WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Working around flaky browser accessibility tree

for

From: Steve Faulkner
Date: Apr 6, 2018 9:21AM

Lynne, this is a known bug, regression in Chrome 65 and is being fixed, so
suggest no workaround as it will be fixed in next release.

https://bugs.chromium.org/p/chromium/issues/detail?id‚4465&q=aria-expanded&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified

--

Regards

SteveF
Current Standards Work @W3C
<http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;

On 6 April 2018 at 16:04, Lynn Holdsworth < <EMAIL REMOVED> > wrote:

> Hi all,
>
> Apologies if this has been discussed ad nauseum in the past, but...
>
> I'm creating an accordion and want to use the aria-expanded attribute
> on the expand/collapse buttons to flag up whether their associated
> content is shown or hidden.
>
> But Google Chrome doesn't expose this flag in its accessibility tree.
> Or at least I assume that's what's happening since JAWS and NVDA can
> pick it up in IE11 but not in Chrome 65.
>
> What's the accepted work-around for issues like this, where it's the
> browser or the AT that's at fault rather than the mark-up? Should we
> add some hidden text into the expand/collapse button until this issue
> gets fixed in Chrome, or just implement our code as-is and blame the
> browser?
>
> If our current solution (the one with no work-arounds) were subject to
> a WCAG2 audit, would this aspect fail 4.1.2 since the button's state
> isn't available to AT?
>
> We want our application to be as accessible as possible, so I'm
> tempted to add a work-around for now, but being a purist I find it
> frustrating to have to do this :-)
>
> Have a great weekend.
>
> Thanks, Lynn
> > > > >