Issue metadata
Sign in to add a comment
|
Accessible name computation should follow DOM order, not layout tree order
Reported by
i...@joe-watkins.io,
Aug 19 2017
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.101 Safari/537.36 Example URL: https://codepen.io/joe-watkins/pen/OjpqxL Steps to reproduce the problem: 1. Visit https://codepen.io/joe-watkins/pen/OjpqxL with Chrome and VoiceOver activated. 2. Tab to each link and listen to how they are announced. What is the expected behavior? The visually hidden text using HTML5 boilerplate's .visuallyhidden {} will be announced in the order that it is within the markup. What went wrong? The order of the text is not announced does not match the markup order. Visually hidden text is announced before visible text copy. Does it occur on multiple sites: Yes Is it a problem with a plugin? N/A Did this work before? N/A Does this work in other browsers? No Safari Chrome version: 60.0.3112.101 Channel: stable OS Version: OS X 10.12.6 Flash Version: Shockwave Flash 26.0 r0 More information found in this bug with the HTML5 boilerplate project: https://github.com/h5bp/html5-boilerplate/issues/1985 We attempted to update the visually hidden text CSS to combat this Safari/Chrome bug but had no luck. HTML5 boilerplate is a source for many developers when it comes to visually hidden text content. The pattern of hiding textual content for screen readers is quite common and this bug can have a large impact on accessibility.
,
Aug 22 2017
It is worth noting that we found by using display: inline-block; it appeared to fix reading order but created visually craziness so we reverted. It feels like if the text at all reaches outside of an invisible bounding box it is read out of order.. if it is nice and inline with the text that is visible, markup order is respected.
,
Aug 22 2017
Interesting. I suspect that position:absolute is pulling it out of the normal DOM order in the layout tree.
,
Aug 22 2017
Also noticed that the <a> may be the culprit in some way. Can't replicate with a heading, paragraph text, or a button. https://s.codepen.io/joe-watkins/debug/9472638eb591bf209aed158a950f4027
,
Aug 23
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Sep 7
It's not specific to a link. The difference is that VoiceOver traverses inside of those other elements, but it stops when it reaches a link and accepts Chrome's accessible text. The underlying bug is that Chrome's accessible text traverses its children in the order of the layout tree, not the DOM tree. Since this is obscure and there are workarounds, marking this a low priority. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by tkent@chromium.org
, Aug 20 2017