A lot of the times, when we discuss the Web Content Accessibility Guidelines (WCAG) 2.1, there is a misconception that if you meet all of the criteria then your service will work for everyone. Here is a little thread to explain why #WCAG itself is not enough.
It's very difficult to gauge how accessible something is or isn't based on WCAG alone. There are 3 levels (A, AA, and AAA). However, AA is pretty much the minimum standard, and even @w3c who wrote WCAG do not advocate for trying to meet AAA across the board.
So, if #WCAG level AA is the minimum, and AAA is not recommended across the board, we can almost think of WCAG 2.1 AA as a binary standard. You meet it or you don't. Until WCAG 3.0, there is not really scale to measure how accessible or inaccessible something is.
This means you can have something which is 'technically compliant' and yet totally unusable. If the context is missing, the layout is convoluted or the content is complex, you can be 'compliant' yet have a totally inaccessible application.
A good example of this is acronyms. They fall under AAA criteria (as does a lot of the content based things). So you can be legally compliant despite none of your content really making sense to people. If it doesn't make sense, people can't use it and therefore it's inaccessible.
On the flipside, you can have something which is non-compliant and work for most people. For example, if you have 1 thing per page, but your session times out after 10 hours, you'd be non-compliant. But most people can fill in 1 field in 10 hours so it's unlikely to cause issues.
WCAG is also super subjective. 5 people can audit the same service and get different results. I'm a particularly harsh auditor, even if something is not a strict failure I add it to the report if it's a potential barrier. But if it's not a failure, do people care to fix it?
The trouble with the Accessibility Regulations and #WCAG 2.1, is that it does not encourage inclusion. It's a list of requirements and it creates a culture of checkbox ticking. You can be legally compliant without talking to a single user of your service and that is not ok. #a11y
The requirements for meeting the GOV.UK Service Standard is higher. You can be legally compliant, but you can't pass a Service Assessment without including users with impairments in your research. And this is the critical part to making things truly accessible!
To know something is accessible, you need to prove it by observing people succeed in using it. A push-door meets the minimum standard you'd expect of a door by adding a handle, but if you watched 10 people try to pull it instead of pushing it, you'd know it was a terrible design.
So apply the same logic with accessibility. Meet the minimum standards. Do your WCAG checks. But don't pat yourself on the back for being compliant. Invite a diverse group of people to come and use what you built and you will find out truly how accessible or inaccessible it is.
Accessibility is about making things work for people. It's not passing an assessment or ticking a box to say you meet a standard. It's about people and their needs just like any other part of user centred design. Do legal compliance as the absolute minimum, but always go further!
• • •
Missing some Tweet in this thread? You can try to
force a refresh
It's good to understand how other people might feel, but don’t assume you know their needs. 1 in 3 show unconscious bias towards people who have a disability. Include a diverse group of people and be collaborative when designing services.
2. Accessible design is good design
Good design meets needs and solves problems. If you design something which is inaccessible you create barriers. Good design is not just what looks good, it must work for everyone regardless of what tools they use or what impairments they have.
I've recently been collecting accessibility audits to try and understand what makes a good one, what makes a bad one, and if there is any work we can do to try and standardise them a bit, at least across Government. Here is a thread of my findings.
The World Wide Web Consortium (W3C) outlines that an audit should include 8 things:
1: Executive Summary
2: Background
3: Scope
4: Reviewer(s)
5: Review process
6: Results and recommendations
7: References
8: Appendices w3.org/WAI/test-evalu…
I got sent a whole bunch of audits, so a big thank you to everyone that got involved! A lot of them were conducted by the same organisations so looked at 10 audits by 7 organisations. The additional 3 are significant iterations to the format or process by 2 of the organisations.