854848 - Support the longdesc attribute

Status: REOPENED

(Core :: Disability Access APIs, defect)

Description

[Laura Carlson]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:19.0) Gecko/20100101 Firefox/19.0
Build ID: 20130307023931

Steps to reproduce:

Tried to obtain the longdesc attribute for an image element.


Actual results:

Nothing.


Expected results:


The browser should supply a way of accessing a longdesc according to the spec:

"
User agents should make the link available to all users through the regular user interface.

User agents should expose the link to relevant APIs, especially accessibility-oriented APIs.

User agents should enable users to discover when images in a page contain a long description.
"
http://www.w3.org/TR/2013/WD-html-longdesc-20130312/#longdesc

Opera added native support for longdesc in 2009.
http://www.opera.com/docs/changelogs/mac/1010b1/#ui
iCab has had native support for longdesc long before then.

Two FireFox extensions exist:
* Longdesc add-on extension for Firefox by Patrick H. Lauke
https://en.add-ons.mozilla.com/en-US/firefox/addon/longdesc/
* longdesk add-on extension for Firefox by Anthony Ricaud
https://en.add-ons.mozilla.com/en-US/firefox/addon/longdesk/

Innovative browser vendors provide ways that make longdesc discoverable:
http://www.d.umn.edu/~lcarlson/research/ld-ua.html

Research on Browsers 
http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc/Implementation#Recent_Research_on_Browsers

HTML5 Image Description (longdesc) Extension Draft Published:
http://www.w3.org/News/2013.html#entry-9756

The W3C validator http://validator.w3.org was updated last week to support the longdesc attribute in HTML5 as specified in http://www.w3.org/TR/html-longdesc/
The W3C validator has always supported it in HTML4.

HTML 4 on longdesc 
http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc/References#HTML_4_on_longdesc

Please support the longdesc attribute.

Related bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1996

Comment 1

[Boris Zbarsky [:bzbarsky]]

The "regular user interface" and "enable users to discover" bits sound like UI issues, not core engine issues, right?

Over to a11y for the "accesibility-related APIs" bit, I guess.

Comment 2

[David Bolter [:davidb] (NeedInfo me for attention)]

Sure we can own it for now. The accessibility API part is very simple. The UI parts are more interesting since this could lead to more actual usage in the wild.

Comment 3

[Gérard Talbot]

IE8 supports (minimally) longdesc natively, without any extension.
 
"
The target of the longDesc attribute is now displayed as the tooltip, if
present; otherwise, the title is displayed.
"
http://msdn.microsoft.com/en-us/library/ie/ms534132%28v=vs.85%29.aspx

-------------

Netscape 7 supported the longdesc attribute via its context-menu.
Netscape 7.0 (rv:1.0.1 Gecko/20020823) has the URL linkified in the right-click context-menu.
In Netscape 7.2 (rv:1.7.2 Gecko/20040804), the link of the longdesc URI is plain text, not blue, linkified, clickable in the right-click context-menu..

-------------

HTML Techniques for Web Content Accessibility Guidelines 1.0
7.2 Long descriptions of images
http://www.w3.org/TR/WCAG10-HTML-TECHS/#long-descriptions

-------------

Techniques for WCAG 2.0
H45: Using longdesc
http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/H45

-------------

Techniques for User Agent Accessibility Guidelines 1.0
2.3 Render conditional content (P1)
"
3. Allow the user to configure how the user agent renders a long description (e.g., longdesc in HTML 4 [HTML4]). Some possibilities include:

    Render the long description in a separate view.
    Render the long description in place of the associated element.
    Do not render the long description, but allow the user to query whether an element has an associated long description (e.g., with a context-sensitive menu) and provide access to it.
    Use an icon (with a text equivalent) to indicate the presence of a long description.
    Use an audio cue to indicate the presence of a long description when the user navigates to the element.
"
http://www.w3.org/TR/UAAG10-TECHS/guidelines.html#long-descriptions

-------------

User Agent Accessibility Guidelines 1.0 Test suite (HTML techniques)
ALT, TITLE, and LONGDESC attributes for IMG element
http://www.w3.org/WAI/UA/TS/html401/cp0203/0203-IMG.html#test3

-------------

User Agent Accessibility Guidelines (UAAG) 2.0
"
Guideline 1.1 - Provide access to alternative content. [Implementing 1.1]

Summary: The user can choose to render any type of alternative content available. (1.1.1). The user can also choose at least one alternative such as alt text to be always displayed (1.1.2), but it's recommended that users also be able to specify a cascade (1.1.4), such as alt text if it's there, otherwise longdesc, 
"
http://www.w3.org/TR/2012/WD-UAAG20-20121004/#gl-access-alternative-content

That's what IE8+ does actually.

Comment 4

[Gérard Talbot]

> it's recommended that users
> also be able to specify a cascade (1.1.4), such as alt text if it's there,
> otherwise longdesc, 
> "
> http://www.w3.org/TR/2012/WD-UAAG20-20121004/#gl-access-alternative-content
> 
> That's what IE8+ does actually.

Argh... no. IE8+ displays the title attribute as a tooltip and if there is an empty title attribute (or no specified title attribute) and there is a non-empty longdesc attribute value, then longdesc attribute will be displayed as a tooltip.

Comment 5

[alexander :surkov (:asurkov)]

Steve shared a link how longdesc implementation can look http://html5accessibility.com/CSUN12/longdescription.html. I like the idea of popup on mouse over. It's easy discoverable and doesn't seem it has disadvantages (duping by special a11y support is not a problem)

Comment 6

[Laura Carlson]

