884927 - Provide longdesc discoverability

Status: RESOLVED WONTFIX

(Firefox :: Disability Access, defect)

Description

[Laura Carlson]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:21.0) Gecko/20100101 Firefox/21.0 (Beta/Release)
Build ID: 20130511120803

Steps to reproduce:

Tried to discover the longdesc attribute for an image element. 

Test cases:
http://www.d.umn.edu/~lcarlson/research/ld-tests/tests/

They include the following 5 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

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

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


Actual results:

No visual affordance provided.


Expected results:

The browser should supply a way of obtaining a longdesc according to the specification, which states, "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-20130606/#user-agents

Providing longdesc discoverability serves 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. 

Innovative browser vendors provide ways that make longdesc discoverable:
http://www.d.umn.edu/~lcarlson/research/ld-ua.html
I expect that Mozilla  UX Team could develop those ideas into a great implementation.

As John Foliot said in Bug 854848, "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)"
https://bugzilla.mozilla.org/show_bug.cgi?id=854848#c46

Notes:

1. This bug is being filed to help fully complete the successful resolution of "Support the longdesc attribute", which is Bug 854848. Bug 854848 was filed with one of the expected results being that "User agents should enable users to discover when images in a page contain a long description." 

2. This bug is being filed per David Bolter's [:davidb]: recommendation
https://bugzilla.mozilla.org/show_bug.cgi?id=877453#c14

Comment 1

[Jennifer Morrow [:Boriss] (UX)]

The reason for adding longdesc to an image's context menu is that it constitutes metadata - data about data.  Metadata for the web is made available by Firefox in a number of places - the Page Info and View Source, for instance.  Making metadata available is important towards the goal of keeping the web open.  

But, browsers don't tend to expose metadata in the pages themselves because rendering pages as closely to how the authors intended is ultimately the core functionality of a web browser.  Changing how images and pages elements actually render essentially overrides the design decisions the authors of the page made made.  

The link in the description shows some innovative ways of exposing longdesc via add-ons and favelets.  These are great tools for using and viewing longdesc, and I hope (and expect) we'll see more in the future

Comment 2

[Laura Carlson]

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

Hi Jennifer,

> But, browsers don't tend to expose metadata in the pages themselves
> because rendering pages as closely to how the authors intended is
> ultimately the core functionality of a web browser.  Changing how
> images and pages elements actually render essentially overrides the
> design decisions the authors of the page made.

I absolutely agree that a forced visual encumbrance of a longdesc could be a critical and significant constraint for designers, visual artists, and marketers because of usability and aesthetics. The specification honors this constraint and requires no visual encumbrance.
http://www.w3.org/TR/2013/WD-html-longdesc-20130606/#requirements 

Discoverability does not have to be on the page itself. An icon in the chrome or address bar could indicate when descriptions exist:
http://www.d.umn.edu/~lcarlson/research/ld-ua.html#globalicon 
https://addons.opera.com/en/extensions/details/tellmemore/?display=en

Or discoverability could be handled via a native browser preference where a person would choose to have discoverability of longdesc enabled. This would seem to fit under "Accessibility" in the "General" preference tab. Or  an option could even fit under the main "View" menu. If selected an icon indicator or a link or highlighting could afford discoverability directly on-page with the users permission. 

As  stated in the bug description, allowing for discoverability serves a number use cases. The fact is that some people need to consume or access long description content but do not use a screen reader. 

Jennifer, will you please reconsider and allow this bug to be fixed? As David Bolter said back in March "The UI parts are more interesting since this could lead to more actual usage in the wild."
https://bugzilla.mozilla.org/show_bug.cgi?id=854848#c2

Adding some way for longdesc to be discoverable would also help complete Mozilla's longdesc implementation.

Comment 3

[Jennifer Morrow [:Boriss] (UX)]

(In reply to Laura Carlson from comment #2)
> Or discoverability could be handled via a native browser preference where a
> person would choose to have discoverability of longdesc enabled. This would
> seem to fit under "Accessibility" in the "General" preference tab.

> As  stated in the bug description, allowing for discoverability serves a
> number use cases. The fact is that some people need to consume or access
> long description content but do not use a screen reader. 

While I understand your point, but discoverability and accessibility are different things.  Accessibility, as we see it, means making the web available to as many people as possible, despite any conditions that make this more difficult for some than others.  As longdesc is accessible to non-sighted users, it's unclear what case could be made that visual indications of longdesc constitute accessibility improvements.

Comment 4

[Laura Carlson]

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

Hi Jennifer,

(In reply to Jennifer Morrow [:Boriss] (Firefox UX) from comment #3)
> While I understand your point, but discoverability and accessibility 
> are different things.  Accessibility, as we see it, means making the 
> web available to as many people as possible, despite any conditions 
> that make this more difficult for some than others.  As longdesc is 
> accessible to non-sighted users, it's unclear what case could be made 
> that visual indications of longdesc constitute accessibility 
> improvements.

Discoverability can aid accessibilty. Without a discoverability affordance it would be a tedious, tiring, horrible experience for people who already face unique challenges and barriers to hunt for the existence of a longdesc via a context menu. Longdesc can be essential for users who need or would like textual reinforcement when deciphering the contents of a complicated image.  For instance in this bug's description I listed a number of particular user groups who would benefit from Mozilla providing longdesc discoverability.  I'll try to explain a bit more regarding use cases for people with low vision, cognitive disorders, learning disabilities as well as those same people who are additionally impacted by mobility impairments. 

LOW VISION

Not all people with visual impairments are totally blind and use a screen reader. Some people with visual impairments have what is known as low vision. Low vision is more common among the elderly, but it can occur in people of any age as a result of such conditions as macular degeneration, glaucoma, diabetic retinopathy, or cataracts. Individuals with low vision include those whose eyesight is deteriorating or has deteriorated. This means that a low vision user can sometimes make out graphical layout of a page but may find it less painful to use a text version of content such as longdesc that does not rely on images. People with low vision may not use a screen reader and would have no idea that an image has a longdesc without a discoverability affordance. They would be locked out.

COGNITIVE & LEARNING DISABILITIES

On the baseline, cognitive disorders are about the brain and problems understanding things. Accessibility for people with cognitive disabilities as well as and learning difficulties is typically one of the most overlooked topics of general web accessibility, despite it affecting the largest numbers. Cognitive impairments incorporate a wide variation of memory, perception, problem solving, and conceptualizing. Learning disabilities affect a person's ability to process information. In some cases, the individual has difficulties interpreting what is seen and would benefit from longdesc. In other cases, the individual can interpret the information but has difficulties making mental connections between different pieces of information. They may find it easier to understand textual information than pictorial content or find it easier to have access to pictorial content reinforced by textual content. All of these situations can benefit from well-written simple text, plain language longdescs with short sentences, simple punctuation and no jargon so that they may be more easily understood. Cognitive accessibility is giving users (or learners) equal access to content regardless of form or media. Like people with low vision people cognitive disorders and learning disabilities may not use a screen reader and would have no idea that an image has a longdesc without some sort of a discoverability affordance. They would be locked out.

LOW VISION, COGNITIVE OR LEARNING DISABILITIES IN COMBINATION WITH MOBILITY DISABILITIES

Moreover the previously mentioned users with low vision, cognitive or learning disables may *also* need to utilize specialized mobility accommodations to be able to navigate web content. These devices include but are not limited to assistive technology such as:

* Mouth-Stick: a device that enables a person to control input through a stick they control with their mouth. Someone with no use of the hands may use a mouth stick to type and perhaps to manipulate a trackball mouse, depending on the amount of control that the person has with the mouth stick, and on the amount of patience that the person has if these movements are difficult.
* Head-Wand: a device similar to a mouth stick, except the stick is strapped to the head.
* Blow-Suck Tube: a device that is placed in the mouth and blown through. It can be used in conjunction with a tongue-activated joystick to move a pointer around and make selections.
* Sip and Puff Switch: a device for users able to interpret the user's breath actions as on/off signals.
* Slow Keys: a keyboard feature that prevents keystrokes from registering until a key has been held down for a certain period of time. 
* Sticky Keys: a method of typing where modifier keys, such as Shift, Control, Command, and Alt/Option, will "stick" down and apply to the next keystroke.

Fatigue would be exacerbated in the case of a person with multiple disabilities who doesn't use a screen reader but uses other mobility accommodations locating images with longdescs if no visual affordance is provided. Without a longdesc discoverability affordance these users with multiple disabilities would be disenfranchised.

CONTENT DEVELOPERS

The Mozilla UX team seems to have no issue with adding all sorts of extra UI and features for another niche audiences such as developers. Content developers would benefit from discoverability of longdesc for development and testing longdescs.

WILL MOZILLA TAKE A LEADERSHIP ROLE & PROVIDE DISCOVERABILITY?

As you stated in your comment in Bug 854848:
> 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.

A context menu certainly provides a type of functionality to obtain the target of a longdesc. It is an excellent first step. However, higher adoption would require Mozilla to truly be open to browser improvements for discoverability and be innovative in providing a complete solution. This is where Mozilla can step up and take a leadership role. 

Jennifer, will you please reconsider and have this bug fixed?

Comment 5

[John Foliot]

(In reply to Jennifer Morrow [:Boriss] (Firefox UX) from comment #1)
> The reason for adding longdesc to an image's context menu is that it
> constitutes metadata - data about data. 

Jennifer, this is where you are very, VERY, wrong. Longdesc content is written text intended for human consumption, not machine consumption. 

The paragraph element is "metadata" as it is data about the data ("this string of text is a specific type of text - a paragraph"), yet for it to make sense to a human, it has an "additional line break" between blocks. Machines and systems that consume metadata (<p>) don't need that white space, but humans do. 

The anchor element <a> is also metadata: it indicates that a specific string of text enclosed inside of that element is actually a hyperlink to more text. This is the foundation of the web, yet machines that consume metadata (Google for example, heck every robot out there) doesn't need for those links to be underlined and in a different color, yet that is the default shipping state of every browser since Mosaic et. al. Why is that?

So too with the discoverability of @longdesc content. Failing to address this issue not only is a key component of the original bug, it is *THE* problem. Failing to address this is tantamount to saying, "we give up, its not important enough to work on".

> Metadata for the web is made
> available by Firefox in a number of places - the Page Info and View Source,
> for instance.  Making metadata available is important towards the goal of
> keeping the web open.  

Correct, which is why the default state for links is to have them a different color and underlined. Authors can change that (and so can users), but the default state, the state that ships, is to *clearly* indicated the presence of a hyper-link, which is what the value string for @longdesc is: <img src="URL string:path to image" longdesc="URL string: path to longer textual description">

> 
> But, browsers don't tend to expose metadata in the pages themselves because
> rendering pages as closely to how the authors intended is ultimately the
> core functionality of a web browser. 

Incorrect. See above: based upon what you are claiming, then the default state of underlined hyperlinks is "broken. Should I file a bug on that for you? 

Web browsers should allow for the end user and the author to modify their visual output according to their needs, but the real answer is that browsers should expose functionality as a default state setting. Many have already suggested that in the case of @longdesc, given legacy reasons, that reversing this (and making the visual discoverability function a user-setting to turn on, not off) would be a reasonable position - failing to do that would "break" many pages. But that should not absolve the responsibility of the browser to change the Status Quo, which is what your closing of this bug does.

> Changing how images and pages elements
> actually render essentially overrides the design decisions the authors of
> the page made made.  
> 
> The link in the description shows some innovative ways of exposing longdesc
> via add-ons and favelets.  These are great tools for using and viewing
> longdesc, and I hope (and expect) we'll see more in the future

How does the community re-open this bug? The end state remains broken due to a failure to understand the problem.

Comment 6

[Laura Carlson]

Attachment: Mockup: Longdesc Icon Button Example for the Firefox Navigation Toolbar

In reply to Comment 5:

> the real answer is that browsers should expose functionality as a 
> default state setting.

As mentioned in Comment 2 an icon in the chrome or address bar could expose functionality. A "Longdesc Icon Button Example for the Firefox Navigation Toolbar" is attached. The 900 x 1816 infographic image depicts the following four states:

1. No Descriptions Icon
If no longdesc attribute is present on a page the icon in the toolbar appears in the inactive state (a symbol of an eye with a line through it).

2. Descriptions Icon
If a longdesc attribute is present the icon in the toolbar appears in the active state (a symbol of an open eye).

3a. Active Descriptions Icon
When the user selects the open eye icon it appears embossed and an alert displays "Indicate Descriptions".

3b. Image is Identified
Each image with a longdesc attribute is highlighted by adding a border and a "D" icon super imposed upon a corner of the image. For example Chris Kennish's longdesc chrome plugin provides an array of longdesc highlighting preferences as discussed in bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=854848#8

4. Context Menu 
The context menu provides the user access to the description via the "View Description" option (Bug 884926).

Discoverability of longdesc should be similar to television closed captions. Closed-captions are encoded or invisible by default and must be decoded or made visible. There is a reason that closed captions (as opposed to open captions) are the default on televisions. Most people typically don't require them as they are visual noise. Clutter. Redundant information. However, whenever a  person needs or wants to enable closed captions he/she can do so via a mechanism (button on the remote or selection in the menu) built into the system.

Mozilla should provide that same type of functionality for people who need access to longdesc i.e., Comment 4.

Comment 7

[Laura Carlson]

Hi Jennifer,

Please this bug for reconsideration due to important information presented in Comment 4. 

Via attachment and comment I have supplied a "Mockup: Longdesc Icon Button Example for the FireFox Navigation Toolbar" 900x1880 infographic and explanation of how this bug could be fixed:
https://bug884927.bugzilla.mozilla.org/attachment.cgi?id=772007
https://bugzilla.mozilla.org/show_bug.cgi?id=884927#c6

In the original longdesc bug you 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

Please fulfill that statement and support longdesc by making it discoverable (this bug 884927) and keyboard accessible (Bug 884926). Thank you for fixing Bug 877453. That is a great start. Please do a complete job and finish the other two thirds of the job.

Comment 8

[Laura Carlson]

Hi Jennifer,

Please reopen this bug for reconsideration due to important information presented in Comment 4. 

Via attachment and comment I have supplied a "Mockup: Longdesc Icon Button Example for the FireFox Navigation Toolbar" 900x1880 infographic and explanation of how this bug could be fixed:
https://bug884927.bugzilla.mozilla.org/attachment.cgi?id=772007
https://bugzilla.mozilla.org/show_bug.cgi?id=884927#c6

In the original longdesc bug you 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

Please fulfill that statement and support longdesc by making it discoverable (this bug 884927) and keyboard accessible (Bug 884926). Thank you for fixing Bug 877453. That is a great start. Please do a complete job and finish the other two thirds of the job.

Comment 9

[Jennifer Morrow [:Boriss] (UX)]

(In reply to John Foliot from comment #5)
> (In reply to Jennifer Morrow [:Boriss] (Firefox UX) from comment #1)
> > The reason for adding longdesc to an image's context menu is that it
> > constitutes metadata - data about data. 
> 
> Jennifer, this is where you are very, VERY, wrong. Longdesc content is
> written text intended for human consumption, not machine consumption. 

What I mean by metadata is that it provides information about other data (in this case,  images), not that it's not meant to be read only by machines.  The date a photo was taken and the camera used, for instance, are also forms of metadata.

> > But, browsers don't tend to expose metadata in the pages themselves because
> > rendering pages as closely to how the authors intended is ultimately the
> > core functionality of a web browser. 
> 
> Incorrect. See above: based upon what you are claiming, then the default
> state of underlined hyperlinks is "broken. Should I file a bug on that for
> you? 

By the same token, rendering text itself could be considered as a design decision.  That's why web authors can specify the rendering of text, links, and styles themselves, and particularly those interested in achieving a specific look and feel on their sites usually do.

> How does the community re-open this bug? The end state remains broken due to
> a failure to understand the problem.

While I'm sorry you feel that way, I'd point out that the recently closed bug 877453 exposes longdesc in Firefox for the first time.  There will always be disagreements about how particular features in Firefox are designed and exposed, but ultimately the user experience team tries to design simply and consistently, making what are often tough design decisions in an effort to improve the web and its use.  The design process will always lead to some users being happier with some decisions than others depending on what they like and use.  However, this is precisely why Firefox counts extensibility among its values.  Open source means that users *can* do whatever they like with our code, from creating add-ons that support use cases to forking Firefox into an entirely new version.  As an aside, I'm happy to help anyone who'd like to build an add-on or create a new version of Firefox entirely.

(In reply to Laura Carlson from comment #8)
> Please reopen this bug for reconsideration due to important information
> presented in Comment 4. 

Some very important accessibility scenarios are presented in Comment 4.  We're absolutely dedicated to accessibility, and have many tools and features to help with poor and no vision as well as assistive technology.  These tools apply to the whole web, including the pages and text that longdesc links to.  A user with poor or low vision is just as able to see a longdesc page at magnified size, for instance, as a regular page.  The special casing of longdesc over other accessibility tools - regular desc, for instance - would put Firefox in a somwhat inconsistent state of highlighting some descriptions and not others.  Thanks again for the feedback.

Comment 10

[John Foliot]

(In reply to Jennifer Morrow [:Boriss] (Firefox UX) from comment #9)
> (In reply to John Foliot from comment #5)
> > (In reply to Jennifer Morrow [:Boriss] (Firefox UX) from comment #1)
> > > The reason for adding longdesc to an image's context menu is that it
> > > constitutes metadata - data about data. 
> > 
> > Jennifer, this is where you are very, VERY, wrong. Longdesc content is
> > written text intended for human consumption, not machine consumption. 
> 
> What I mean by metadata is that it provides information about other data (in
> this case,  images), not that it's not meant to be read only by machines. 
> The date a photo was taken and the camera used, for instance, are also forms
> of metadata.

The confusion you seem to be having is in referencing the prose supplied for the long description as "data". Saying all data is data is indeed a truism, but misses the point; this particular data is not data "about" the image, it is an *alternative presentation* of the image, and most certainly not metadata. 


> > > But, browsers don't tend to expose metadata in the pages themselves because
> > > rendering pages as closely to how the authors intended is ultimately the
> > > core functionality of a web browser. 
> > 
> > Incorrect. See above: based upon what you are claiming, then the default
> > state of underlined hyperlinks is "broken. Should I file a bug on that for
> > you? 
> 
> By the same token, rendering text itself could be considered as a design
> decision.  That's why web authors can specify the rendering of text, links,
> and styles themselves, and particularly those interested in achieving a
> specific look and feel on their sites usually do.

It is also why browsers allow end-users to over-ride author supplied styling information (Firefox: Tools >> Options >> Content >> Fonts and Colors >> Advanced >> [deselect] "Allow pages to choose their own fonts, instead of my selections above"). You can spend 40+ hours working up a color pallet and visual "design language", and the end user can dismiss that by simply making a single change to the Firefox browser. Out goes your carefully selected Web-Font, on comes Comic Sans (http://thenextweb.com/dd/2011/06/02/comic-sans-may-improve-your-reading-retention-says-study/).

It is at this level of functionality that this bug is seeking to resolve, as it is going to become a standards requirement in the HTML5 Image Description extension, now at Last Call at the W3C. That document states:

  3.0.3 User Agents

  If the longdesc value is valid, User agents MUST make the link
  available to all users through the regular user interface(s). 

  If the longdesc value is valid, User agents MUST 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.

Source: http://www.w3.org/TR/html-longdesc/#user-agents

Note that these requirements are written referencing the IETF's RFC2119 "MUST, SHOULD, MAY" definitions (http://www.ietf.org/rfc/rfc2119.txt). 

The definition of SHOULD states:

   "SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course."

I refer you to the 3rd requirement - "User agents SHOULD enable users to discover when images in a page contain a long description." and ask you, have you resolved this requirement? Do you *really* understand the full implications of your actions here? That you have strongly weighted reasons to not resolve this bug? Do you believe that the best you can ever offer is a user moving their mouse around the page, right clicking every image in search of a long description; and that this meets the letter and spirit of the Standard? How so? Is that, in your opinion, a good user-experience? Is that something that Firefox should point to with pride?


> 
> > How does the community re-open this bug? The end state remains broken due to
> > a failure to understand the problem.
> 
> While I'm sorry you feel that way, I'd point out that the recently closed
> bug 877453 exposes longdesc in Firefox for the first time. 

Incorrect, please review your history. It now adds the actual actionable clicking to the url presented: (much) earlier versions of Firefox would expose/render the link in the contextual menu, but at that time it was not rendered as a link, only a text string.

As well, that is only a partial fix to the parent bug, which clearly stated that the discoverability feature is and was also a requirement. 


> always be disagreements about how particular features in Firefox are
> designed and exposed, but ultimately the user experience team tries to
> design simply and consistently, making what are often tough design decisions
> in an effort to improve the web and its use. 

How does this decision improve the web? Please do elaborate, as there are a ton of questions that the community has no answers for at this time. You claim you've made some tough decisions (with no indication of what they were, nor what fueled your decision process), and have decided that you know better than the community what needs to happen here. Do we have a right to ask why?


> The design process will always
> lead to some users being happier with some decisions than others depending
> on what they like and use. 

Interesting political spin. Can you point us to *any* users who are happy with the current resolution? (WON'T FIX) You've ignored the biggest problem brought forward: the ability for a sighted user to know that long descriptions are present on any given image, reducing it to a "Where's Waldo" exercise.


> However, this is precisely why Firefox counts
> extensibility among its values.  Open source means that users *can* do
> whatever they like with our code, from creating add-ons that support use
> cases to forking Firefox into an entirely new version.  As an aside, I'm
> happy to help anyone who'd like to build an add-on or create a new version
> of Firefox entirely.

What a very polite blow-off. Thanks for your eloquence.


>(In reply to Laura Carlson from comment #8)
> > Please reopen this bug for reconsideration due to important information
> > presented in Comment 4. 
>
> Some very important accessibility scenarios are presented in Comment 4. 
> We're absolutely dedicated to accessibility, and have many tools and
> features to help with poor and no vision as well as assistive technology.
>  These tools apply to the whole web, including the pages and text that
> longdesc links to.  A user with poor or low vision is just as able to see
> a longdesc page at magnified size, for instance, as a regular page.  The
> special casing of longdesc over other accessibility tools - regular desc,
> for instance - would put Firefox in a somwhat inconsistent state of
> highlighting some descriptions and not others.  Thanks again for the
> feedback.

Your response is just another clear indication that you are failing to understand the problem here. Of course a low-vision user can zoom on the longer description page, its just a web page. 

HOW DOES THE LOW VISION USER KNOW THAT THE LONGER DESCRIPTION EXISTS IN THE FIRST PLACE? 

Your current solution is to have that user pan around the image, and then right click every image and hope that the long description is there. (As an aside, what is the "regular desc"? Are you perhaps thinking of the @alt attribute, which provides the AccessibleName to the Accessibility APIs, as opposed to the AccessibleDescription to those same APIs - which is the role of the @longdesc attribute?)

If you are "...absolutely dedicated to accessibility..." then listen very carefully to the feedback: this *IS* a special case, you *are* failing accessibility here, clearly, significantly, and willfully. Not fixing this bug is hurting a significant number of the population, whether you are prepared to admit it or not.

The community has already noted that an overly intrusive mechanism cannot emerge, that is understood. But just as any user can over-ride every web page to render using Comic Sans, so too they should be able to turn on a Firefox feature that that advises them when @longdesc is present on the page. Offers of extensions and forking Firefox are insincere dismissals of this problem.

Comment 11

[Laura Carlson]

Hi Jennifer,

> (In reply to Laura Carlson from comment #8)
> > Please reopen this bug for reconsideration due to important information
> > presented in Comment 4. 
> 
> Some very important accessibility scenarios are presented in Comment 4. 

Did you read that whole comment?

> We're absolutely dedicated to accessibility, and have many tools and
> features to help with poor and no vision as well as assistive technology. 

That's great to know.

> These tools apply to the whole web, including the pages and text that
> longdesc links to. 

Yes indeed. That is why longdesc discoverability is so important.

> (In reply to John Foliot comment #10)

> HOW DOES THE LOW VISION USER KNOW THAT THE LONGER DESCRIPTION EXISTS IN THE FIRST PLACE? 

Yes indeed, John. As stated in Comment 4 the same thing applies to people with learning disabilities and cognitive disorders. 

Jennifer, did you read all of Comment 4? Please do not lock out people with low vision or people with learning disabilities  or cognitive disorders from obtaining a longdesc. Please fix this bug and show that Mozilla is actually dedicated to accessibility.

Again, via attachment and comment I have supplied a "Mockup: Longdesc Icon Button Example for the FireFox Navigation Toolbar" 900x1880 infographic and explanation of how this bug could be fixed:
https://bug884927.bugzilla.mozilla.org/attachment.cgi?id=772007
https://bugzilla.mozilla.org/show_bug.cgi?id=884927#c6