E-mail List Archives
Re: Working around flaky browser accessibility tree
From: Lynn Holdsworth
Date: Apr 9, 2018 1:54AM
- Next message: Tim Harshbarger: "Re: [EXTERNAL] CSS disabled"
- Previous message: Kakarla Meharoon: "CSS disabled"
- Next message in Thread: None
- Previous message in Thread: Birkir R. Gunnarsson: "Re: Working around flaky browser accessibility tree"
- View all messages in this Thread
Cheers Steve for the clarification. Let's hope Google get it together
soon, but in the interim AT users will just have to suck it up I
suppose. I was tempted to add an "aria-pressed" state too, since AFAIK
that's supported by Chrome, but no point in over-complicating things
if the bug is likely to be fixed soon.
On 06/04/2018, Steve Faulkner < <EMAIL REMOVED> > wrote:
> 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
>> >> >> >> >>
> > > > >
- Next message: Tim Harshbarger: "Re: [EXTERNAL] CSS disabled"
- Previous message: Kakarla Meharoon: "CSS disabled"
- Next message in Thread: None
- Previous message in Thread: Birkir R. Gunnarsson: "Re: Working around flaky browser accessibility tree"
- View all messages in this Thread