User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.67 Safari/537.36 Steps to reproduce: Applied display:contents to a <button>, both with and without its role set to button. Test page: https://s.codepen.io/aardrian/debug/KGBbQd Test page: https://s.codepen.io/scottohara/debug/GYoBgZ/WPALYNWgeOJk Essentially <button style="display:contents"> and <button role="button" style="display:contents"> both lost their button semantics. Actual results: The button is exposed in the Firefox accessibility inspector as a text leaf node, not a button. Expected results: It should be exposed as a button element with all appropriate nodes in the accessibility tree. Related to (which focuses on list semantics): https://bugzilla.mozilla.org/show_bug.cgi?id=1455357#c32 Also related to (which focuses on role attribute): https://bugzilla.mozilla.org/show_bug.cgi?id=1494196
It looks like we haven't yet caught all cases where display:contents is dealt with. Possibly also related to bug 1500416, which landed today. I will take a look at this tomorrow.
Component: Untriaged → Disability Access APIs
Priority: -- → P2
Product: Firefox → Core
This is due to a couple of things: 1. button isn't in MarkupMap; we use layout stuff to create an accessible for <button>. In this case, there's no layout stuff, so no accessible. So, we need to move <button> into MarkupMap. 2. We only ever create accessibles for display: contents if the element is in MarkupMap. If it isn't in MarkupMap, we don't consider it at all, even if it has an ARIA role. That's covered by bug 1494196. So, this bug should just fix 1) and 2) should be fixed in bug 1494196.
See Also: → 1494196
7 months ago
Depends on: 1508935
You need to log in before you can comment on or make changes to this bug.