884926 - Provide longdesc keyboard support

Status: UNCONFIRMED

(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 obtain the longdesc attribute for an image element via the keyboard. Some 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 keyboard support was provided.


Expected results:

The ability to obtain a longdesc via the keyboard should have been provided.

The browser should supply a way of accessing a longdesc according to the specification, which states, "If the longdesc value is valid, User agents must make the link available to all users through the regular user interface(s)."
http://www.w3.org/TR/2013/WD-html-longdesc-20130606/#user-agents
This requirement includes keyboard users who who are sighted or partially sighted but do not use a screen reader.
 
Providing longdesc keyboard support 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. The fact is that some people may want or need to consume or access long description content but do not use screenreaders but rather use either a keyboard or pointing device without screen reader or assistive technology.

As Patrick H. Lauke said, "This  will require a change to the way focus is given, i.e. include images with a longdesc attribute into the regular tab cycle? Either by default, or having it as a checkbox preference under accessibility settings? Otherwise, this only benefits mouse users."
https://bugzilla.mozilla.org/show_bug.cgi?id=877453#c2

Steve Faulkner suggested on Rebuilding the Web, "In regards to displaying a context menu for images, the simple suggestion is to add tabindex=0 which puts them in the tab order."
http://rebuildingtheweb.com/en/how-is-accessibility-made/#c20130522033556

Notes:

1. This bug is being filed to help fully complete 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 make the link available to all users through the regular user interface." 

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

Comment 1

[Laura Carlson]

The types of mobility accommodations that people with mobility disabilities use to navigate web content include but are not limited to assistive technology such as:

* 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.
* 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.
* Head-Wand: a device similar to a mouth stick, except the stick is strapped to the head.

Without keyboard support these users would be locked out from access to a longdesc.

Please consult Bug 884927#c4 for use case details for people with low vision, cognitive disorders and learning disabilities who are additionally impacted by mobility impairments. 
https://bugzilla.mozilla.org/show_bug.cgi?id=884927#c4

Comment 2

[Jennifer Morrow [:Boriss] (UX)]

There actually is keyboard support for context menus in Firefox.  The context menu can be accessed via the keyboard using ctrl-space on the focused element, then pressing down arrow to move through the context menu items.  Pressing enter when the description element is selected will open the long description of an image.

Comment 3

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

Heyo. I think the crux of this bug is about how to get focus to the image in the first place. For example, treating as tabindex=0.

Comment 4

[Joseph Scheuhammer (:clown)]

(In reply to Jennifer Morrow [:Boriss] (Firefox UX) from comment #2)
> There actually is keyboard support for context menus in Firefox.  The
> context menu can be accessed via the keyboard using ctrl-space on the
> focused element, ...

That is part of the issue:  how to put focus on the element with @longdesc.

Comment 5

[steve faulkner]

(In reply to Joseph Scheuhammer from comment #4)
> (In reply to Jennifer Morrow [:Boriss] (Firefox UX) from comment #2)
> > There actually is keyboard support for context menus in Firefox.  The
> > context menu can be accessed via the keyboard using ctrl-space on the
> > focused element, ...
> 
> That is part of the issue:  how to put focus on the element with @longdesc.

The simplest and most robust method would be to include an image with @longdesc in the default tab order, what is the issue with implementing this?

Comment 6

[Joseph Scheuhammer (:clown)]

(In reply to steve faulkner from comment #5)
> (In reply to Joseph Scheuhammer from comment #4) 
> > That is part of the issue:  how to put focus on the element with @longdesc.
> 
> The simplest and most robust method would be to include an image with
> @longdesc in the default tab order, what is the issue with implementing this?

Compare the experience with clicking right on whitespace to invoke a context menu.  If users manage to move focus to the entire document, one can invoke the same context menu by ctrl-space.  The "focus on the entire document" appears to be focus on the <body> element.

IMHO, placing the <img> with @longdesc into the default tab order is the same as  the existent practice of placing the <body> in the tab order.

Comment 7

[Laura Carlson]

Hi Jennifer,

(In reply to Jennifer Morrow [:Boriss] (Firefox UX) from comment #2)
> There actually is keyboard support for context menus in Firefox.  The
> context menu can be accessed via the keyboard using ctrl-space on the
> focused element, then pressing down arrow to move through the context menu
> items.  Pressing enter when the description element is selected will open
> the long description of an image.

Did you mean that you actually tried to obtain a longdesc on the test page and you were able to obtain the text description via keyboard? 

For instance using the keyboard only with are you able ctrl-space and arrow down to obtain the description[1] from the first image on the test page[2]? Or on any of those images?

I sure can't make it work. Can anyone else?

[1] http://www.d.umn.edu/~lcarlson/research/ld-tests/assets/ld/graph.html
[2] http://www.d.umn.edu/~lcarlson/research/ld-tests/tests/

Comment 8

[Jennifer Morrow [:Boriss] (UX)]

(In reply to David Bolter [:davidb] from comment #3)
> Heyo. I think the crux of this bug is about how to get focus to the image in
> the first place. For example, treating as tabindex=0.

Indeed - how do screenreaders handle this for regular images with regular descriptions, if at all?  I'm assuming some operate on more elements of the page than default tab order.

Comment 9

[steve faulkner]

(In reply to Jennifer Morrow [:Boriss] (Firefox UX) from comment #8)
> (In reply to David Bolter [:davidb] from comment #3)
> > Heyo. I think the crux of this bug is about how to get focus to the image in
> > the first place. For example, treating as tabindex=0.
> 
> Indeed - how do screenreaders handle this for regular images with regular
> descriptions, if at all?  I'm assuming some operate on more elements of the
> page than default tab order.

Hi Jennifer, there appears to be an ongoing disconnect in understanding. Keyboard access is not about supporting screen reader users, its about supporting users who cannot use a mouse, many of whom do not use an AT at all.

Comment 10

[Jennifer Morrow [:Boriss] (UX)]

(In reply to steve faulkner from comment #9)
> (In reply to Jennifer Morrow [:Boriss] (Firefox UX) from comment #8)
> > (In reply to David Bolter [:davidb] from comment #3)
> > > Heyo. I think the crux of this bug is about how to get focus to the image in
> > > the first place. For example, treating as tabindex=0.
> > 
> > Indeed - how do screenreaders handle this for regular images with regular
> > descriptions, if at all?  I'm assuming some operate on more elements of the
> > page than default tab order.
> 
> Hi Jennifer, there appears to be an ongoing disconnect in understanding.
> Keyboard access is not about supporting screen reader users, its about
> supporting users who cannot use a mouse, many of whom do not use an AT at
> all.

I understand that, I was asking about screenreaders specifically because I'm not very familiar with how they operate.

Comment 11

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

(In reply to Jennifer Morrow [:Boriss] (Firefox UX) from comment #8)
> (In reply to David Bolter [:davidb] from comment #3)
> > Heyo. I think the crux of this bug is about how to get focus to the image in
> > the first place. For example, treating as tabindex=0.
> 
> Indeed - how do screenreaders handle this for regular images with regular
> descriptions, if at all?  I'm assuming some operate on more elements of the
> page than default tab order.

Yes that is the right intuition. We expose an accessibility tree (which we build from the dom/content, and frame trees). Each node is an accessibility object with numerous properties. Additionally we expose a way for screen readers to get more directly to the raw DOM (ISimpleDOM) but this isn't encouraged. In the end screen readers can solve a lot of things for their consumers.

As Steve mentioned we like to solve for sighted keyboard users, and this gets us a bit closer to universal/inclusive design which covers a broader spectrum of (dis)ability.