(In reply to alexander :surkov from comment #5)
> Steve shared a link how longdesc implementation can look
> http://html5accessibility.com/CSUN12/longdescription.html. I like the idea
> of popup on mouse over. It's easy discoverable and doesn't seem it has
> disadvantages (duping by special a11y support is not a problem)

Hi Alexander,

How would that work on touch devices?

A User Interface idea that we had discussed at one point for touch devices was a "turn the image around" transition e.g., the UI could have a flip transition: akin to flipping over a hard-copy physical photograph to read what is written on the back. Activation could be upon a finger flick gesture on the corner of an image or a tap-and-hold gesture for a touch device contextual menu.

Other User interface examples are at:
http://www.d.umn.edu/~lcarlson/research/ld-ua.html

Comment 7

[alexander :surkov (:asurkov)]

(In reply to Laura Carlson from comment #6)
> (In reply to alexander :surkov from comment #5)
> > Steve shared a link how longdesc implementation can look
> > http://html5accessibility.com/CSUN12/longdescription.html. I like the idea
> > of popup on mouse over. It's easy discoverable and doesn't seem it has
> > disadvantages (duping by special a11y support is not a problem)
> 
> Hi Alexander,
> 
> How would that work on touch devices?

I missed it from initial consideration. A semi-transparent link on the image probably works.

> A User Interface idea that we had discussed at one point for touch devices
> was a "turn the image around" transition e.g., the UI could have a flip
> transition: akin to flipping over a hard-copy physical photograph to read
> what is written on the back. Activation could be upon a finger flick gesture
> on the corner of an image or a tap-and-hold gesture for a touch device
> contextual menu.

it's fancy and should be nice

Comment 8

[Laura Carlson]

Hi Alexander,

>> How would that work on touch devices?
> 
> I missed it from initial consideration. A semi-transparent link on the image
> probably works.

Yes, a semi-transparent link as a user option could work and satisfy the "No visual encumbrance" requirement too if a no-link option was also available.
http://www.w3.org/TR/2013/WD-html-longdesc-20130312/#req

It would be good to offer the user some options. For example Chris Kennish's longdesc chrome plugin provides an array of longdesc highlighting preferences:
https://chrome.google.com/webstore/detail/longdesc/haohljalgapbacpkfefnmhiadanhejmb

Once the extension is installed if a user selects

1. Preferences
2. Extensions
3. Then under Longdesc 0.0.1 Select: The "Options" Link. They are presented with the following options:

Highlight color:
* red
* green
* blue
* yellow
* aqua
* black
* fuchsia
* gray
* lime
* maroon
* navy
* olive
* purple
* silver
* teal
* white

Highlight style:
* solid
* dotted
* inset
* outset

Highlight width:
* 1
* 2
* 3
* 5
* 0 (no highlight)

Open longdesc:
* same tab
* new tab
* new window

> > A User Interface idea that we had discussed at one point for touch devices
> > was a "turn the image around" transition e.g., the UI could have a flip
> > transition: akin to flipping over a hard-copy physical photograph to read
> > what is written on the back. Activation could be upon a finger flick gesture
> > on the corner of an image or a tap-and-hold gesture for a touch device
> > contextual menu.
> 
> it's fancy and should be nice

Would something like that be difficult to implement something like this in Mozilla?

Comment 9

[David Bolter [:davidb] (NeedInfo me for attention)]

Chrome bug is here: https://code.google.com/p/chromium/issues/detail?id=224285
Initial UI proposed is a context menu addition.

Comment 10

[Hixie (not reading bugmail)]

This is just a dupe of bug 1996. It isn't any more reasonable now than it has been before.

Comment 11

[Leif Halvard Silli]

(In reply to Hixie (not reading bugmail) from comment #10)
> This is just a dupe of bug 1996. It isn't any more reasonable now than it
> has been before.

Some pieces of data that IMO makes it more reasonably now:

1) In HTML4 and up until now in HTML5, there were no validation of the longdesc attribute.[1] This just changed.[2][3] And will probably change again, to become same level strict as the HTML5 validation of @src attribute of the img element. [4][5]

2) The documented problems of the past have been incorrect authoring and lack of correct implementation. There is now new and improved validator support and more widespread implementation (e.g. in Chrome Vox and NVDA). This will lead authors to make fewer errors and users to experience longdesc.

3) There is an improving spec that focues on how to technically implement longdesc.

[1] http://tinyurl.com/lackOfURLvalidation
[2] http://lists.w3.org/Archives/Public/www-validator/2013Mar/0060
[3] http://tinyurl.com/ValidatorNUsURLvalidation
[4] http://lists.w3.org/Archives/Public/www-validator/2013Mar/0074
[5] http://tinyurl.com/PleaseForbidEmptyLongdescURLs

Comment 12

[Mike Gifford]

I do think that exposing long desc via the UI will make it much more useful for everyone. 

This is 2013, and the arguments in 2013 seem pretty solid.  It's being used, it's in the spec, other browsers are doing it, why shouldn't FF?

I like Léonie's point in:
https://bugzilla.mozilla.org/show_bug.cgi?id=1996#c98

Comment 13

[John Rochford]

My development team has been implementing longdesc on websites and in online courses for many years. We would like our Firefox users to be able to easily discover and take advantage of our long descriptions. The more user agents that support longdesc, the more known and thus used longdesc will become.

Native Firefox support for longdesc would be great.

Comment 14

[Hixie (not reading bugmail)]

> it's in the spec

It's in _a_ spec. Anything can be in a spec, all it takes is one person to write a spec. :-)

longdesc="" doesn't actually help well-designed accessible sites (since those wouldn't rely on images to convey content). It doesn't help poorly-designed accessible sites (since they wouldn't bother to write a longdesc="" page).

Plus the attribute itself is a lost cause: http://blog.whatwg.org/the-longdesc-lottery

This is just a duplicate of bug 1996 and is a waste of everyone's time.

Comment 15

[Mike Gifford]

Sorry Hixie.  You may well have been following this issue since 2007, but I don't think that most of us on this list have.  

I do think a lot has changed since that time.  Lots hasn't.  But I really don't want to be put back into a debate that is now closed off and six years old.  

That's not a very good definitive reference when making a decision looking ahead at how to best support HTML5.

Comment 16

[Hixie (not reading bugmail)]

I've been following this since far longer than 7 years. I filed bug 1996 in 1998.

At some point, we (as a community) have to decide to move on to new things. I'm sorry you weren't around when this was first (and second, and third, and fourth, and...) debated. I wasn't around when we were debating the shape of the wheel, but I don't ask to reopen that decision...

Comment 17

[Vlad Alexander]

>Anything can be in a spec
We know, you put everything but the kitchen sink in there.

>, all it takes is one person to write a spec. :-)
You said it!

Hixie, you are taking this personally because you did not get your way on longdesc. Surely you are capable of showing a bit of grace by not being an obstacle to those who care deeply about this issue?

>At some point, we (as a community) have to decide to move on to new things.
The community is voting to fix this bug! Please respect the people who took the time to register and vote for this bug.

Comment 18

[Hixie (not reading bugmail)]

