Support the exposure of web app specific shortcuts to assistive technologies
Categories
(Core :: Disability Access APIs, enhancement, P2)
Tracking
()
People
(Reporter: MarcoZ, Assigned: MarcoZ)
References
(Blocks 1 open bug)
Details
(Keywords: parity-chrome)
Attachments
(1 file)
|
47 bytes,
text/x-phabricator-request
|
Details |
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.
| Assignee | ||
Comment 1•5 years ago
|
||
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.
Comment 2•5 years ago
|
||
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.
| Assignee | ||
Comment 3•5 years ago
|
||
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.
Comment 5•5 years ago
|
||
| bugherder | ||
Updated•5 years ago
|
Description
•