Closed Bug 877453 Opened 11 years ago Closed 11 years ago

Expose longdesc in image context menus

Categories

(Core :: Disability Access APIs, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla25

People

(Reporter: jboriss, Assigned: maxli)

References

(Blocks 1 open bug)

Details

(Keywords: access, dev-doc-needed)

Attachments

(2 files)

Adding longdesc to the context menu on images (for context, see Bug 854848).  Longdesc would not appear if the image has none.  

The second segment of items in the context menu deals with image-specific data, so that's probably the right place for it.  Under "View Image Info," new string should be "View Description."  Longdesc URL would then open in the current tab.  The reason for the same tab rather than a new one or a pop-up is to be consistent with the most similar current context menu item, "View Image," which also opens the image in the same tab.  We may want to have both of these open in different tabs later, but for now, let's make longdesc as consistent as we can with similar menu items.
To make this useful to keyboard users as well, I guess 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.
(In reply to Jennifer Morrow [:Boriss] (Firefox UX) from comment #0)
> Created attachment 755660 [details]
> Mockup: Longdesc added to image context menu
> 
> Adding longdesc to the context menu on images (for context, see Bug 854848).
> Longdesc would not appear if the image has none.  
> 
> The second segment of items in the context menu deals with image-specific
> data, so that's probably the right place for it.  Under "View Image Info,"
> new string should be "View Description."  Longdesc URL would then open in
> the current tab.  The reason for the same tab rather than a new one or a
> pop-up is to be consistent with the most similar current context menu item,
> "View Image," which also opens the image in the same tab.  We may want to
> have both of these open in different tabs later, but for now, let's make
> longdesc as consistent as we can with similar menu items.
"We may want to have both of these open in different tabs later" note that longdesc can potentially also point to a fragment identifier in the same page as the image (a n early form of aria-describedby I guess). See for instance the demo page[1] for my humble Fx longdesc extension[2]

[1] http://www.splintered.co.uk/experiments/archives/firefox_longdesc_extension/
[2] https://addons.mozilla.org/en-US/firefox/addon/longdesc/
Some longdesc test cases are at:
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
(In reply to Patrick H. Lauke from comment #2)
> To make this useful to keyboard users as well, I guess 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.

Images themselves are not a default part of the Firefox tab focus cycle - is focus used differently by many screen reader users, or does it tend to be set in a non-default arrangement?  It seems inconsistent for a tab focus cycle used by screen-reader users to ignore all images except those with the longdesc attribute.  Perhaps someone who's familiar with standard screen-reader use can weigh in here.  But yes, any browser behavior that should be different for screen-reader use could be added to the General/Accessibility Preference menu.
To be clearer, my comment wasn't particularly about screen-reader users, but sighted users with a keyboard.

When running a screen-reader, images aren't normally added to the focus cycle either. However, SRs offer a variety of ways (in addition to conventional TAB/SHIFT+TAB) to navigate content...reading the whole content top to bottom, working from one word/block to the next etc. And even now, without the addition of this context menu item, SRs already provide built-in access to longdesc of course.

For instance in Windows, with Jaws, I can use cursor up/down to work my way through the page, only pausing at any new block/element. In this fashion, I can actually "get to" an image (even if it's not normally focusable), and then if there's a longdesc, Jaws will announce it and prompt me to use ALT+ENTER to load the longdesc address. Another way would be to just let Jaws read the content of the page, sequentially, from top to bottom. Once it reads "over" an image that has a longdesc, it will also prompt me to hit ALT+ENTER. If I'm quick enough (and don't let it carry on reading much further), I can also activate the longdesc.

This is of course great for screen-reader users, as the AT here is providing a rich way to navigate and activate content. For a NON-screen-reader user who happens to use a keyboard only, though, there is no way to "get to" an image, so no way to activate the context menu and select this new longdesc option...unless you add an option for users to force these images into the focus cycle. Otherwise, you're only making a useful addition to mouse-using sighted users.
Hi Jennifer,

As Patrick said in comment #7 sighted keyboard users could certainly benefit from longdesc. 

In the previous bug I mentioned that the following sighted people may be aided by access to a longdesc that don't use a screen reader:

* 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. 
https://bugzilla.mozilla.org/show_bug.cgi?id=854848#c44

Devarshi Pant talked about the keyboard focus in the previous bug too. He suggested that: a Keyboard Only Sighted User could possibly:
"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.'"
https://bugzilla.mozilla.org/show_bug.cgi?id=854848#c32

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
(In reply to Patrick H. Lauke from comment #7)
> When running a screen-reader, images aren't normally added to the focus
> cycle either. 

Thanks for the clarification, Patrick.  It sounds like screen reader software (such as Jaws) themselves treat longdesc and even focus itself differently, but these differences are best handled on their end rather than in the browser.  

> For a NON-screen-reader user
> who happens to use a keyboard only, though, there is no way to "get to" an
> image, so no way to activate the context menu and select this new longdesc
> option...unless you add an option for users to force these images into the
> focus cycle. 

That's true, though it's not specific to longdesc but rather an attribute of browser focus itself.  Changes to overall focus are out of scope for this particular bug.  If any changes are made to focus in Firefox, they'd apply to long and short descriptions.

This bug is unowned right now, and I'll try and find a free developer to work on it.  Also, I point out because several people are watching this bug, that Firefox is an open source community project, so absolutely anyone can feel free to pick up this bug and work on its implementation.  I'd be happy to work with any developer who's interested in writing the patch.
Just to be very clear:

- screenreader users are already able to access longdesc without the proposed addition from this bug - they do not need this additional item in the context menu, as they have built-in functionality to access the longdesc anyway

- so, the user group that's ideally addressed by this bug are partially sighted and sighted users that may be using a mouse, keyboard, etc.

"Changes to overall focus are out of scope for this particular bug."

By not changing focus handling (or rather, by not including an option to also change focus handling) to include images with longdesc into the normal tab/focus cycle, this bug effectively only benefits users with a mouse.

"If any changes are made to focus in Firefox, they'd apply to long and short descriptions"

This does not make any sense to me. Can you clarify what you mean by "short descriptions" in relation to images here? Things like showing a title popup?
> Thanks for the clarification, Patrick.  It sounds like screen reader
> software (such as Jaws) themselves treat longdesc and even focus itself
> differently, but these differences are best handled on their end rather than
> in the browser.  

Yes and no. 

Prior to NVDAs implementation of support for @longdesc, I had an opportunity to have a face-to-face meeting with both Jamie and Nick (Spring, 2011). I asked them then why they were reluctant to implement support for @longdesc, and the response they gave me at taht time was that they really did not want to start creating new "controls", but rather to map to existing controls in the browser. However, when that functionality was not forthcoming, they eventually conceded and found a way of providing that support. It was apparently not their first choice however.

A standardized control - in the browser - makes it easier for all types of users and Assistive Technology to interact with that control, as it is consistent at the user-agent level. It is my belief that this is both the nature and the intent of the initial bug filed here (https://bugzilla.mozilla.org/show_bug.cgi?id=854848)


> 
> That's true, though it's not specific to longdesc but rather an attribute of
> browser focus itself.  Changes to overall focus are out of scope for this
> particular bug.  If any changes are made to focus in Firefox, they'd apply
> to long and short descriptions.

There is a significant difference between the "short description" (which is rendered as string text, both by the browser, as well as 'interpreted' by the screen readers) and the longer description. The @longdesc attribute takes, not string text, but a URI, which requires some form of user-interaction to process. Screen readers today announce the presence of the link, but then awaits further 'instruction' from the end user (follow the link, continue past the link). For this reason, FOCUS must be part of the technical solution for native implementation of @longdesc support.

As Patrick also notes, while screen readers have found ways to augment and support this attribute today (to meet the needs of their users), there are other user-groups who may or may not be using screen reading technology that would also greatly benefit from support of this attribute.

As I noted earlier (https://bugzilla.mozilla.org/show_bug.cgi?id=854848#c46), one of the key requirements for support of @longdesc is that of 'discoverability', and for those users who MUST interact with their user-agent via the keyboard only, it would seem that the only way of providing that discoverability would be through some form of tab focus + visual feedback(*). If the UI team at Mozilla have other ideas on how to meet this goal however, it would be great to hear of them: I for one promise an honest and balanced feedback of that/those idea(s).  

(* note that the common "marching ants" focus outline would not be sufficient, as an image with the @longdesc attribute might also be wrapped in a link (anchor) element, like this:

<a href="path to homepage"><img src="logo.png" alt="Nike.com" longdesc="path to swoosh.html"/></a>)


> This bug is unowned right now, and I'll try and find a free developer to
> work on it.  Also, I point out because several people are watching this bug,
> that Firefox is an open source community project, so absolutely anyone can
> feel free to pick up this bug and work on its implementation.  I'd be happy
> to work with any developer who's interested in writing the patch.

Jennifer, thank you for your continued participation in this dialog - it seems that in some ways *you* own it today, although I appreciate that there is ownership and then Ownership (as part of the business process). So thank you again for at least owning the task of finding an Owner :-)

Is there a documented process for getting patches written by outside developers into the core code base? If a developer or other interested parties emerged with such a patch, what is the process and (more importantly) the likelihood that the patch would be integrated back into core? For example, if I were to make a financial investment in contracting a developer to write such a patch, would that investment be worth it? (It would be a shame to spend money on a solution, and not have it implemented). Feedback on that idea greatly appreciated.
Hi Jennifer,

You wrote in comment 9:
"Changes to overall focus are out of scope for this particular bug." 

John wrote in comment 11:
"A standardized control - in the browser - makes it easier for all types of users and Assistive Technology to interact with that control, as it is consistent at the user-agent level. It is my belief that this is both the nature and the intent of the initial bug filed here (https://bugzilla.mozilla.org/show_bug.cgi?id=854848)"

This is correct. I filed bug 854848 with the following 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.
"

Again, as Steve suggested his simple suggestion is to add tabindex=0. But if  changes to focus are out of scope for this new bug 877453, then I am thinking that we should reopen 854848 because 877453 is not in fact a duplicate of 854848. What do you think Jennifer? What is the best way to proceed?
longdesc has been 'supported' in Firefox in relation to the accessibility payer for eons. Any AT that uses the standard accessibility APIs can get the info that a longdesc is present on an image and a default action is provided via the API for activating the opening of the longdesc URL in a new tab/window. In MSAA its(accDefaultAction: ShowLongdesc) and indeed this is what NVDA uses to support access to longdesc.

I suggest what is needed is support for non-AT users including keyboard users.
I think this bug can be left as intended and remain scoped to the actual implementation of the context menu. I think separate bugs can be opened for addressing other pieces such as keyboard use and visual affordance but let's please try not to make the comment scroll too long on any of these bugs.
Agreed. I think the focus navigation should be a separate discussion as it is more contentious given that it impacts the rendering of the page directly.
(In reply to David Bolter [:davidb] from comment #14)
> I think this bug can be left as intended and remain scoped to the actual
> implementation of the context menu. I think separate bugs can be opened for
> addressing other pieces such as keyboard use and visual affordance

Thanks David. The new 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
Attached patch PatchSplinter Review
Try builds available at:

http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/maxli@maxli.ca-332fda3c2988/
Assignee: nobody → maxli
Attachment #766475 - Flags: feedback?(jboriss)
Hi Max,

(In reply to Max Li [:maxli] from comment #17)
> Created attachment 766475 [details] [diff] [review]
> Patch
> 
> Try builds available at:
> 
> http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/maxli@maxli.ca-
> 332fda3c2988/

I tested patch "try-macosx64" Nightly 24.0a1 with Mac OS X 10.68 and Mac OS X 10.84 on the test cases at:
http://www.d.umn.edu/~lcarlson/research/ld-tests/tests/index.html

Using a mouse or track pad the patch successfully allowed me to access all of the long text alternative resources indicated by the longdesc attribute through the context menu.

This is excellent progress in Mozilla beginning to support longdesc and fulfill expected results.
http://www.d.umn.edu/~lcarlson/research/ld-tests/tests/index.html#results

Many, many thanks to you, Jennifer and David. Very much appreciated!
Blocks: 854848
(In reply to John Foliot from comment #11)
> Prior to NVDAs implementation of support for @longdesc, I had an opportunity
> to have a face-to-face meeting with both Jamie and Nick (Spring, 2011). I
> asked them then why they were reluctant to implement support for @longdesc,
> and the response they gave me at taht time was that they really did not want
> to start creating new "controls", but rather to map to existing controls in
> the browser. However, when that functionality was not forthcoming, they
> eventually conceded and found a way of providing that support. It was
> apparently not their first choice however.

Makes sense, and Jamie and Nick's perspective has merit.  The browser's role, as I see it, is to support the innovation of the web by making it accessible, usable, and performant.  Affecting with how innovation happens, by creating controls or otherwise, is something to be done sparingly and only when absolutely necessary (for instance, when lack of controls impeding innovation or use of the web).  
 
(In reply to Laura Carlson from comment #12)
> Again, as Steve suggested his simple suggestion is to add tabindex=0. But if
> changes to focus are out of scope for this new bug 877453, then I am
> thinking that we should reopen 854848 because 877453 is not in fact a
> duplicate of 854848. What do you think Jennifer? What is the best way to
> proceed?

Individual bugs we try to scope to one issue, mostly for our own sanity.  Separate issues related to longdesc can be filed in separate bugs.  A tracking bug shouldn't be needed for longdesc issues as there isn't a significant dependency tree to worry about.  I saw you opened other bugs related to longdesc and will address them too.

(In reply to Max Li [:maxli] from comment #17)
> Created attachment 766475 [details] [diff] [review]
> Patch

Fantastic, thanks Max!
Attachment #766475 - Flags: feedback?(jboriss) → ui-review+
No longer blocks: 854848
Attachment #766475 - Flags: review?(gavin.sharp)
Comment on attachment 766475 [details] [diff] [review]
Patch

onImageDesc seems redundant, since it's always equal to (this.imageDescURL != ""), so please just remove it.

r=me with that change.
Attachment #766475 - Flags: review?(gavin.sharp) → review+
https://hg.mozilla.org/mozilla-central/rev/4d308b13b92c
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla25
Blocks: 1203282
See Also: → 1283529
Blocks: 314697
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: