WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Kevin Chao
Date: Dec 27, 2016 9:04AM

Thanks! I've filed a crbug:
https://bugs.chromium.org/p/chromium/issues/detail?idg7147

On Sat, Dec 24, 2016 at 5:43 PM Birkir R. Gunnarsson <
<EMAIL REMOVED> > wrote:

> 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.
> >
> >