-
Notifications
You must be signed in to change notification settings - Fork 266
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
SC 4.1.1 also for invisible content? #1805
Comments
based on a real world use case: <nameable-element aria-labelledby=foo>...</nameable-element>
<p hidden id=foo>name 1</p>
<div hidden id=foo>oops name</div> That'd still pose an issue though the hidden elements are not directly exposed. For other sorts of parsing errors, it'd depend if the content could become visible/enabled. Some analytical thinking is likely needed in the skillset of the auditor. |
For some things like aria-labelledby which can reference display:none content yes - if you have 2 ids that are the same but different content it could make a difference. For other things like structure that is never shown it may not make an impact if the error doesn't affect tags that are not display none. |
@scottaohara I agree with you that in such cases the correct syntax is relevant. However, there are also pages with syntax errors in invisible areas where there is no reference to them via ARIA. But the SC 4.1.1 applies to all content. After all, no one in the audit probably takes the trouble to check each syntax error individually. My experience is that the HTML validator is used. One more reason to deprecate 4.1.1 |
Yes we do agree on that aspect, @JAWS-test, but your issue here could be interpreted as a flat out ignoring of content that isn't directly exposed to the a11y tree, which could still be problematic as I demonstrated. A common 'failure' i see auditors make is failing documents that have I'd very much like to see the understanding document updated to better clarify that HTML validation issues do not always mean parsing issues, and I think this specific issue is a good starting point of where there needs to be nuance to what's written. |
@scottaohara I don't agree that a style element in the body would be an example that shouldn't cause a violation of SC 4.1.1 because browsers don't have a problem with it. Because that's what 4.1.1 is about: that browsers have repair mechanisms for syntax errors (this is true for most syntax errors checked in 4.1.1, by the way), but first, you can't rely on all browsers and AT to use the same repair mechanisms, and second, there's no guarantee that the mechanisms will work in old or future versions of browsers and AT
My example with the invisible content (which is not referred to by ARIA and which is not switched visible and invisible by scripting) behaves differently: Because these never become relevant for the users of the page, no matter whether with or without AT. Even these must be syntactically correct according to 4.1.1. Therefore my question, whether a corresponding exception should be formulated in the understanding or we continue to stubbornly evaluate every syntax error as a violation of 4.1.1, even if it definitely has no effect on accessibility. |
So then the end goal here is to fail people for some hidden content which isn’t exposed to the accessibility api, but fail them for other content which isn’t exposed to the accessibility api.
seems to me we have the same desire here |
Should 4.1.1 also be checked for invisible content (e.g. display:none, hidden). These are not sent to the Accessibility API, so source code errors should not matter.
The text was updated successfully, but these errors were encountered: