-
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
Removing 4.1.1 #2797
Removing 4.1.1 #2797
Conversation
Add script to remove it post-generation
This reverts commit 2b6caec.
just noting that this may break backwards-compatibility, or rather: it's possible for a site to be conformant to 2.2 but non-conformant to 2.1/2.0. |
Yep, and we did discuss that on the call. Partly these things should be caught by other SCs (primarily 1.3.1, 4.1.2), partly allowed by the exception "where allowed by the spec", and partly that it creates so much noise people are ignoring it anyway. Also, a couple of people volunteered to do a mapping exercise of things 4.1.1 caught that should be caught by other SCs. |
People ignoring the SC doesn't sound like a valid reason for removing it. We have rarely had a client that wasn't able to meet this SC. It's actually one of the easier SCs to fix because all you need to do is write valid code. If people are not willing to do that, it's difficult to imagine them meeting all the other success criteria. |
Unless they are ignoring it for good reason.
That's almost the opposite of my experience. With the exception of a publisher (who was also exporting to ePub), it is one of the most time consuming SCs to test and fix. Partly because you have to wade through so many results and filter down to what you actually need to fix. And then doing so rarely had a perceptible effect unless it was also causing issues elsewhere (e.g. for 4.1.2). I'd much rather spend time testing (or teaching people how to test) 1.3.1 and 4.1.2 efficiently. One of those methods can be validation, but the signal to noise ratio is not good in most cases I've come across. |
What would be a good reason for ignoring it? I seriously can't think of one. Presumably there was a rationale for this SC being included in WCAG 2.0, in which case it should not be removed just because some people don't want to make the effort to write valid code. I would expect to hear a much more powerful justification than that. Standards should not be lowered just so everyone can pass. Where did the suggestion to drop it come from? I haven't seen any complaints about this SC on the WebAIM and IAAP forums or anywhere else. Is there really any demand for dropping it? |
Sorry, I didn't realised you'd missed all the context. Most of it is in #2525, but see also the original reason for the SC, which no longer exists. Also, the discussion in #2525 highlighted that many (most?) people (including AG members) have been interpreting it more widely than intended, failing more things than was intended. (I.e. the 'content model' was not intended to be covered.) Added to the fact that the "original rationale" is no longer relevant, we've had a lot of people saying that, particularly at larger scales, it creates more "busy work" than work which actually improves accessibility for people. My personal experience has been that the useful parts are caught under 1.3.1 and 4.1.2, and the effort in 'validating' webapps based in React/Angular etc vs testing the other SCs is not worth it. So those have been the "good reasons" for ignoring it. |
/me looks up from a super cryptic and dense results page on validator.w3.org/nu, which is close to impossible to actually use due to use of react, web components, and just sheer amount of markup and deeply nested structures... yup |
Yes, but only for a site that is non-conformant to 2.0/2.1 because of only failures against SC 4.1.1 which don't map to other SC (already in 2.0/2.1) -- such as duplicated-but-unused IDs. |
sure, but that's still breaking backwards compatibility. so IF 4.1.1 gets removed (which, don't get me wrong, I'm all in favour of), this nuance should be called out in the intro for the spec/wherever it talks about being backwards-compatible |
Agreed, and that was part of the conversation on the Tuesday call, but we tabled that part of the conversation. There will be some details to work out!
I agree with "many people" and that this includes some AG members. I have a hard time believing that it is "most'. We also have many people, including some AG members, who (understandably IMHO) deliberately ignore 4.1.1. |
We also need to add a little nuance, the requirement it was addressing is backwards compatible, but there can be differences in the results of an audit. |
Capitalized Success Criterion and Success Criteria in all cases
Approved: https://www.w3.org/2022/11/22-ag-minutes.html#t08 More changes to come, e.g. mapping table and commentary on backwards compatibility. |
@alastc Should this have been removed in |
Arg. Yes. It's a template thing, I'll have to check with Michael. |
@alastc Appears to be fixed! |
Cross-reference: #2525 (comment)
Preview | Diff