Closed thibaudcolas closed 9 months ago
Agreed, this could do with tightening up. Consider it added onto the list for the next draft.
Thanks @AlexDawsonUK!
I've gone through the specification replacing all of the offending content (spotting a few myself!) Hopefully I've caught all of them, I've definitely done all of the ones you managed to find so the language is much tighter now. The updates are visible immediately in the living specification, and will be published in the next public draft specification. I'll mark this as complete as it's entered into the specification, but if any more are found and commented as such, I'll immediately re-open to continue working on it.
Thank you @AlexDawsonUK!
There are a number of occasions in the guidelines where I think there’s room for improvement on terminology around accessibility, and occasions where the guidelines seem to have accessibility confused with general usability or inclusivity. I wouldn’t find this too problematic for general writing on the web, but for web guidelines, I think it’s paramount to have high standards around terminology.
The general issues are:
6. Glossary
I thought I’d start with this one as this is perhaps where all the other issues stem from. I’m not aware of anyone who refers to web accessibility as Inclusive Design. They’re certainly related concepts but this makes it sound like they’re synonyms, which is very much not the case.
Perhaps this could be replaced with a more formal, agreed-upon definition from WCAG / WAI / WAI EOWG. Or if this standard wants to make the case that "Accessibility" is also about Usability, Inclusiveness, etc – then I think this ought to be made very clear in the introduction and in a glossary entry like this.
In the context of the web, I find people use the term "accessibility issue" more to describe the problems with the web content, than to describe accessibility needs or disabilities. For example, "missing alt text" is a common accessibility issue. I’m not too well versed in inclusive language but I think lots of people would disagree with referring to for example neurological conditions as "issues". "disabilities" or "needs" I believe are more generally-accepted.
1.2.2 Guidelines
I believe WCAG 3.0 "bronze to gold" rating is at the level of a conformance claim, and explicitly not at the guideline level contrary to A/AA/AAA. I think it’s also meant to encourage "progress over perfection". In any case, personally I think WSGs could explain its approach to conformance without relying on what seems like a dig at another standard. At least the WCAG 3.0 reference feels very superfluous considering it’s so far away from being practically useful.
2.9 Respect the Visitor's Attention
I don’t understand what this point has to do with accessibility. What does "by providing a method for them to engage with your product or service" mean? Data emissions, screen time, and power usage don’t have much to do with accessibility.
2.2 Assess and Research Visitor Needs
Under Benefits,
This is minor but I find the calling out of "extra features" problematic. It can be misconstrued as perpetuating the idea that accessibility is something that has an added effort "on top" of building something. This could be easily rephrased as "inclusive design improvements".
Or just make this all much shorter / to the point:
2.13 Use a Design System To Prioritize Interface Consistency
The second sentence feels redundant to me. "reduces the time for implementation" isn’t an accessibility benefit, and the second "decreases the potential […]" is basically a repeat of the first sentence.
2.19 Provide Suitable Alternatives to Web Assets
See above, better terminology than "issue" is available.
2.20 Provide Accessible, Usable, Minimal Web Forms
I would recommend making this about strict accessibility considerations rather than the "cost your business". The connection with emissions is also tenuous at best so I’d recommend removing it. Something like:
2.29 Incorporate Compatibility Testing Into Each Release-Cycle
Two issues here:
3.6 Avoid Code Duplication
Though this is possibly true, considerations about the accessibility of source code don’t strike me as relevant in those guidelines. I’d expect a point about accessibility to cover benefits for end users. Also terminology "accessibility issues" -> "cognitive needs".
3.7 Rigorously Assess Third-Party Services
This is a strange point to me that seems only tenuously related to accessibility. Building something one way or another can potentially improve anything. Reducing third-party services can potentially worsen accessibility if those third-party services help with accessibility. "built-in custom syntax" is very unclear / vague.
3.8 Use HTML Elements Correctly
I don’t understand why this says "readability". To me readability is more about the quality of the content, and about styling, than HTML semantics. Content can be very readable inside a
<div>
element. I’d also recommend caution when associating semantic HTML with accessibility; there are a lot of semantic HTML elements that do nothing for people with accessibility needs (for example a<section>
without a label doesn’t do much). And finally "reducing the time" sounds like an argument about productivity, while accessibility is generally more about removing barriers.3.11 Validate Form Errors and External Input
This is a general usability improvement rather than accessibility specifically. I also don’t understand what the rather than blame for is doing here.
3.13 Adapt to User Preferences
See above "accessibility issues" would be more inclusive and clearer as "accessibility needs".
3.14 Develop a Mobile-First Layout
This is true for all users of all interfaces, so I fail to see the connection to accessibility. It’s a general point about usability. "lead to fewer support requests" is a clear benefit but also has nothing to do with accessibility.
3.15 Use Beneficial JavaScript and Its APIs
Support for older / low-spec devices is a usability / inclusivity consideration, not accessibility.
3.18 Include Files That Are Automatically Expected
This feels true but somewhat weak. It aids usability generally much more than accessibility
3.20 Avoid Using Deprecated or Proprietary Code
I see two issues here:
input type="date"
. This could be addressed by rephrasing this to be about "deprecated" standards instead of merely "old".3.22 Use the Latest Stable Language Version
I don’t understand what this has to do with accessibility. It feels like just a re-statement of the point about performance below.
4.3 Compress Your Files
This narrative feels more like a social equity or inclusiveness thing to me than accessibility. The "may be lower income" feels like a red flag to me – the issue raised here feels like it’s entirely about income and not so much about accessibility.
4.4 Use Error Pages and Redirects Carefully
I don’t think any of this has anything to do with accessibility? Perhaps if there was a point made about how this affect people with specific cognitive needs more, but otherwise this reads like a statement about general UX.
5.5 Estimate a Product or Service's Environmental Impact
I’m finding the wording a bit problematic here. "Inclusiveness" isn’t about removing barriers as much as accessibility is. And as far as accessibility, it seems to me like there are much more obvious exercises than an LCA that can be conducted (a WCAG audit?). I’ve also never seen or heard about an LCA that covers inclusiveness or accessibility, so this whole statement is puzzling to me.