disallow aria-hidden on the body element

scottaohara commented 4 years ago

See ARIA issue 1190.

scottaohara commented 4 years ago

see also ARIA issue 1254

scottaohara commented 4 years ago

immediate takeaway from this, add exclusion of aria-hidden on body element.

it's already not allowed on html.

scottaohara commented 3 years ago

I see the following needed here:

indicate that aria-hidden is not allowed on the body element (additionally, i question if any aria attributes should even be allowed on the body element. the only non-global one in aria 1.1 is aria-expanded. and in aria 1.2 that one is being removed as it doesn't make sense on a role=document).
indicate that aria-hidden is not allowed on interactive/focusable elements unless those elements are also set to tabindex=-1
indicate that if aria-hidden=true is used on a container to focusable elements, then those focusable elements MUST have a tabindex=-1 set to them, or be otherwise unable to receive keyboard focus (e.g., display:none)

JAWS-test commented 3 years ago

indicate that aria-hidden is not allowed on interactive/focusable elements unless those elements are also set to tabindex=-1

Screen readers offer the possibility to output the content under the mouse pointer. What would be the correct output for interactive elements if they are marked with tabindex=-1 and aria-hidden=true:

no output
full output
output with reference to aria-hidden
output of the role, but not of label (this is the current behavior of NVDA, which is probably wrong)

scottaohara commented 3 years ago

@JAWS-test as I know you have been following along with this topic, as in ARIA ticket #1381, I should also hope you remember that it is not for this spec to determine what what the correct output would be for screen readers.

Rather, until a feature such as inert is available, there is no good way for authors to completely hide content outside of modal dialogs and other such components, and the reality is techniques like this, using aria-hidden and negative tabindex, is necessary to both hide the content from AT while ALSO making sure it cannot receive keyboard focus.

This issue, much like the work in ARIA, is an effort to at least mitigate instances of authors doing things like <body aria-hiddden=true> and <button aria-hidden=true> where the latter is widely agreed to be problematic because any dialog that appears on the screen will also be a child of body, and the former can still receive keyboard focus, even though it's hidden to AT.

So, again, while I appreciate the ramifications that your question alludes to, this issue is to help STOP the misuse of aria-hidden as setting up these rules will at least allow conformance checkers like the HTML validator to produce warnings. Both of my examples currently flag no warnings or errors in the validator. The completion of this issue will help change that.

JAWS-test commented 3 years ago

@scottaohara I had just wondered if aria-hidden on interactive elements that can be operated with the mouse should not be banned in general.

scottaohara commented 3 years ago

that'd be nice. not sure if it'd be actually practical. but, worth discussing and collecting information.

scottaohara commented 3 years ago

@alia11y here is the related issue i created for ARIA's issue 1254

to express concerns expressed on the ARIA WG call today – we would want to make sure to specify this in a way where it is now allowed on the root document (body/html element - noting again that html already disallows this attribute), but we do want to make sure this could be used for nested documents which do need to be set to hidden.

scottaohara commented 2 years ago

@patrickhlauke assigning to you for additional thoughts on what could be done here.

scottaohara commented 1 year ago

note per PR 447, this issue will be resolved only by disallowing aria-hidden on the body element.

a new issue will be created for other potential rules to limit misuse of the aria-hidden attribute.

w3c / html-aria

disallow aria-hidden on the body element #221