E-mail List Archives
Thread: Working around flaky browser accessibility tree
Number of posts in this thread: 5 (In chronological order)
From: Lynn Holdsworth
Date: Fri, Apr 06 2018 9:04AM
Subject: Working around flaky browser accessibility tree
No previous message | Next message →
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
From: Steve Faulkner
Date: Fri, Apr 06 2018 9:21AM
Subject: Re: Working around flaky browser accessibility tree
← Previous message | Next message →
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?id4465&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 ADDRESS 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
> > > > >
From: Glen Walker
Date: Fri, Apr 06 2018 9:45AM
Subject: Re: Working around flaky browser accessibility tree
← Previous message | Next message →
In this particular case, it sounds like you're ok, but it's a good general question. If my site works well with browser A and screen reader X, do I have to worry about browser B or screen reader Y? I think a common practice is for companies to have an accessibility statement that says something like, "For the best user experience, we recommend using jaws with ie or nvda with firefox", with possible details about browser or AT version numbers. VO is usually included too. I don't see chrome mentioned very often in those statements, fwiw.
From: Birkir R. Gunnarsson
Date: Sat, Apr 07 2018 11:39AM
Subject: Re: Working around flaky browser accessibility tree
← Previous message | Next message →
Exactly. You only have a chance to do proper user testing with one
combination of a browser and a screen reader, doing more than that is
usually unattainable because of the resources required.
so you should have a statement, or help page or something publically
accessible that states: For best experience use combination x, (often
NVDA and Firefox) or that your site was tested with combination x.
On 4/6/18, Glen Walker < = EMAIL ADDRESS REMOVED = > wrote:
> In this particular case, it sounds like you're ok, but it's a good general
> question. If my site works well with browser A and screen reader X, do I
> have to worry about browser B or screen reader Y? I think a common practice
> is for companies to have an accessibility statement that says something
> like, "For the best user experience, we recommend using jaws with ie or nvda
> with firefox", with possible details about browser or AT version numbers. VO
> is usually included too. I don't see chrome mentioned very often in those
> statements, fwiw.
> > > > >
--
Work hard. Have fun. Make history.
From: Lynn Holdsworth
Date: Mon, Apr 09 2018 1:54AM
Subject: Re: Working around flaky browser accessibility tree
← Previous message | No next message
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 ADDRESS 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?id4465&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 ADDRESS 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
>> >> >> >> >>
> > > > >