Rebuilding The Web

Articles, advocacy, discussion and debate about the many problems of the Web and the challenges of rebuilding it.

How is accessibility made?

Behind every accessibility achievement, there is usually a story of perseverance, patience and tolerance. Rarely do we get to hear about the people behind these achievements and rarer still do we hear why perseverance, patience and tolerance were required. This is an update on an ongoing advocacy effort to make images on the web more accessible.

Making images speak

Images can convey important information that influences how content is understood. To make visual information contained in images accessible on the web, two textual representations are usually required. The first is alt text - a textual replacement for the image. The second is longdesc - a description of the image.

The HTML specification supported both alt and longdesc. Most web browsers partially supported alt while none of the leading browsers supported longdesc. Largely due to non-implementation in major browsers, longdesc was removed from HTML5. After a long and sustained accessibility community effort we achieved a longdesc specification that defines how web authors can provide descriptions for complex images. The effort underway now is to get this feature implemented by web browsers. The longdesc functionality is simple to implement - taking about an hour of development time. It is a non-intrusive user interface enhancement shown in the following mock screen shot.

The context menu for an image displays the item 'View Image Description'.

Selecting the new context menu item navigates the browser to the longdesc URL where the document description resides.

The Firefox effort

Back when Firefox was gearing up to its initial release, it was a leader on accessibility issues. So it was a natural choice to approach Firefox once again to take the lead on accessibility and implement longdesc. It is after all many of the same web standards advocates who helped promote Firefox years ago who are now advocating for support for longdesc.

Here is how the process works. Report the feature request to Mozilla's bug tracking system, get people to vote for it to help prioritize the bug, and find someone at Mozilla to champion the bug for fixing.

The community at large showed their support for longdesc with over 120 people taking the time and effort to vote for Bug 854848 - a respectable number given the complexity of Mozilla's bug tracking system. As for trying to find someone at Mozilla to champion the bug fix, one petty and vindictive Mozilla employee responded with "I just found out that you have emailed still more people, after I advised you not to. As a result, I will now advocate against fixing that bug to whomever will listen. Congratulations, and good luck". Shortly after this petulant outburst, several other Mozilla employees joked about assigning the bug to the least qualified team member to fix it.

An opportunity to work together

To Mozilla, I say that these negative responses will not deter those who advocate for a more inclusive web. Instead, let's examine where the goals of the accessibility community intersect with your own goals as a browser vendor. And let's see how we can work together to achieve those goals. Every browser vendor understands the benefits of working with the community at large in order to produce a better product. Fixing bugs reported through community efforts like this is one of the best examples of this type of collaboration.

Note, the Mozilla employee mentioned in this article has communicated his/her apology for the statements made.

Public comments

1. Posted by Laura
on Monday 2013-05-20 at 10:46:29 PST

Hi Vlad,

Thank you very much for all of your support and for providing the community with this update on longdesc.

Last week I asked Alex Surkov when the bug would be fixed. He said that he didn't know and that the ball is not in hands of accessibility team but rather the UX Mozilla team as they have to approved the idea.
http://asurkov.blogspot.com/2013/05/accessible-mozilla-tech-overview-of.html?showComment=1368729235742#c2436303137851041009

Please, Mozilla take a leadership role and fix Bug 854848.

2. Posted by Alexander Surkov
on Monday 2013-05-20 at 20:53:26 PST

Sad to hear you didn't get a good experience of collaboration with Mozilla.

I'd say problem of the bug is nobody feels responsible for it. It should find an assignee who has a power to say Firefox needs this. That's why I suggested to go to UX team, it is their area.

3. Posted by Patrick H. Lauke
on Tuesday 2013-05-21 at 03:19:03 PST

I have to admit, as much as I'm an advocate for accessibility, that I can understand some of the feelings in the UX team that this is a niche feature that perhaps may best be served with an extension, rather than being baked into the default interface. If the end result is the same, I can personally live with having the longdesc interface first requiring the installation of an extension...

4. Posted by Leif Halvard Silli
on Tuesday 2013-05-21 at 06:51:41 PST

Patrick,

Out or similar motivation, I suggested the UX for longdesc could be made a (hidden) preference. But according to Alexander Surkov, there is no reason to make it a (hidden) preference - and thus there should also be no reason to make it an extension, one should think: http://asurkov.blogspot.no/2013/04/firefox-preferences-for-screen-readers.html?showComment=1369106269118#c5317343217934586477a
The longdesc feature in Opera or iCab has never affected me negatively, so it is simplel to agree with Alexander from that point of view.

On the other side, it seems like at least one Mozilla UX person considers turning some preferences into extensions: http://limi.net/checkboxes-that-kill/ My assumption is that they would then replace some of the advanced preferences with some “official” extensions - e.g. an ‘Advanced Preferences’ extension - that enables these preference. And, in the prolongmenet of that, why not some ’A11Y Preferences’?

Like so many things in life, being consequent is very important. And so, if it became common knowledge that some features can be turned on/off only via extensions, then why not.

Just my $2

5. Posted by Joan
on Tuesday 2013-05-21 at 12:08:09 PST

@Patrick H. Lauke: You are asking the people who have the most obstacles in using computers to perform additional, complex steps involving installation of 3rd party software. And you are asking extension developers to maintaining this software for all browsers and test with each release. Isn't it easier for everyone to simply have this feature built-in? Aren't you going to get more use of this feature when you educate people about this feature and you don't have to qualify the message with "...for those users who have an extension X installed and on browser Y".

6. Posted by Patrick H. Lauke
on Tuesday 2013-05-21 at 13:15:23 PST

@Joan, my comment was mainly about tempering the dramatic "all or nothing" tone of the discussion. Yes, if Mozilla are happy to include it in their UX by default, why not. Considering, though, that most browsers have been actively working on pairing down their interfaces (removing things like RSS indicators, extra buttons, menu options...going for an uncluttered, Chrome-like look), I'm just skeptical this rather niche feature will buck the trend. And pointing out that this extensions are exactly right for additional options like these which are, let's be honest, not really a mainstream feature.

"You are asking the people who have the most obstacles in using computers to perform additional, complex steps involving installation of 3rd party software"

Personally, I don't see installation of extensions (from official places like https://addons.mozilla.org) as all that problematic, as it usually involves a simple in-browser step of accepting and restarting (we're not talking big setup executables).

"And you are asking extension developers to maintaining this software for all browsers and test with each release"

Yes, and for what it's worth, extension architectures are usually not changed dramatically (browser manufacturers don't want to poison their own well of extensions by making backwards-compatibility-breaking changes in most cases). For instance, I've not had to modify https://addons.mozilla.org/en-US/firefox/addon/longdesc/ (except for manually version-bumping it, before Mozilla made this automatic) since releasing it in 2007.

Anyway, my point is: if the browser UX teams *can* be persuaded to add an option by default, great. If not, it's not the end of the world as this can be patched in with extensions.

7. Posted by Patrick H. Lauke
on Tuesday 2013-05-21 at 13:22:49 PST

By the way, worth mentioning that having the option to view longdesc in the context menu is all fine for mouse users. For keyboard users, however, this needs to be complemented with a new way to actually set focus on images themselves, as these are not focusable by default (even images that are enclosed in a focusable element, such as a link, can't be focused directly - and if you activate the context menu when focused on a link, for instance, you get contextual options for the link, not its child content). So we're not just talking about "just adding a simple line to the context menu"...

8. Posted by steve faulkner
on Wednesday 2013-05-22 at 03:35:56 PST

@Patrick

In regards to displaying a context menu for images, the simple suggestion is to add tabindex=0 which puts them in the tab order.

In regards to adding UI, as I noted on another Firefox accessibility UI related bug (about landmark navigation) The Firefox UI team appear to have no issue with adding all sorts of extra UI and features for another niche audience (i.e developers).

9. Posted by Patrick H. Lauke
on Wednesday 2013-05-22 at 06:40:25 PST

@Steve

of course, doing the tabindex=0 thing is the technical solution...but do you want to foist this on all keyboard users? Or make it part of a setting that needs to be enabled? And - not tested - does this work for having nested focusable elements (e.g. a link containing an image with tabindex=0)?

As for adding to dev tools, the additions are not being made to the core UI itself (i.e. with new dev tools appearing, there aren't more things being added to context menu), but rather just to the dev tools themselves. What then happens at that point is up to a different UI/UX discussion relating specifically to dev tools.

10. Posted by Timothy Bajorek
on Wednesday 2013-05-22 at 07:13:53 PST

>my comment was mainly about tempering the dramatic "all or nothing" tone of the discussion

I did not feel that tone at all from those asking for this feature. Sounds like there is a process for asking for feature requests through voting. People took the time to vote and those votes should be respected.

>Personally, I don't see installation of extensions (from official places like https://addons.mozilla.org) as all that problematic

Not everyone is as technical as you ;-)

>my point is: if the browser UX teams *can* be persuaded to add an option by default, great

I voted because its a form of persuasion. Sounds like you support this Patrick, so could you please vote too?

11. Posted by Leif Halvard Silli
on Saturday 2013-05-25 at 17:39:19 PST

@SteveFaulkner

You said: “In regards to displaying a context menu for images, the simple suggestion is to add tabindex=0 which puts them in the tab order.“

Question: How can one make Firefox display a contextual menu for items that have focus? Is there an option for that, or?

@Patrick

Patrick asked: “And - not tested - does this work for having nested focusable elements (e.g. a link containing an image with tabindex=0)?”

If you add tabindex=0 to the img, then, yes, you can tab from the link to the image.

12. Posted by Former Firefox User
on Sunday 2013-05-26 at 17:27:23 PST

Mozilla, I am very disappointed in you. Your guiding principle "doing good is part of our code" is duplicitous. You have not only lost a user but you have lost my trust.

13. Posted by stevefaulkner
on Monday 2013-05-27 at 23:30:34 PST

@leif,

shift+f10

14. Posted by steve faulkner
on Tuesday 2013-05-28 at 06:36:29 PST

@former firefox user and the whole direction of this post in general. Mozilla and in particular the accessibility team do a shitload of thankless work making Firefox the most accessible browser out there. The issue of longdesc is but one of the many they have to deal with and prioritise, so cut them some slack.

15. Posted by Laura
on Tuesday 2013-05-28 at 08:14:11 PST

@Former Firefox User: Being disappointed doesn't get the bug fixed. We need a patch. Is there anyone who will step up and write one?

16. Posted by Laura
on Wednesday 2013-05-29 at 11:49:18 PST

Opera and iCab browsers deserve accolades for providing native longdesc functionality years ago. Bravo.

17. Posted by Vlad Alexander
on Wednesday 2013-05-29 at 17:29:20 PST

Jennifer Morrow from Mozilla writes: "After further looking into this, we've decided to support the longdesc attribute in Firefox."

Thank you Mozilla for taking the lead! And thanks to everyone who took the time and effort to vote - your participation helped make this happen. Please follow the progress / implementation schedule through bug 877453.

18. Posted by Steve
on Thursday 2013-12-05 at 06:46:06 PST

Using tabindex to get Shift+F10 working is a workaround, not the real deal, sorry.

Use F7 caret mode to fix this in a future FF release. You can already SELECT an image by this, but the OBJECT below is NOT considered to be contextual for the menu, so Shift+F10 will fail after selection. This is strange, because the copy action HAS the context (image), but NOT the context for the browser context menu :)

Comments are closed for this article.

Main menu

Check out the a11y bugs project that aims to help browser / tool vendors fix accessibility bugs.