-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarification for Accessibility requested #197
Comments
Nobody has responded on this, I have to think that the specification should say if Chrome's behavior is correct- how the backdrop should appear in the accessibility tree as it has tremendous impact on the potential use of this spec when serving users with accessibility issued. |
This does seem like a reasonable concern. Perhaps the non-fullscreen elements need to be treated as inert? cc @whatwg/a11y |
Yes, anytime an element is not rendered or interactive to mainstream users, I'd support it being removed from (or marked as hidden in) the accessibility tree. I agree that's likely a Gecko bug. A few pitfalls to be aware of are dual monitor setups, picture-in-picture mode, or multiple "Spaces" (Apple term). If other exit UI remains interactive (e.g. "Click to exit full-screen" or click the gray overlay to exit the modal) or if the rest of the page is still accessible while the full screen element is in another display or space, the new spec restrictions should account for those scenarios. |
Firefox >= 112 removes content outside full screen elements from the accessibility tree. |
Should this be defined in html-aam, similar to https://w3c.github.io/html-aam/#att-inert ? |
I would suggest the inertness behaviour be defined as a function of the top layer, per the discussion in whatwg/html#10811 In particular, since popover elements can appear as a new top layer on top of the fullscreen element (or modal dialog), it's important that they not be made inert just because they are outside that element in the DOM. |
I'd like a clarification of what should happen to elements outside of the full screen element when a screen reader is being used.
In Chrome currently there does not seem to be any interaction with them.
In Firefox it is all available with the screen reader
I have not tested with anything else, however when I read the spec regarding the backdrop pseudo selector this Note:
The ::backdrop pseudo-element can be used to create a backdrop that hides the underlying document for an element in a top layer (such as an element that is displayed fullscreen).
implies to me that the way to hide something that is in the backdrop from a screenreader
would be to use the backdrop pseudo selector and put in a display: none property.
which currently has no effect in Chrome because Chrome doesn't expose it to screen readers anyway, and which doesn't work in Firefox.
Given that we are also supposed to be able to style the backdrop this doesn't seem very reasonable either however - because what if I want to style the backdrop but alson don't want any of it to be read by screenreaders (which frankly seems to be nearly always the way it should be)
I made a bug report in Firefox yesterday https://bugzilla.mozilla.org/show_bug.cgi?id=1728889 although the more I think about it maybe the solution is an addition to the spec allowing you to turn off screenreader access to the backdrop programmatically.
The text was updated successfully, but these errors were encountered: