Skip to content
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

Closed
JAWS-test opened this issue May 12, 2021 · 6 comments
Closed

SC 4.1.1 also for invisible content? #1805

JAWS-test opened this issue May 12, 2021 · 6 comments

Comments

@JAWS-test
Copy link

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.

@scottaohara
Copy link
Member

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.

@mraccess77
Copy link

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.

@JAWS-test
Copy link
Author

@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

@scottaohara
Copy link
Member

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 <style> as a descendant of the <body> element. This I think fits very well into for what I think is the intent for this issue. By the normative language of the SC "elements are nested according to their specifications" then because style is not allowed as a descendant of body this "fails". But in reality, browsers handle this just fine and there are zero reasons, aside from being pedantic, to fail someone for this "parsing" issue.

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.

@JAWS-test
Copy link
Author

@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

Since repair techniques vary among user agents, authors cannot assume that content will be accurately parsed into a data structure or that it will be rendered correctly by specialized user agents, including assistive technologies, unless the content is created according to the rules defined in the formal grammar for that technology (https://w3c.github.io/wcag/understanding/parsing.html)

Maximize compatibility with current and future user agents, including assistive technologies. (https://w3c.github.io/wcag/guidelines/#compatible)

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.

@scottaohara
Copy link
Member

scottaohara commented May 13, 2021

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.

Style Of course likely not to have its default UA CSS of display none undone. But an element set to display none by the author could (by a function of the page or a user overwriting the style sheet). Or, speaking of making sure old browsers are taken into account, guess that means hidden Isn’t safe either?

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.

seems to me we have the same desire here

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants