Closed Bug 1657576 Opened 5 years ago Closed 5 years ago

Support the exposure of web app specific shortcuts to assistive technologies

Categories

(Core :: Disability Access APIs, enhancement, P2)

Firefox 81
enhancement

Tracking

()

RESOLVED FIXED
82 Branch
Tracking Status
firefox81 --- wontfix
firefox82 --- fixed

People

(Reporter: MarcoZ, Assigned: MarcoZ)

References

(Blocks 1 open bug)

Details

(Keywords: parity-chrome)

Attachments

(1 file)

Currently used mostly by JAWS, Twitter and Facebook to allow them to specify which virtual quick navigation keys JAWS should not use when in those web applications, but instead pass them through to the browser. This works in Chrome and the new Edge, but not in Firefox, because JAWS stopped using ISimpleDOM in Firefox, which no longer gave them access to this attribute.

This bug is to allow exposure of the non-standardized data-at-shortcutkeys attribute value via a same-named IAccessible2 and ATK Object Attribute.

For a description and example, see this portion of a JAWS training webinar on the Freedom Scientific web site.

Currently used mostly by Twitter and Facebook to allow them to specify which virtual quick navigation keys assistive technologies should not use when in those web applications, but instead pass them through to the browser. JAWS is currently the only known assistive technology making use of this feature.

This works in Chrome and the new Edge, but not in Firefox, because JAWS stopped using ISimpleDOM in Firefox, which no longer gave them access to this attribute.

This bug is to allow exposure of the non-standardized data-at-shortcutkeys attribute value via a same-named IAccessible2 and ATK Object Attribute.

Given that ISimpleDOM is still available in Firefox, this raises the question: which is the worse of two evils? Having JAWS use ISimpleDOM just to access this attribute or special casing a non-standard attribute in our code? On one hand, we want to deprecate ISimpleDOM and anything that gets us closer to that is a good thing. On the other hand, special casing a non-standard attribute because vendors pushed it without even trying to standardise it sets a pretty bad precedent and is potentially a slippery slope. Do we just expose any attribute a vendor asks for? What are the criteria for when we allow this and when we don't?

Given that this has been around for a while, I can probably live with special casing this. I do worry about the precedent here, though.

CC Sean and Asa in case they have objections, but otherwise, I will r+ this.

It appears either no opinions, or this was drowned by the layoffs. Any thoughts? I was trying to be pragmatic and allow Vispero access to something they lost when they moved away from iSimpleDOM, probably as a result of Quantum and performance problems with our architecture, and give them the opportunity to offer them the same feature their users get in Chrome and Edge. And yes, this has been around for a few years, and Twitter even fixed it for the new PWA some time last year when they deprecated the old web interface. See this post on the Freedom Scientific blog.

Pushed by mzehe@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/facc78377809 Expose the data-at-shortcutkeys attribute as an object attribute, r=Jamie
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → 82 Branch
Flags: in-testsuite+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: