Chrome 80/81 Bug: Accessible Name Calculation
Chrome 80 rolled out on 19 February 2020, and with it came a pile of fixes for how elements with CSS display properties have their semantics exposed in the accessibility tree. These huge accessibility bug fixes featured prominently in my CSUN talk this year (starting at slide 36).
Unfortunately, that release introduced a new bug, filed 30 January 2020: Issue 1047549: Incorrect name calculation for ListBoxOption with strong or emphasis text
Add in some of my testing, asking around, wading into a WebAIM thread, and what I found is that some HTML elements nested within
<label>s are excluded from the accessibility tree. I am probably over-simplifying, but at the very least it is clear accessible name calculation in Chrome 80 is kinda broken and extends well beyond the
listbox scope of the bug report.
The fix came too late to make it into Chrome 81 (per the bug report). With Chrome 81 now delayed, any fix coming in Chrome 82, originally scheduled for 9 June 2020, will come at some yet-to-be-determined future date.
That means this post has a freshness date. After some time in June or July 2020, I hope you can ignore this post.
I discovered this when testing a form on a project. A form I had tested before with a screen reader and which had already been buttoned up and deployed. I made a crude minimal representation of it on Codepen (view it in debug mode to remove Codepen cruft for testing).
The simplest way to confirm the problem is to open the dev tools and pop into the accessibility inspector. When you look at the accessible name for each control, the text that is wrapped in
<em> is completely excluded.
It may be a bit hard to understand just how much the meaning can be changed by excluding a single word or clause, so I made a video.
I also confirmed the problem in Chrome for Android.
On the WebAIM list someone pointed out that a ‘fix’ is to add
role="presentation" to each element that is not being announced. Doing so appeared to do the trick. So, yeah, that works, but it is a terrible, awful hack.
Other reports indicate
<b>, and many more on all also have the same problem when part of an accessible name. Which means, essentially, you have to test.
I don’t know how this happened. I am not dunking on Chrome nor its team. Building a browser with a 6-week life-cycle is hard work. Bugs happen. This just happens to be a bug with potential massive risk for screen reader users.
This is not something an automated accessibility checker would catch. As far as I know, none compares the DOM with the accessibility tree to look for discrepancies. A validator would not catch this, either. This is something you would only catch with manual testing.
Probably do not rush out and add
role="presentation" to every inline element that is part of an accessible name. My testing was not that thorough. It would also hobble the experience for browsers that aren’t broken (Firefox). Instead, find those critical forms and screens and spot test them. Then make a decision based on that context and your user stats.
Understand that this bug will be in the wild for at least three more months (late June 2020), perhaps more depending on how far the Chrome 82 release slips. Which you will have to test again.
Update: 1 April 2020
Chrome 82 is being skipped and 83 is being moved up by three weeks, though this appears to be just a naming/semantics issue as it will contain the 82 changes.
If the updated schedule is accurate, Chrome 81 will drop on 7 April. While I have not heard back on a question about when to expect this, it seems like I should test the release next week if/when it drops.
In the meantime, continue to test your critical applications for the impact of this bug.
In my current code base, I have a badly written button with both strong and b elements contained, that now appears to speak twice in the Chrome 81 beta.
Oh my. Do you have a test case you can add to that open bug? If not, I will see what I can come up with later.
A quick check based on what you described shows me that in Chrome Canary (83.0.4102.3) and Chrome Beta (81.0.4044.83) there is no doubling in the accessibility inspector. Nor is there double announcement with JAWS 2018.