(In reply to Vlad Alexander from comment #17)
> >Anything can be in a spec
> We know, you put everything but the kitchen sink in there.

Actually, the kitchen sink is in there too!

   http://whatwg.org/html#abstract


> Hixie, you are taking this personally because you did not get your way on
> longdesc.

I'm not sure what "my way" is supposed to be here, or what it would mean for me to get my way or not get my way. What I want is for the Web to be more accessible for everyone. longdesc="" doesn't achieve that goal, it hinders it.


> Surely you are capable of showing a bit of grace by not being an
> obstacle to those who care deeply about this issue?

I do care deeply about this issue. I think having longdesc="" on the Web will actually harm long-term accessibility of the Web because it will cause the few authors who actually care enough to learn about how to make pages accessible to waste their time doing something that takes a lot of time _and_ is of almost no practical use. There's tons of stuff that authors 
could do to improve accessibility. Let's not distract them with useless features like this.


> The community is voting to fix this bug! Please respect the people who took
> the time to register and vote for this bug.

Please respect the people who took the time to deeply research this issue, also.

Comment 19

[Vlad Alexander]

>Please respect the people who took the time to deeply research this issue
Your "research" was faulty. You proved that practically no one uses longdesc and out of those who do, fewer still use it correctly. Congratulations, you proved something obvious. Your research should have been to find out why.

As an authoring tool vendor, let me propose a likely reason: the average content author had no way of testing or seeing the benefits of using longdesc. This is what this bug is all about. It gives content authors the ability to interact with longdesc, test it and see how it works in a browser. Let's fix this bug and give the community an opportunity to make longdesc work.

Comment 20

[Alastair Campbell]

Vlad has a good point about the authoring aspect - if you can't check something when authoring, you're unlikely to get it right, or care. It's a chicken and egg issue that has to be solved on the browser side first.

Longdesc (or at least some sort of extended image description) is of practical *niche* use. No, it's not common, it's not a cow path. That's the nature of accessibility, it is for minority audiences, and in this case a minority use-case as well.

It's an important use-case though, for example educational material with diagrams, graphs or infographics. They are not authored by everyone but, when they are, an extended description is needed.

Without some form of extended description, it impacts the viability of HTML as the technology of choice. An organisation looks at the requirements of their content and asks what is the best language/technology. PDF is often an alternative, and both PDF and Flash enable longer descriptions. Not well IMHO, but they do tick that box.

I also don't want to re-hash old longdesc arguments, but since it has implementations already, and no alternative has been agreed as better, can we just get on with it?

Comment 21

[Geoff Kerson]

Laura Carlson and Alastair Campbell have nailed it. When people widely considered to really know what they are talking about re web accessibility are behind this, can we not indeed "just get on with it" and fix this bug?

Comment 22

[Laura Carlson]

Comment from Shelley Powers:
https://plus.google.com/115416893708386851153/posts/DQhprtnuGeP

Comment 23

[Stephanie Sullivan Rewis]

I would definitely up-vote this bug request. Saying something isn't valuable in any situation because the implementation was poor and thus, many authors didn't bother, isn't answering the right question. 

Longdesc, if implemented in a manner useful to the user, can be very useful for the comprehension of charts and graphed data, among other things. It's hard to understand why it's such a contentious issue. It has a use—albeit limited—as is the case with many elements of a11y. That doesn't make them any less important. 

I would love to see this fixed.

Comment 24

[John Foliot]

My position and opinion on the fate of longdesc is, by now, fairly well known. 

I applaud Mozilla for tackling the user-agent requirements of this valuable attribute. Despite the rhetoric and misinformation offered by those who oppose the retention of longdesc in the W3C HTML5 specification, saner heads and the voice of the community was heard.

Given that the HTML5 Image Description Extension Spec (https://dvcs.w3.org/hg/html-proposals/raw-file/753af00ced01/longdesc1/longdesc.html) is on track to become a W3C Recommendation, it is good that Mozilla is now taking on this issue. 

I would definitely up-vote this bug request as well.

Comment 25

[John Foliot]

(In reply to Hixie (not reading bugmail) from comment #14)
> 
> This is just a duplicate of bug 1996 and is a waste of everyone's time.

If this is such a “waste of time”, why have you bothered to respond to this bug 4 times now? Please, for everyone’s sake, don’t waste any more of your time here: move on to something else and let those of us who want to see Mozilla succeed at supporting the W3C HTML5 Image Description Extension Spec work with the Mozilla folks to do just that.

Comment 26

[karl]

I've added my vote for this spec and would like to publicly acknowledge those who have worked so hard to get longdesc where it is today.

I think it is hard to come up with any new arguments for/ against longdesc than those which have already been more-than-adequately posed by others on this ticket. I hope to see longdesc support soon.

Comment 27

[Denis Boudreau]

I concur with Karl. I've also added my vote because even though some people will stop at nothing to claim the attribute is useless, hundreds of valid use cases were put together during the HTML5 saga that prove otherwise. A lot of people (myself included) have been hoping for longdesc to get the recognition and support it deserves for ages, but only a handful had the courage to really pick that ball up and run with it. So thank you for keeping the fight alive: we wouldn't be having this discussion if you didn't have the tenacity the rest of us lacked when it really counted the most.

Comment 28

[Lars Gunther]

While I am convinced that longdesc is worthy of support, may I remind all my accessibility friends and others that Bugzilla is not a debate forum. Use the vote system and other forums to voice opinion, and write comments here that will help the one who writes the code.

Comment 29

[Nigel Peck]

If a place is needed for discussion then I have already started a thread at Accessify Forum:
http://www.accessifyforum.com/viewtopic.php?t=22798

Comment 30

[Cliff Tyllick]

(In reply to Lars Gunther from comment #28)
> … write comments here
> that will help the one who writes the code.

Lars, please excuse my ignorance: What information would the person who writes the code need? I'd love to participate in that discussion, but as a newbie to the Bugzilla forum, I'm at a loss as to the best way to do so.

By the way, before asking this question, I did check the "Help" link, where I did not find the answer but did discover this about the process:

20. Additional Comments: You can add your two cents to the bug discussion here, if you have something worthwhile to say.

I think it's worth noting that no one who has made a comment opposing this feature is at all active in the field of accessibility. Our opposition might be involved in making life easier for people who write code, but not in making the Web work better for everyone, regardless of how they interact with it.

Comment 31

[Laura Carlson]

Hi Cliff,

(In reply to Cliff Tyllick from comment #30)
> (In reply to Lars Gunther from comment #28)
> > … write comments here
> > that will help the one who writes the code.
> 
> Lars, please excuse my ignorance: What information would the person who
> writes the code need? 

David Bolter added Keywords: uiwanted to the bug, so ideas for the browser interface may be helpful to the Mozilla engineers.

I put together some user interface ideas at:
http://www.d.umn.edu/~lcarlson/research/ld-ua.html

Also check Comments 5-8 for further discussion. Comment 8 has Chris Kennish's ideas.

Comment 32

[devarshi]

Some thoughts:

Common Requirement:
1.	Image that uses the longdesc attribute should receive keyboard focus.

Scenarios:

A] Blind User:
1.	User either selects the graphic from a list or tabs / arrows to it.
2.	The feedback from a screen reader voices any available alt text or title if present, but then goes on to acknowledge the presence of longdesc, something like, “press enter for long description.” Right now, JAWS 13 running on IE8 says “press Alt + Enter for long description” but there seems to be a conflict with this key combination. 

B] Keyboard Only Sighted User:
1.	User tabs to an graphic that contains the longdesc attribute.
2.	On receiving keyboard focus, the graphic either gives a visual feedback, like a fading effect or displays the text “press enter for the long description.”

C] Magnifier User:
See B above.

D] Voice User:
See B above.

-Devarshi

Comment 33

[David MacDonald]

I support this bug. Would like to see longdesc supported

Comment 34

[v.conway]

I support this but and think it should be supported.

Comment 35

[Laura Carlson]

Some longdesc test cases are at:
http://www.d.umn.edu/~lcarlson/research/ld-tests/tests/

They include the following 4 tests and expected results.

1. longdesc on a different page using an absolute URL:
http://www.d.umn.edu/~lcarlson/research/ld-tests/tests/index.html#ld1

2. longdesc on a different page using a relative URL:
http://www.d.umn.edu/~lcarlson/research/ld-tests/tests/index.html#ld2

3. longdesc on the same page using a fragment identifier:
http://www.d.umn.edu/~lcarlson/research/ld-tests/tests/index.html#ld3

4. longdesc as a descendant of an <a> element:
http://www.d.umn.edu/~lcarlson/research/ld-tests/tests/index.html#ld4

Expected results are at: 
http://www.d.umn.edu/~lcarlson/research/ld-tests/tests/index.html#results

Comment 36

[Tony Mechelynck [:tonymec]]

(In reply to Laura Carlson from comment #35)
> Some longdesc test cases are at:
> http://www.d.umn.edu/~lcarlson/research/ld-tests/tests/
> 
> They include the following 4 tests and expected results.
> 
> 1. longdesc on a different page using an absolute URL:
> http://www.d.umn.edu/~lcarlson/research/ld-tests/tests/index.html#ld1
> 
> 2. longdesc on a different page using a relative URL:
> http://www.d.umn.edu/~lcarlson/research/ld-tests/tests/index.html#ld2
> 
> 3. longdesc on the same page using a fragment identifier:
> http://www.d.umn.edu/~lcarlson/research/ld-tests/tests/index.html#ld3
> 
> 4. longdesc as a descendant of an <a> element:
> http://www.d.umn.edu/~lcarlson/research/ld-tests/tests/index.html#ld4
> 
> Expected results are at: 
> http://www.d.umn.edu/~lcarlson/research/ld-tests/tests/index.html#results

Mozilla/5.0 (X11; Linux x86_64; rv:23.0) Gecko/20100101 Firefox/23.0 SeaMonkey/2.20a1 ID:20130421003001 c-c:1637ab8d5a01 m-c:0d50cb959c46

Experiment shows that the longdesc URL, resolved, is accessible via "Right-click → Properties" under "Description"; it is copyable but not clickable; AFAICT there is no visible cue that a longdesc is present (unless it is governed by a preference which I have in the wrong state). I'd say that the "Expected Results" listed below the images are partly satisfied.

Comment 37

[Laura Carlson]

Hi Tony,

(In reply to comment #36)

> Mozilla/5.0 (X11; Linux x86_64; rv:23.0) Gecko/20100101 Firefox/23.0
> SeaMonkey/2.20a1 ID:20130421003001 c-c:1637ab8d5a01 m-c:0d50cb959c46
> 
> Experiment shows that the longdesc URL, resolved, is accessible via 
> "Right-click > Properties" under "Description"; it is copyable but 
> not clickable; AFAICT there is no visible cue that a longdesc 
>  is present (unless it is governed by a preference which I have in 
> the wrong state). I'd say that the "Expected Results" listed below 
> the images are partly satisfied.

Yes. You are right. I know my Firefox v/20 has partial native UI support via the "View Image Information" context menu, which shows the URL of the longdesc attribute (but currently doesn't open it). The functionality piece could be easy to implement via a simple linkified context menu item [1]. Selecting the menu item would then navigate the user to the URL specified by longdesc. 

As Gerard Talbot previously said at one time Netscape did open it.

* Netscape 7 supported the longdesc attribute via its context-menu. Netscape 7.0 (rv:1.0.1 Gecko/20020823) has the URL linkified in the right-click context-menu.

* In Netscape 7.2 (rv:1.7.2 Gecko/20040804), the link of the longdesc URI is plain text, not blue, linkified, clickable in the right-click context-menu.

As David Bolter previously said the discoverability piece is more interesting since it can lead to more actual usage in the wild.

[1] http://www.d.umn.edu/~lcarlson/research/ld-ua.html#contextmenu

Comment 38

[Laura Carlson]

(In reply to Laura Carlson from comment #35)
> Some longdesc test cases are at:
> http://www.d.umn.edu/~lcarlson/research/ld-tests/tests/
> 
> They include the following 4 tests and expected results.

I neglected to create a test case for Data URIs. One is now at:

http://www.d.umn.edu/~lcarlson/research/ld-tests/tests/index.html#ld5

My results are the same as in Comment 37

Comment 39

[Jennifer Morrow [:Boriss] (UX)]

Thank you for bringing this to our attention, Laura.  As one of Firefox's user experience designers unfamiliar with longdesc's historical context, I reviewed it for consideration.  After all, we're absolutely open to browser improvements, particularly that benefit users with screenreaders or disabilities.  But, I'm having trouble seeing that tangible benefit of longdesc to those or any other users.  Yes, images can absolutely benefit from longer descriptions (particularly if users cannot view the image), but is longdesc really a good way way to achieve this?  

If we were to begin supporting longdesc - in a context menu, for instance - I expect very low adoption across the web.  This creates a very inconsistently-implemented solution for describing images - not something users with screenreaders could expect any given site to have implemented and not something any given site could expect users to be familiar with.  The result is that it works in a few cases to those who know about it, but mostly isn't used and isn't known about - it's an internet easter egg.

Why do I expect low adoption across the web?  Mostly because there are so many better ways to provide a description.  Alt-text is short because it's simply meant to tell users what the image is - not provide meaningful artistic commentary or link to another site.  After all, there are so many much better ways to provide description, commentary, and links available to both users with screenreaders and without, I can't understand why longdesc would be a better method than any of those.  Basically, if a description of an image requires paragraphs of text or a whole link, why would a web author want to expose that to only the people that know about longdesc?  

I'm not WONTFIX'ing this for now, because I'm genuinely just learning about longdesc now and perhaps I'm overlooking an important use case, particularly in the accessibility area.  If I have, please let me know what functionality means longdesc should be supported where other tools and options for exposing text aren't sufficient.

Comment 40

[Stephane Deschamps]

Hi Jennifer,

A typical case I can testify about, in the real world: there was a poster on a wall, and I was with someone with extreme low vision. He asked if I could describe it, so I said "here on the forefront is a black horse grazing the grass, which is green and hilly, and at the back there is a ruin of something like a castle tower. The sky is two thirds of the image and is of a deep blue with a few white clouds." He had to hear a description so as to make sense of the image, and then said "oh, I can see now". And he could, based on his very partial vision plus my description, understand what the shapes meant.

This is typically what you won't share under a photo, but what is needed by a low-vision user (he uses Jaws, the screen reader, as he is almost blind in front of a screen).

This was a revelation to me, and this pushed me to adopt longdesc, for lack of a better mechanism.

Comment 41

[Vlad Alexander]

Thanks for looking into this Jennifer.

>Alt-text is short because it's simply meant to tell users what the image is

Actually, the purpose of alternate text is to provide a textual substitute for the image. This is quite different than a description. Let me illustrate with a simple example. Say you have an icon of a heart. The description could read "small red heart". Now put that into the following markup:

<p>I <img src="icon.png" alt="small red heart" /> you!</p>

In Firefox, copy and paste the sentence into a text only document or turn image rendering off. You will get:

"I small red heart you!"

As you can see, using a description for alt text does not work. The textual substitute for the image in this example would be "love". If you put that same image into a different context, alt text would need to change as well in order to make sense.

<p>My <img src="icon.png" alt="heart" /> breaks.</p>

> After all, there are so many much better ways to provide description

All other methods are intrusive - taking up visual real estate and potentially interrupting the flow of content.

Comment 42

[Jennifer Morrow [:Boriss] (UX)]

(In reply to Vlad Alexander from comment #41)
> Thanks for looking into this Jennifer.
> 
> >Alt-text is short because it's simply meant to tell users what the image is
> 
> Actually, the purpose of alternate text is to provide a textual substitute
> for the image. This is quite different than a description. Let me illustrate
> with a simple example. Say you have an icon of a heart. The description
> could read "small red heart". Now put that into the following markup:
> 
> <p>I <img src="icon.png" alt="small red heart" /> you!</p>
> 
> In Firefox, copy and paste the sentence into a text only document or turn
> image rendering off. You will get:
> 
> "I small red heart you!"
> 
> As you can see, using a description for alt text does not work. The textual
> substitute for the image in this example would be "love". If you put that
> same image into a different context, alt text would need to change as well
> in order to make sense.
> 
> <p>My <img src="icon.png" alt="heart" /> breaks.</p>
> 
> > After all, there are so many much better ways to provide description
> 
> All other methods are intrusive - taking up visual real estate and
> potentially interrupting the flow of content.

Hey Vlad, I actually saw your example and comment on https://code.google.com/p/chromium/issues/detail?id=224285, but agreed with the followup comment that such image-as-word use is very rare, and the regular alt text alone would suffice in providing a word like "heart."  My understanding of longdesc's purpose is more akin to what Setphane describes in Comment 40, and I agree that it's a good use case, I'm just not convinced longdesc is an ideal way to provide it.  So, prepared to be pinged, Marco.  :)

Comment 43

[Janina Sajka]

When you say longdesc may not be the ideal way to support the use case, I have to wonder whether you're thinking this is some kind of new attribute, nesly introduced. It's not. It was intro'd in HTML 4, and there is extensive use. Unfortunately, most of the correct use is not in the wild, but behind walled gardens, especially in educational textbook-type content.
So, even if it's not the iedal approach, there's still the need to support existing usage.

Comment 44

[Laura Carlson]

Hi Jennifer,

(In reply to Jennifer Morrow [:Boriss] (Firefox UX) from comment #39)

> Thank you for bringing this to our attention, Laura. 

You're welcome.

> As one of Firefox's
> user experience designers unfamiliar with longdesc's historical context, I
> reviewed it for consideration.  After all, we're absolutely open to browser
> improvements, particularly that benefit users with screenreaders or
> disabilities. 

Thank you very  much for being open to browser improvements, particularly ones that would benefit users with disabilities. As Alastair Campbell said in Comment 20 longdesc is "not common, it's not a cow path. That's the nature of accessibility, it is for minority audiences".

> But, I'm having trouble seeing that tangible benefit of
> longdesc to those or any other users. 

Did you find the use cases in the specification unclear as to benefits? 
http://dvcs.w3.org/hg/html-proposals/raw-file/default/longdesc1/longdesc.html#UCnR
Perhaps Chaals could make those use cases clearer if you find them ambiguous.

Some formal use cases are available at:
http://www.d.umn.edu/~lcarlson/research/ld.html#uc

> Yes, images can absolutely benefit
> from longer descriptions (particularly if users cannot view the image), but
> is longdesc really a good way way to achieve this?  

No better technical solution exists. Longdesc solves problems. And I expect that Mozilla has a UX team that could enable better usability of longdesc. Longdesc is perceivable to its target audience and Mozilla could take a leadership role to make it more discoverable and more useful to others. People with disabilities would be the losers if Mozilla does not.

> If we were to begin supporting longdesc - in a context menu, for instance -
> I expect very low adoption across the web.  

A context menu could certainly provide a type of functionality to obtain the target of a longdesc. However, higher adoption would require Mozilla to truly be open to browser improvements for discoverability and be innovative in its solution. A start of some ideas for discoverability are provided at:
http://www.d.umn.edu/~lcarlson/research/ld-ua.html
I expect that Mozilla  UX Team could develop those ideas into a great implementation.

> This creates a very
> inconsistently-implemented solution for describing images - not something
> users with screenreaders could expect any given site to have implemented and
> not something any given site could expect users to be familiar with. 

Modern screen readers have good support of longdesc.
http://www.d.umn.edu/~lcarlson/research/ld.html#at

A dear friend of mine who happens to be blind wrote the following to me last year. It is reprinted with his permission as it speaks to your concern:

<quote>
ever since i first started working with the W3C, i've been attempting to explain that while a picture may be worth a thousand words, that doesn't mean i want to hear all one-thousand words all at once or at this particular moment... i do, however, absolutely need to know that: 1) the author has inserted an image here, so it is probably relevant to the content (the purpose of "alt"); 2) that there is a long description of the image available should i need/want it; 3) that i can use familiar structural navigational features and commands to obtain the description's contents, with the ability to stop speech and review in detail (i.e. by character) or by structure (i.e. current list item, next list item, list item x out of y) the structured content used to provide the long description; and 4) the confidence that when i am satisfied with the amount of information obtained from the long description, i can and will return to the exact place in the main content from which i initiated exposition of the long description.

longdesc fulfills all my requirements and needs.
<unquote>

> The
> result is that it works in a few cases to those who know about it, but
> mostly isn't used and isn't known about - it's an internet easter egg.

This is where Mozilla can step up and take a leadership role. As Alastair said in comment 20 it is  a "chicken and egg issue that has to be solved on the browser side first". 

> Why do I expect low adoption across the web?  Mostly because there are so
> many better ways to provide a description.  Alt-text is short because it's
> simply meant to tell users what the image is - not provide meaningful
> artistic commentary or link to another site.  After all, there are so many
> much better ways to provide description, commentary, and links available to
> both users with screenreaders and without, I can't understand why longdesc
> would be a better method than any of those.

longdesc is programmatically determinable while not forcing a visual encumbrance upon users. Please consult:
http://www.d.umn.edu/~lcarlson/research/constriants/programmatic.html
http://www.d.umn.edu/~lcarlson/research/constriants/visual-encumbrance.html

It provides authors with a solution while allowing for constraints. Further information is available at:
http://www.d.umn.edu/~lcarlson/research/constriants/

> Basically, if a description of
> an image requires paragraphs of text or a whole link, why would a web author
> want to expose that to only the people that know about longdesc?  

Similar to the alt attribute, longdesc is not typically displayed by default in browsers. Modern screen readers take advantage of the programmatic determinability of longdesc. It is announced and read upon request so that users are provided a choice of listening to it (or not).

In JAWS 11 and up one can even use the list of graphics contained in the document in order to retrieve longdescs by using the "Graphics List" to move focus to an individual graphic, the longdesc of which can then be accessed by pressing the "enter" key.

But you are right, Jennifer. Allowing discoverability serves other use cases. Longdesc is not only an accommodation mechanism for people who are blind or have a visual impairment and use a screen reader, it also can assist others who need or would like textual reinforcement when deciphering the contents of a complicated image. 

The fact is that, some people may want or need to consume or access long description content but do not use assistive technology (AT). The following sighted people may be aided by access to a longdesc:

* Users who have a cognitive or visual impairment. 
* Users with either a keyboard or pointing device without screen reader or assistive technology.
* Users with a custom input accommodation, such as a mouth-stick or sticky keys.
* Users who have small screens (e.g. mobile phone or screen magnifiers).
* Users who turn off images to decrease bandwidth use in order to lower their Internet usage fees.
* Authors, for ease of authoring, testing, and maintenance purposes. 

> I'm not WONTFIX'ing this for now, because I'm genuinely just learning about
> longdesc now and perhaps I'm overlooking an important use case, particularly
> in the accessibility area.

Thank you for wanting to learn about longdesc. The following may be helpful:

Accessibility 104 Images: The short and long of it
http://www.d.umn.edu/itss/training/online/images/

Example Long Text Alternative Markup
http://www.d.umn.edu/itss/training/online/moodle_downloads/accessibility_104/examples/long.html

Please fix this bug.

Comment 45

[Shelley Powers]

(In reply to Jennifer Morrow [:Boriss] (Firefox UX) from comment #39)
> Thank you for bringing this to our attention, Laura.  As one of Firefox's
> user experience designers unfamiliar with longdesc's historical context, I
> reviewed it for consideration.  After all, we're absolutely open to browser
> improvements, particularly that benefit users with screenreaders or
> disabilities.  But, I'm having trouble seeing that tangible benefit of
> longdesc to those or any other users.  Yes, images can absolutely benefit
> from longer descriptions (particularly if users cannot view the image), but
> is longdesc really a good way way to achieve this? 

Do you have a ready alternative? 
 
> 
> If we were to begin supporting longdesc - in a context menu, for instance -
> I expect very low adoption across the web.  This creates a very
> inconsistently-implemented solution for describing images - not something
> users with screenreaders could expect any given site to have implemented and
> not something any given site could expect users to be familiar with.  The
> result is that it works in a few cases to those who know about it, but
> mostly isn't used and isn't known about - it's an internet easter egg.
> 

Primarily because of low adoption by browsers. The HTML5 video and audio elements weren't particularly useful, either, until implemented by the browsers.

> Why do I expect low adoption across the web?  Mostly because there are so
> many better ways to provide a description.  Alt-text is short because it's
> simply meant to tell users what the image is - not provide meaningful
> artistic commentary or link to another site.  After all, there are so many
> much better ways to provide description, commentary, and links available to
> both users with screenreaders and without, I can't understand why longdesc
> would be a better method than any of those.  Basically, if a description of
> an image requires paragraphs of text or a whole link, why would a web author
> want to expose that to only the people that know about longdesc?  
> 

What are the ways? 

You're criticizing one approach that has accessibility support, use cases, implementation suggestions, but you're not providing an alternative. 

So, what's the superior alternatives?

> I'm not WONTFIX'ing this for now, because I'm genuinely just learning about
> longdesc now and perhaps I'm overlooking an important use case, particularly
> in the accessibility area.  If I have, please let me know what functionality
> means longdesc should be supported where other tools and options for
> exposing text aren't sufficient.

Alternatives? 

The only alternative I've seen is 'nothing'.

Comment 46

[John Foliot]

(In reply to Jennifer Morrow [:Boriss] (Firefox UX) from comment #39)
> Thank you for bringing this to our attention, Laura.  As one of Firefox's
> user experience designers unfamiliar with longdesc's historical context, I
> reviewed it for consideration.  
> 
> I'm not WONTFIX'ing this for now, because I'm genuinely just learning about
> longdesc now and perhaps I'm overlooking an important use case, particularly
> in the accessibility area.  If I have, please let me know what functionality
> means longdesc should be supported where other tools and options for
> exposing text aren't sufficient.

Hello Jennifer,

The use cases that leads to @longdesc all have 3 basic requirements: 1)discoverability, 2) the user option of consume or do not consume, and 3) the content consumed must support HTML richness (headings, list structure, etc.).

As Laura has pointed out, the second requirement (consume or not consume) means that under most circumstances longer complex textual descriptions should ideally be separate from the parent document of the complex image (think, for example, of an embedded info-graphic). This way, the additional content is only pulled to the user on demand (resulting in lighter page weights, faster transmission, etc.) - granted, text is fairly light anyway, but in the era of minification of even the smallest CSS or JS files, every byte counts (just ask the mobile guys <smile>)

Currently, the discoverability of @longdesc is fairly well handled by screen readers, who, when they encounter an image with longdesc, will usually announce the presence of the longer description and await user input (consume/skip). The lack of support we have today is primarily in the GUI interface, of which the "best" we have today is still contextual (right-click) menus, which already presumes that the end user is specifically hunting for the longer description already (the text-book scenario that Janina pointed to).  

To facilitate discoverability for sighted users then will require something that is not dependent on a screen reader, which one can only then conclude requires a visual indication of sorts. 

We have a few proof of concept examples of this type of visual indication, and the 2 basic models are either a) a (semi-transparent) on-screen indication (see: 1, 2, 3) or a chrome-based indication (see: 4). Since either/both solutions *do* have an impact on the authors original intended visual output (#4 less so), it would seem that the reasonable compromise is that any sort of indicator would be browser-based, and a user-selected option (likely) shipped with a default of "off", (as Mozilla currently does with DoNotTrack)

With the discoverability issue addressed, the right-click contextual menu solution does seem to have some merit: used in the wild, "longer descriptions" *ARE* contextual, tight binding with the element being "right-clicked", etc.

Thank you for your continued investigation. With the rapid progress of the extension specification at the W3C that covers this attribute, it would be very much in keeping with Mozilla's mission to remain a Standards Bearer in this regard. The community waits and watches with hopeful enthusiasm.

JF


1. https://addons.mozilla.org/En-us/firefox/addon/longdesk/

2. http://blog.ginader.de/dev/jquery/longdesc/examples/webaim/index.php (icon in bottom right corner of image, and an interesting implementation using AJAX and iFrame to render the textual equiv "in place" - food for thought)

3. http://ow.ly/i/22gKr (while not directly related to @longdesc, mobile browsers such as Dolphin {Android} are making use of semi-transparent watermarks with functionality today - again offered as a thought provoker more than a specific solution)

4. https://addons.opera.com/en/extensions/details/tellmemore/?display=en (and I keep telling chaals the icon puts the ugh back into ugly)

Comment 47

[Tony Mechelynck [:tonymec]]

I already had the following in userContent.css to make links more discoverable:

a[href]:hover
 { outline:                     2px solid red   !important
 }

Now I added the following two rules, which will certainly make longdesc attributes discoverable (for me, who have good sight when I have my glasses on) with no change to the rendering engine. After I restart the browser, I'll see if I like it:

*[longdesc]
 { outline:                     2px dashed green !important
 }
a[href][longdesc], a[href] *[longdesc]
 { outline                      2px solid green  !important
 }

For those who don't know, userContent.css (and userChrome.css) are "user CSS" style sheets which may exist (but don't by default) in the chrome subfolder of the profile folder of Mozilla applications (including Firefox, Thunderbird, SeaMonkey, and maybe others). userContent is for any web page's content, userChrome is for the browser's (or mailer's, etc.) menus, toolbars, buttons, etc.

Comment 48

[Nigel Peck]

Hi Tony,

Just thought I'd mention you're missing the colon from your last rule.

All the best,
Nigel

Comment 49

[Tony Mechelynck [:tonymec]]

(In reply to Nigel Peck from comment #48)
> Hi Tony,
> 
> Just thought I'd mention you're missing the colon from your last rule.
> 
> All the best,
> Nigel

ah, yes, right; thanks.

Comment 50

[Majken Connor [:Kensie]]

It sounds like this is almost an equivalent to described video which is available on my TV in the SAP options - http://en.wikipedia.org/wiki/Descriptive_Video_Service

Thinking about how much entertainment happens on the internet now, I can definitely see how this would be important for people to be able to fully participate. I also see how this is different from the descriptive text someone would include in the caption on an article (that always assumes the person can see the picture, but maybe doesn't recognize who's in it or where it was taken).

I imagine that right now most people who would include a longdesc would be businesses (news or media sites) that have good awareness and desire to include their visually impaired consumers (maybe those people who already provide the descriptions for their TV shows, eg). I think we're also not entirely far away from technology being able to provide some of the description as well with all the face recognition etc that's being used in social media (eg "this is a picture of a man and a woman with a chihuahua").

One solution to including more longdesc across the internet would be to have a mechanism, probably cloud based, to submit a description to content someone else has produced (like universal subtitles), though in that case it would make more sense to be an add-on.

Comment 51

[Laura Carlson]

Hi Majken,

(In reply to Majken Connor [Kensie] from comment #50)

> One solution to including more longdesc across the internet would be to have
> a mechanism, probably cloud based, to submit a description to content
> someone else has produced 

Check out Object Description: 
http://objectdescription.org/how-it-works.aspx

Comment 52

[John Foliot]

@Jennifer Morrow: Brendan Eich suggests that this bug is neither deadlocked nor livelocked - that it is in fact awaiting a response from you. (Ref: https://twitter.com/BrendanEich/status/339152195595407361)

Could you advise us of the status of this bug please? Thanks.

Also, worth noting is that the current "HTML5 Image Description Extension" has cleared the next hurdle, and is on its way to officially becoming part of HTML5. See: http://lists.w3.org/Archives/Public/public-html-admin/2013May/0117.html 

The time is now. :)

Comment 53

[John Foliot]

@bsmedberg - what info, if any, can the community provide you? Happy to help.

Comment 54

[David Bolter [:davidb] (NeedInfo me for attention)]

(In reply to John Foliot from comment #53)
> @bsmedberg - what info, if any, can the community provide you? Happy to help.

Hi John, if you are referring to the needinfo flag I believe Benjamin was setting that on your behalf so that the request shows up in jboriss' dashboard.

Comment 55

[John Foliot]

(In reply to David Bolter [:davidb] from comment #54)
> (In reply to John Foliot from comment #53)
> > @bsmedberg - what info, if any, can the community provide you? Happy to help.
> 
> Hi John, if you are referring to the needinfo flag I believe Benjamin was
> setting that on your behalf so that the request shows up in jboriss'
> dashboard.

Thanks David,

What is needed to make this move forward? Seriously? This should be an easy win, yet it feels like pulling teeth from a Grizzly Bear with a tooth ache.  

Need testers? We've got em. Need ideas, we've provided them. The UI team has outstanding questions? We're happy to try and answer them. 

We've appealed to Mozilla Community pride and Mozilla's Principles, we've pointed out that the Image Description spec is moving forward and will land this summer, we've pleaded, cajoled, tweeted, blogged, prayed, cried and smiled... What else is needed?  Will anyone at Mozilla stand up and say "Yes, let's just get this fixed"?

Our colleague Charles McCathieNeville, when he worked at Opera, bit the bullet and had Opera engineers add the basic support for longdesc that appears in Opera today. Total effort? Less than a developer day. Could it be better? Sure. Does it meet the basic requirement? Yes.

How do we challenge the Mozilla UI team to take this on as a creative challenge, and not something to get the accessibility community off their backs? What more can we do?

*****************
Principles: http://www.mozilla.org/en-US/about/manifesto/

Mozilla Principle #2: The Internet is a global public resource that must remain open and accessible.

  - Numerous persons with disabilities have explained how @longdesc improves the accessibility of complex images. Authors, such as Pearson Publishing, need a mechanism like @longdesc (and in fact are using @longdesc) to make eLearning texts accessible to non-sighted users. Major screen readers already support the attribute, but sighted users who might benefit from this same content remain shut out from a native Firefox solution.

Mozilla Principle #3: The Internet should enrich the lives of individual human beings.

  - See above. I want to highlight the word INDIVIDUAL in that statement. The @longdesc attribute won't bring world peace, nor solve global warming or even remember to take out the trash. Yet for those individuals who will benefit from its support, it will ENRICH their lives in many positive ways. Isn't that worth the effort? 

Mozilla Principle #5: Individuals must have the ability to shape their own experiences on the Internet.

 - The idea that this feature could be a user-controlled setting in Firefox has been suggested (https://bugzilla.mozilla.org/show_bug.cgi?id=854848#add_comment), and I believe would receive community support. This would easily address any visual impact on the default UI (in case this is a concern). Is this, BTW, an RFC 2119 MUST? (http://tools.ietf.org/html/rfc2119)

Mozilla Principle #8: Transparent community-based processes promote participation, accountability, and trust.

 - ...and here we have it. Many in the accessibility community have used your bugzilla system - including the up-vote process - to try and bring this issue forward. We've participated, but how do we measure your accountability? And how can we trust Mozilla when this issue seems to languish, to be batted back and forth from one group to another? Please Mozilla, what will it take to Just Get It Done?

Comment 56

[John Foliot]

s/ https://bugzilla.mozilla.org/show_bug.cgi?id=854848#add_comment / https://bugzilla.mozilla.org/show_bug.cgi?id=854848#c46

Comment 57

[David Bolter [:davidb] (NeedInfo me for attention)]

I told myself I wouldn't clutter this bug but let me say a few things.

It really isn't an 'us vs them' thing and the community lines blur.

I'm removing [need a11y team consensus] from the whiteboard since we've talked enough and opinions range but with no champion emerging. Personally I'd be excited to see a slick patch (as per my comment 2) and move on. I really do appreciate all the time taken (in fact the time taken makes me sad) to provide supporting data (such as Pearson adoption) and I really do hear the frustration.

As for status update: earlier today Jennifer and I connected over IRC but my dental appointment got in the way. Picking it back up tomorrow. If you don't see anything here in 5 days please ping me directly. (Aside: I worry about the correlation between a bug reports comment length and its fix success rate.)

One thing I'd ask is that nobody think that Mozilla's history with longdesc equates to Mozilla's commitment to accessibility. We've got lots happy stuff on the go!

Comment 58

[John Foliot]

(In reply to David Bolter [:davidb] from comment #57)
 
> I'm removing [need a11y team consensus] from the whiteboard since we've
> talked enough and opinions range but with no champion emerging.

That appears to be a positive step. Thanks! (Here's a thought: the *community* is the emergent champion here - how about everyone listen to that champion, and revisit the Mozilla Principles I outlined above?)

> Personally
> I'd be excited to see a slick patch (as per my comment 2) and move on. I
> really do appreciate all the time taken (in fact the time taken makes me
> sad) to provide supporting data (such as Pearson adoption) and I really do
> hear the frustration.

The question remains, does anyone else hear that frustration? Over the weekend, Brendan Eich placed this at your feet (https://twitter.com/BrendanEich/status/339146305194586112), but does he and others at Mozilla get this? That it is important? Not world peace important, but INDIVIDUAL important? That it delivers real benefit to real users? That if Mozilla does this right they will be Industry Leaders (again?). Does any of that matter?

> 
> As for status update: earlier today Jennifer and I connected over IRC but my
> dental appointment got in the way. Picking it back up tomorrow. If you don't
> see anything here in 5 days please ping me directly. (Aside: I worry about
> the correlation between a bug reports comment length and its fix success
> rate.)

Thanks for that too, and date noted in my calendar (the new catch phrase here is Patient but Persistent). As for "bug reports comment length"... an easy way to resolve that is to get the bug fixed :)

> 
> One thing I'd ask is that nobody think that Mozilla's history with longdesc
> equates to Mozilla's commitment to accessibility. 

If anything David, it is the main source of confusion and frustration, at least for me. With the exemplary support for accessibility related issues normally displayed by Mozilla, it is bewildering why something so simple, such a "slam dunk" obvious need for a fix, should still languish and be treated this way.

OK, we sit back and watch, and wait (some more). Patient but Persistent.

Comment 59

[Jennifer Morrow [:Boriss] (UX)]

After further looking into this, we've decided to support the longdesc attribute in Firefox.  

While we've considered longdesc in the past, the landscape has changed and there are reasons to support it now.  For one, the W3C validator now supports it, making it more likely to be supported across browsers.  Authors who want to make pages accessible may not be able to rely on longdesc on any browser, but there isn't presently another standardized option available.  And, importantly, it can be implemented without disrupting the user experience of users who don't require it.  Underscoring all of this is that the Mozilla project is a community, and our actions must reflect the needs and wants of the community.

There is a chicken and egg issue here, as Alastair notes in comment 20.  Supporting longdesc means that the door to wider adoption is open, and perhaps authors will surprise us with innovative uses of this attribute once they feel freer to do so.  And, perhaps in time better solutions to some of the problems longdesc tackles will emerge.  While we'll always be open to browser improvements, particularly in the accessibility space, we shouldn't ignore a ready solution because it's not perfect.

I've opened Bug 877453 for the implementation of the longdesc attribute and am dup'ing this one.

Comment 60

[Catherine Roy]

(In reply to Jennifer Morrow [:Boriss] (Firefox UX) from comment #59)
> After further looking into this, we've decided to support the longdesc
> attribute in Firefox.  

[snip]

Hello Jennifer,

Let me be the first to thank and congratulate you, your colleagues and Mozilla for this decision. Y'all rock !

Best,

Catherine

Comment 61

[Laura Carlson]

(In reply to Jennifer Morrow [:Boriss] (Firefox UX) from comment #59)

> After further looking into this, we've decided to support the longdesc
> attribute in Firefox.  

Deepest thanks Jennifer.

Comment 62

[Laura Carlson]

Hi Jennifer,

(In reply to Laura Carlson from comment #61)
> (In reply to Jennifer Morrow [:Boriss] (Firefox UX) from comment #59)

> I've opened Bug 877453 for the implementation of the longdesc attribute and am 
> dup'ing this one.

A quick question:

Will the people who voted for this bug automatically continue to receive updates on the new bug 877453? I'm getting them but have heard that others aren't.

Thank you.

Comment 63

[EddyCarr]

Hi Laura,

I believe the answer is 'No'. Anyone wanting to get email updates on the new bug should add themselves to the CC list on bug 877453. There are currently 5 people on it.

Comment 64

[Jennifer Morrow [:Boriss] (UX)]

(In reply to Laura Carlson from comment #62)
> Hi Jennifer,
> 
> (In reply to Laura Carlson from comment #61)
> > (In reply to Jennifer Morrow [:Boriss] (Firefox UX) from comment #59)
Eddy's right in Comment 63.

I also want to note for those on this thread that Bug 877453 is for design and patch creation only - not discussion of the merits of longdesc generally.  Please only comment on that bug if you're involved in its implementation.  Thanks!

Comment 65

[Laura Carlson]

Hi Jennifer and all,

>>> (In reply to Jennifer Morrow [:Boriss] (Firefox UX) from comment #59)

> Eddy's right in Comment 63.

Thanks for the confirmation.

> I also want to note for those on this thread that Bug 877453 is for design
> and patch creation only - not discussion of the merits of longdesc
> generally.

That's terrific. I am very please we are past that stage.

> Please only comment on that bug if you're involved in its
> implementation.  

I copied the links to the test cases to the new Bug. 
https://bugzilla.mozilla.org/show_bug.cgi?id=877453#c5

We will probably need testers for the new implementation so those who can help in that aspect may want to cc themselves on the new longdesc Bug 877453. Thanks!

Comment 66

[Laura Carlson]

(Jennifer Morrow [:Boriss] (Firefox UX) from comment #59)

> After further looking into this, we've decided to support the longdesc
> attribute in Firefox.  
..
> I've opened Bug 877453 for the implementation of the longdesc attribute and
> am dup'ing this one.

I am reopening this bug because Bug 877453: "Expose longdesc in image context menus" is not a full duplicate of this bug. While the context menu bug is an excellent step, it has come to light that that bug has a narrow scope and does not include implementing longdesc discoverability or keyboard support i.e., "Changes to overall focus are out of scope for this particular bug."
https://bugzilla.mozilla.org/show_bug.cgi?id=877453#c9

The requirements now have been split among three separate bugs per David Bolter's recommendation:  
https://bugzilla.mozilla.org/show_bug.cgi?id=877453#c14
Thanks David!

The bugs are:

Bug 884926 - Provide longdesc keyboard support
https://bugzilla.mozilla.org/show_bug.cgi?id=884926

Bug 884927 - Provide longdesc discoverability
https://bugzilla.mozilla.org/show_bug.cgi?id=884927

Bug 877453 - Expose longdesc in image context menus
https://bugzilla.mozilla.org/show_bug.cgi?id=877453

Please heed David's request to try not to make the comment scroll too long on those bugs.

Anyway, this umbrella Bug 854848 "Supporting the longdesc attribute" depends upon all three of the a fore mentioned bugs being fixed successfully and will help insure necessary requirements are cohesively tracked for Firefox's longdesc implementation.

Comment 67

[Laura Carlson]

In Comment 59 Jennifer said:
"After further looking into this, we've [Mozilla] decided to support the longdesc attribute in Firefox."  
https://bugzilla.mozilla.org/show_bug.cgi?id=854848#c59

An update: The context menu Bug 877453 has been fixed. That is an excellent start in Mozilla beginning to support longdesc.

However, apparently the full longdesc issue was not understood resulting in the issue being one third resolved WONTFIX (Bug 884927 discoverability) and one third not yet addressed (Bug 884926 keyboard accessibility). These important aspects of longdesc should not be rejected or ignored.

Fixing this Bug 854848 is dependent on Mozilla fully supporting the W3C HTML Image Description Specification by fixing all three bugs thereby finishing the other two thirds of the job.

Comment 68

[ytrezq]

For those who are wondering how to implement it without using the context menu, the test case of this bug can provide a good example once it will be fixed : #1203282

Comment 69

[ytrezq]

Sorry https://bugzilla.mozilla.org/show_bug.cgi?id=1203282

Comment 70

[ytrezq]

Oh looks like I wrong about security in https://bugzilla.mozilla.org/show_bug.cgi?id=1203282.

Comment 71

[Jonathan Watt [:jwatt]]

Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)

Comment 72

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 123 votes.
:Jamie, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 73

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.