Closed
Bug 1508711
Opened 5 years ago
Closed 4 years ago
Nodes inside a shadow root don't properly implement accessibility standards
Categories
(Core :: Disability Access APIs, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: caleb.d.williams, Unassigned, NeedInfo)
References
(Blocks 1 open bug)
Details
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Steps to reproduce: Created form elements inside of a shadow root and used the built-in Apple VoiceOver feature for a11y testing. A very basic reproduction can be found on https://codepen.io/calebdwilliams/pen/PxENvb which contains an input and a label inside an open shadow root. The elements are ignored by Firefox when focusing. Using these same steps in Chrome and Safari work. Actual results: Very basic and advanced accessibility features didn't fire including aria-* attributes, input recognition, etc. The nodes in question were effectively ignored. Expected results: The screen reader should read out the proper DOM information in exactly the same manner it would in the light DOM, but with node encapsulation (only read the ids, names, etc in the current document-fragment scope).
Reporter | ||
Comment 1•5 years ago
|
||
This was also tested with NVDA and MSSA Object Inspect.
![]() |
||
Updated•5 years ago
|
Component: Untriaged → Disability Access
Comment 2•5 years ago
|
||
I cannot reproduce with Firefox Nightly on Windows 10 with NVDA. On the above code pen, in the result frame, I get a "This isn't accessible" label and a text input which I can focus and which gets the same name from the label. I don't see a problem there. You are probably using a version of Firefox where the shadow DOM features aren't enabled yet. Note, too, that our implementation for accessibility on Mac is spotty at best. So the only reliable way to test accessibility with Firefox and a screen reader is on Windows or Linux. WFM as far as I am concerned.
Flags: needinfo?(caleb.d.williams)
Comment 3•5 years ago
|
||
There has been fixing happening quite recently, so Nightly behaves probably differently than release versions. But IIRC at least a11y handling for iframes in shadow DOM needs still some work.
Flags: needinfo?(surkov.alexander)
Comment 4•5 years ago
|
||
(In reply to Olli Pettay [:smaug] (high review load) from comment #3) > There has been fixing happening quite recently, so Nightly behaves probably > differently than release versions. But IIRC at least a11y handling for > iframes in shadow DOM needs still some work. Right. It probably shouldn't go into this bug though. Do you want me to file a new bug to explore the potential issues?
Flags: needinfo?(surkov.alexander)
Reporter | ||
Comment 5•5 years ago
|
||
I am definitely using a version of Firefox where shadow DOM is enabled and am getting the same behavior on OSX for whatever it's worth.
Flags: needinfo?(caleb.d.williams)
Comment 6•5 years ago
|
||
(In reply to caleb.d.williams from comment #5)
I am definitely using a version of Firefox where shadow DOM is enabled and
am getting the same behavior on OSX for whatever it's worth.
could you double check with Firefox Nightly please [1]?
Flags: needinfo?(caleb.d.williams)
Updated•5 years ago
|
Component: Disability Access → Disability Access APIs
Product: Firefox → Core
Comment 7•4 years ago
|
||
I can't reproduce this either as per comment 2. Closing as worksforme given no response from reporter, noting that there were shadow DOM a11y fixes around 7 months ago (and more since then) that are now in Firefox release versions.
Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•