Change aria-hidden=false to synonym of undefined - #2090
Conversation
resolves #1256 This PR modifies the previous note about aria-hidden=false to instead indicate that as of ARIA 1.3 is serves as a synonym for the 'undefined' value. It also includes a minor editorial change to remove the mention of 'screen readers' from the last paragraph of the normative text. It seemed to state, especially when the sentence ends with referring to 'assistive technologies' in general. See [last comment](#1256 (comment)) Chrome issue: https://bugs.chromium.org/p/chromium/issues/detail?id=1500299 Question: assuming this PR is approved, would we also want to add the following sentence to the note? >In future versions of ARIA, the undefined value will be deprecated in favor of the false value.
There was a problem hiding this comment.
@aleventhal approved this PR, but he was also proposing that aria-hidden=false be allowed on visibly rendered items, a partial equivalent to the inert attribute. What changed, Aaron?
If there's a possibility we'll ever want to bring this value back, we should not change it now, and instead wait to change it once WICG/aom#203 (or some other testing approach) gives us access to inspect whether the node is "hidden from accessibility"
|
@jnurthen there were other related issues in the ARIA-hidden project that have been moved elsewhere. Should a keyword be added instead? Is there an easy way to find those issues? I'm not sure why they were put in a 1.3/1.4 Projects when we already had 1.3/1.4 Milestones. Apologies if that explanation was covered in one of the meetings I missed. |
I wanted aria-hidden="false" to be useful, but unfortunately, as was pointed out to me, it's misused by a lot of JS toolkits which treat it as a boolean, and they end up setting "false" all over the place where they really should have removed the attribute.
Because of the problem in js toolkits, and because browsers all implement it differently, I think we should go ahead and deprecate it as a possible value. |
Okay. I'm going to ask @twilco and @minorninth to review as well in case there are implementation concerns with its removal. I'm hopeful it goes without saying that this should not be merged until we have extensively passing WPT tests. Since this one wasn't in the initial Interop 2024 Focus Area proposal, that may not happen this year, but we can treat it as a tentative area for inclusion if there is time to fix it before the Fall releases. |
cookiecrook
left a comment
There was a problem hiding this comment.
Updating my "Changes Requested" review to "Comment" tentatively pending review from others.
|
I support removing the semantics of aria-hidden=false, but I'd like to improve the wording. I left some comments. Thanks. |
Co-authored-by: James Craig <cookiecrook@users.noreply.github.com>
SHA: 6205740 Reason: push, by jnurthen Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
| <p>Authors MAY, with caution, use aria-hidden to hide visibly rendered content from assistive technologies <em>only</em> if the act of hiding this content is intended to improve the experience for users of assistive technologies by removing redundant or extraneous content. Authors using aria-hidden to hide visible content MUST ensure that identical or equivalent meaning and functionality is exposed to assistive technologies.</p> | ||
| <p class="note">Authors are advised to use extreme caution and consider a wide range of disabilities when hiding visibly rendered content from assistive technologies. For example, a sighted, dexterity-impaired individual might use voice-controlled assistive technologies to access a visual interface. If an author hides visible link text "Go to checkout" and exposes similar, yet non-identical link text "Check out now" to the accessibility API, the user might be unable to access the interface they perceive using voice control. Similar problems can also arise for screen reader users. For example, a sighted telephone support technician might attempt to have the blind screen reader user click the "Go to checkout" link, which they might be unable to find using a type-ahead item search ("Go to…").</p> | ||
| <p class="note">At the time of this writing, <code><sref>aria-hidden</sref>="false"</code> is known to work inconsistently in browsers. As future implementations improve, use caution and test thoroughly before relying on this approach.</p> | ||
| <p class="note">As of ARIA 1.3, <code><sref>aria-hidden</sref>="false"</code> is now synonymous with <code>aria=hidden="undefined"</code>.</p> |
https://bugs.webkit.org/show_bug.cgi?id=267150 rdar://120557669 Reviewed by Tyler Wilcock. Per spec changes (see w3c/aria#2090), we should treat `aria-hidden=false` as undefined. This patch removes support for aria-hidden=false, updating places where we relied on the behaviors of isNodeARIAVisible with the new behavior. For example, we need to check if a child node is focused before deciding whether to skip it if it is aria-hidden (tested by accessibility/datetime/input-date-field-labels-and-value-changes.html). Tests that explicitly validate aria-hidden false were removed, and a new test to check that we are ignoring this property has been added. * LayoutTests/accessibility/aria-hidden-false-ignored-expected.txt: Added. * LayoutTests/accessibility/aria-hidden-false-ignored.html: Added. * LayoutTests/accessibility/aria-hidden-false-works-in-subtrees.html: Removed. * LayoutTests/accessibility/aria-hidden-negates-no-visibility.html: Removed. * LayoutTests/accessibility/aria-hidden-subtree-expected.txt: Added. * LayoutTests/accessibility/aria-hidden-subtree.html: Added. * LayoutTests/accessibility/aria-modal-expected.txt: * LayoutTests/accessibility/aria-modal.html: * LayoutTests/accessibility/aria-visible-element-roles.html: Removed. * LayoutTests/accessibility/datetime/input-date-field-labels-and-value-changes.html: * Source/WebCore/accessibility/AXObjectCache.cpp: (WebCore::AXObjectCache::modalElementHasAccessibleContent): (WebCore::AXObjectCache::isNodeVisible const): (WebCore::AXObjectCache::getOrCreate): (WebCore::isNodeFocused): (WebCore::isNodeAriaVisible): Deleted. * Source/WebCore/accessibility/AXObjectCache.h: * Source/WebCore/accessibility/AccessibilityNodeObject.cpp: (WebCore::AccessibilityNodeObject::textUnderElement const): * Source/WebCore/accessibility/AccessibilityObject.cpp: (WebCore::AccessibilityObject::defaultObjectInclusion const): * Source/WebCore/accessibility/AccessibilityRenderObject.cpp: (WebCore::AccessibilityRenderObject::addNodeOnlyChildren): Canonical link: https://commits.webkit.org/284905@main
ARIA spec change to make aria-hidden="false" the same as undefined: w3c/aria#2090 Fixed: 1500299 Change-Id: Ibd3ea96445519b9eb671a68809a95353fa3940cb Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5010376 Auto-Submit: Aaron Leventhal <aleventhal@chromium.org> Commit-Queue: Benjamin Beaudry <benjamin.beaudry@microsoft.com> Reviewed-by: Benjamin Beaudry <benjamin.beaudry@microsoft.com> Cr-Commit-Position: refs/heads/main@{#1278372}
resolves #1256
This PR modifies the previous note about aria-hidden=false to instead indicate that as of ARIA 1.3 is serves as a synonym for the 'undefined' value.
It also includes a minor editorial change to remove the mention of 'screen readers' from the last paragraph of the normative text. It seemed to state, especially when the sentence ends with referring to 'assistive technologies' in general.
See last comment
Question: assuming this PR is approved, would we also want to add the following sentence to the note?
PR tracking
Check these when the relevant issue or PR has been made, OR after you have confirmed the
related change is not necessary (add N/A). Leave unchecked if you are unsure. Read the
Process Document or
Test Overview for more information.
Implementation tracking
Preview | Diff