WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: How to solve a talkback chrome issue for aria-describedby

for

From: Birkir R. Gunnarsson
Date: Dec 24, 2016 6:43PM

This is an example as to why you have to pick an accessibility testing
platform, and optimize only for that platform.

I always recommend NVDA with Firefox, because Firefox is responsive to
accessibility pdates and NVDA is free and open source.
Accessibility is not only the webpage author's business. The author
needs to make sure to write standards compliant/accessible code that
works with at least one browser/A.T. combination.
* It is the browser vendor's responsibility to expose the
accessibility markup to the operating system's accessibility API.
* It is the operating system's vendor's job to make sure the API
accommodates all accessibility markup.
* It is the assistive technology maker's job to make sure the a.t.
application queries the interface and interprets the information in a
way the end users can understand.
In this scenario, Google; the vendor responsible for Chrome, is most
likely responsible for not handling aria-describebby properly (not
exposing its value as an accessible description to the Windows
accessibility API, either MSAA, UIA or iAccessible2. I say this
because it works fine with Firefox.
It could also be Windows fault (implementing so many accessibility
interfaces, often failing to implement one all the way).
My point is that the authors are not the only ones responsible for
webpages being accessible in all browsers on all operating systems.
That is the reason we have standards in the first place. The work must
be not only on the authors, but on the browser vendors, the operating
system vendors and the assistive technology vendors.
We have standards to explain how information should be exposed. Those
are not perfect, but we are working hard to improve them.
It is our job, as accessibility experts, to recognize the glitches and
file bugs with the parties we believe are responsible.
We can ask the authors to jump through hoops to address the need, but
if we keep doing that, we will destroy the whole effort of
accessibility standardization.
We have a responsibility to help ensure that accessible markup is
turned into an accessible experience on the largest possible
combination of browsers, operating systems and assistive technologies.
But we can't always do that by asking the webpage developers to jump
through hoops and expose all manners of tricky markup to workaround
the inefficiencies and bugs of this and that browser.
It is our responsibility to make sure it works on at least one
reasonable combination, and then to help file bugs and promote
accessibility everywhere else.

Cheers
-B


On 12/23/16, Moore,Michael (Accessibility) (HHSC)
< <EMAIL REMOVED> > wrote:
> Yes there is not much support for that attribute at this point
> aria-describedby provides a backup. IMHO chrome accessibility support in
> general is not very good for windows based screen readers yet. Ideally the
> aria-describedby would only be injected when it was needed but I am not sure
> how well that could be determined.
>
> Mike Moore
> EIR (Electronic Information Resoources) Accessibility Coordinator
> Texas Health and Human Services Commission
> Civil Rights Office
> (512) 438-3431 (Office)
> (512) 574-0091 (Cell)
>
> Making electronic information and services accessible to people with
> disabilities is everyone's job. I am here to help.
>
>