-
Notifications
You must be signed in to change notification settings - Fork 126
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
prevent use of aria-hidden=true on document root elements #1880
Conversation
closes #1254 @cookiecrook I took a first stab at drafting up the author and UA must nots. Please revise however you see fit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great start. Raising some questions that I don't currently know the answer to. Thanks for taking this one on!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for working on this.
Does this conflict with #1256? That proposal has its own set of challenges, but as I understand it, it could be used to emulate dialog.showModal(). That is, an author might set aria-hidden=true on the root and then set aria-hidden=false on a (non-native) modal dialog.
I tend to think the risk of abuse with aria-hidden on the root is higher than the advantages of supporting the theoretical emulation of dialog.showModal(), but I know there's been some push to have parallel support in ARIA for native HTML features, which is why I'm raising it here.
Co-authored-by: James Craig <[email protected]>
Co-authored-by: James Craig <[email protected]>
thanks a ton for those edits, @cookiecrook |
companion PR to w3c/aria#1880
https://bugs.webkit.org/show_bug.cgi?id=269523 rdar://123049663 Reviewed by Chris Fleizach. To prevent authors from hiding all content from assistive technologies, aria-hidden should not be respected on document root elements (`html`, `body`, or top-level `svg`s). w3c/aria#1880 * LayoutTests/accessibility/body-element-aria-hidden-expected.txt: Added. * LayoutTests/accessibility/body-element-aria-hidden.html: Added. * LayoutTests/accessibility/html-element-aria-hidden-expected.txt: Added. * LayoutTests/accessibility/html-element-aria-hidden.html: Added. * LayoutTests/platform/ios/TestExpectations: Enable new tests. * Source/WebCore/accessibility/AXCoreObject.h: * Source/WebCore/accessibility/AccessibilityObject.cpp: (WebCore::AccessibilityObject::isARIAHidden const): (WebCore::AccessibilityObject::tagName const): (WebCore::AccessibilityObject::setIsIgnoredFromParentDataForChild): * Source/WebCore/accessibility/AccessibilityObject.h: * Source/WebCore/accessibility/atspi/AccessibilityObjectAtspi.cpp: (WebCore::AccessibilityObjectAtspi::attributes const): * Source/WebCore/accessibility/isolatedtree/AXIsolatedObject.cpp: (WebCore::AXIsolatedObject::tagName const): Deleted. * Source/WebCore/accessibility/isolatedtree/AXIsolatedObject.h:
https://bugs.webkit.org/show_bug.cgi?id=269523 rdar://123049663 Reviewed by Chris Fleizach. To prevent authors from hiding all content from assistive technologies, aria-hidden should not be respected on document root elements (`html`, `body`, or top-level `svg`s). w3c/aria#1880 * LayoutTests/accessibility/body-element-aria-hidden-expected.txt: Added. * LayoutTests/accessibility/body-element-aria-hidden.html: Added. * LayoutTests/accessibility/html-element-aria-hidden-expected.txt: Added. * LayoutTests/accessibility/html-element-aria-hidden.html: Added. * LayoutTests/platform/ios/TestExpectations: Enable new tests. * Source/WebCore/accessibility/AXCoreObject.h: * Source/WebCore/accessibility/AccessibilityObject.cpp: (WebCore::AccessibilityObject::isARIAHidden const): (WebCore::AccessibilityObject::tagName const): (WebCore::AccessibilityObject::setIsIgnoredFromParentDataForChild): * Source/WebCore/accessibility/AccessibilityObject.h: * Source/WebCore/accessibility/atspi/AccessibilityObjectAtspi.cpp: (WebCore::AccessibilityObjectAtspi::attributes const): * Source/WebCore/accessibility/isolatedtree/AXIsolatedObject.cpp: (WebCore::AXIsolatedObject::tagName const): Deleted. * Source/WebCore/accessibility/isolatedtree/AXIsolatedObject.h: Canonical link: https://commits.webkit.org/277677@main
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hopefully it is clear to readers what a primary document is. Do we need to define that in the glossary or is it really obvious to the intended audience?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@scottaohara, in an earlier comment you said the embedded view (iframe, img, etc) could be hidden by the containing context, so on a per-document level, this rule need not be aware of its embeddedness, or whether it's the "primary" document.
the root element or the host language element that represents the contents of the
primarydocument in view.
I agree with you, so it's possible this ~"root element or the host language element representing contents" is sufficient without the undefined "primary document" term.
What if the parent document doesn't have as much context as the iframe's contents about whether it should be hidden or not? They might not even be from the same domain. Is it difficult for any of the implementations to determine whether the document is top level? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removing my +1 until we get consensus on whether the top level document's documentElement/body is treated differently from the iframe's.
If that's a deal-breaker for Aaron, I'd say let's keep "primary." It does allow more permissive authoring flexibility, albeit adding a bit more implementation complexity. |
I think it just adds a single condition to the 'if' statement. Not too complex IMO. I'd rather not deal with the bug that gets filed with a legit use case. But perhaps Scott has a good reason to disallow in iframe html/body elements. |
Allowing an html/body element to have aria-hidden=true on it in an iframe wouldn’t do anything to prevent the exposure of the iframe in the parent doc However is the iframe in the parent doc could be consistently set to be hidden / taken out of the tab order, then that could prevent the nested iframe content from being accessible I fail to understand why there should be any distinction whether aria-hidden is set to the html/body elements within an iframe or not, since it’d be unnecessary if the iframe in the parent doc was properly hidden, and if the iframe was not properly hidden, then respecting the aria-hidden attribute in that context would result in the problem we are trying to solve with this change |
Adding agenda to "get consensus" re: Aaron's concerns so we can move this one forward! |
discussed in https://www.w3.org/2024/05/09-aria-minutes.html#t10 Decision to move forward |
Ok, let's go with disallowing aria-hidden on |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Excellent. I can't find anything that would be confusing, vague or isn't a clear improvement.
In terms of "waiting for implementations". Chrome has implemented this. |
@scottaohara the WebKit issue also seems to have been resolved, so this might be ready to merge. |
related HTML AAM PR has been merged. |
@jnurthen @spectranaut i think this has been ready to merge for awhile? at least chromium/webkit have implemented per comments here |
SHA: 951479e Reason: push, by jnurthen Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
closes #1254
adds user agent and author requirements regarding the use of aria-hidden=true on root-level elements of a document.
@cookiecrook I took a first stab at drafting up the author and UA must nots. Please revise however you see fit.
Implementation tracking
Preview | Diff