Closed Bug 1508711 Opened 5 years ago Closed 5 years ago

Nodes inside a shadow root don't properly implement accessibility standards

Categories

(Core :: Disability Access APIs, defect)

64 Branch
defect
Not set
normal

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).
This was also tested with NVDA and MSSA Object Inspect.
Component: Untriaged → Disability Access
Blocks: shadowdom
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)
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)
(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)
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)

(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]?

[1] https://www.mozilla.org/en-US/firefox/channel/desktop/

Flags: needinfo?(caleb.d.williams)
Component: Disability Access → Disability Access APIs
Product: Firefox → Core

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: 5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.