WCAG is hard to read and complicated and it puts a lot of developers off when talking about making their applications accessible.
In this series I am going to try and simplify things down and offer a different approach to WCAG that is hopefully more accessible!
Part of my "year of the series"
This is one of 4 series I am writing this year, you can see the other series here:
Article No Longer Available
What is the series about?
This came about because whenever I start talking about accessibility I get the same responses:
- It is complicated
- WCAG makes no sense!
And you know what people are (kind of) right!
If WCAG was easier to understand I think more people would embrace accessibility!
And I am arrogant enough to believe that I am the one to solve this problem! 🤣
What will you get out of this series?
A complete run through of the WCAG "rules" and guidance covering:
- examples of code / markup,
- simplified explanations of the guidance and none of the "fluffy" stuff that causes confusion (where the W3 team attempt to accommodate rare edge cases)
- who it affects (user story and why it matters)
- who's responsibility it is in a team
To achieve this I will be using the following structure in each article:
- Introduction (what does this criterion cover / summary)
- Contents
- Why is this criterion important
- user story
- relevant "temporary disabilities" such as broken arm, direct sunlight etc.
- Disability categories it impacts (cognitive, visual, hearing etc.)
- General UX improvements fixing this item brings
- Business Impact (for persuading business owners / stakeholders)
- How to test whether your site passes this criterion
- Manually
- Automated
- How to fix any problems
- General guidance
- Code examples (for web)
- Design examples (if this is visual, such as contrast)
- Exceptions to this criterion
- Additional Tips
- Tricks for long term consistency
- Conclusion and further reading
That should hopefully make the guides much easier to skim through to find what you need!
Why am I writing this series?
I want to be able to point people to an article when explaining an accessibility concept to them (especially as part of my ultimate UI series!).
Additionally I want to make accessibility more accessible (the irony!) so that more people embrace it.
Finally I am working to "get known" for accessibility within the industry for a product I am building, so this is a way to showcase my knowledge while hopefully helping the developer and designer communities!
Ok it sounds interesting, what will the series cover?
All of the WCAG success criterion (including the WCAG 2.2 draft items).
It will also explain the conformance levels of A, AA and AAA and other terminology in the first episode of the series!
Item | SC | Level |
---|---|---|
Non-Text Content | 1.1.1 | A |
Audio-only and Video-only (Prerecorded) | 1.2.1 | A |
Captions (Prerecorded) | 1.2.2 | A |
Audio Description or Media Alternative (Prerecorded) | 1.2.3 | A |
Captions (Live) | 1.2.4 | AA |
Audio Description (Prerecorded) | 1.2.5 | AA |
Sign Language (Prerecorded) | 1.2.6 | AAA |
Extended Audio Description (Prerecorded) | 1.2.7 | AAA |
Media Alternative (Prerecorded) | 1.2.8 | AAA |
Audio-only (Live) | 1.2.9 | AAA |
Info and Relationships | 1.3.1 | A |
Meaningful Sequence | 1.3.2 | A |
Sensory Characteristics | 1.3.3 | A |
Orientation | 1.3.4 | AA |
Identify Input Purpose | 1.3.5 | AA |
Identify Purpose | 1.3.6 | AAA |
Use of Color | 1.4.1 | A |
Audio Control | 1.4.2 | A |
Contrast (Minimum) | 1.4.3 | AA |
Resize text | 1.4.4 | AA |
Images of Text | 1.4.5 | AA |
Contrast (Enhanced) | 1.4.6 | AAA |
Low or No Background Audio | 1.4.7 | AAA |
Visual Presentation | 1.4.8 | AAA |
Images of Text (No Exception) | 1.4.9 | AAA |
Reflow | 1.4.10 | AA |
Non-text Contrast | 1.4.11 | AA |
Text Spacing | 1.4.12 | AA |
Content on Hover or Focus | 1.4.13 | AA |
Keyboard | 2.1.1 | A |
No Keyboard Trap | 2.1.2 | A |
Keyboard (No Exception) | 2.1.3 | AAA |
Character Key Shortcuts | 2.1.4 | A |
Timing Adjustable | 2.2.1 | A |
Pause, Stop, Hide | 2.2.2 | A |
No Timing | 2.2.3 | AAA |
Interruptions | 2.2.4 | AAA |
Re-authenticating | 2.2.5 | AAA |
Timeouts | 2.2.6 | AAA |
Three Flashes or Below Threshold | 2.3.1 | A |
Three Flashes | 2.3.2 | AAA |
Animation from Interactions | 2.3.3 | AAA |
Bypass Blocks | 2.4.1 | A |
Page Titled | 2.4.2 | A |
Focus Order | 2.4.3 | A |
Link Purpose (In Context) | 2.4.4 | A |
Multiple Ways | 2.4.5 | AA |
Headings and Labels | 2.4.6 | AA |
Focus Visible | 2.4.7 | A |
Location | 2.4.8 | AAA |
Link Purpose (Link Only) | 2.4.9 | AAA |
Section Headings | 2.4.10 | AAA |
Focus Appearance (Minimum) | 2.4.11 | AA |
Focus Appearance (Enhanced) | 2.4.12 | AAA |
Page Break Navigation | 2.4.13 | A |
Pointer Gestures | 2.5.1 | A |
Pointer Cancellation | 2.5.2 | A |
Label in Name | 2.5.3 | A |
Motion Actuation | 2.5.4 | A |
Target Size (Enhanced) | 2.5.5 | AAA |
Concurrent Input Mechanisms | 2.5.6 | AAA |
Dragging Movements | 2.5.7 | AA |
Target Size (Minimum) | 2.5.8 | AA |
Language of Page | 3.1.1 | A |
Language of Parts | 3.1.2 | AA |
Unusual Words | 3.1.3 | AAA |
Abbreviations | 3.1.4 | AAA |
Reading Level | 3.1.5 | AAA |
Pronunciation | 3.1.6 | AAA |
On Focus | 3.2.1 | A |
On Input | 3.2.2 | A |
Consistent Navigation | 3.2.3 | AA |
Consistent Identification | 3.2.4 | AA |
Change on Request | 3.2.5 | AAA |
Consistent Help | 3.2.6 | A |
Visible Controls | 3.2.7 | AA |
Error Identification | 3.3.1 | A |
Labels or Instructions | 3.3.2 | A |
Error Suggestion | 3.3.3 | AA |
Error Prevention (Legal, Financial, Data) | 3.3.4 | AA |
Help | 3.3.5 | AAA |
Error Prevention (All) | 3.3.6 | AAA |
Accessible Authentication | 3.3.7 | AA |
Accessible Authentication (No Exception) | 3.3.8 | AAA |
Redundant Entry | 3.3.9 | A |
Parsing | 4.1.1 | A |
Name, Role, Value | 4.1.2 | A |
Status Messages | 4.1.3 | AA |
As you can see that is quite a list!
Cool, I am looking forward to it, what should I do now?
First thing is first, you should bookmark this page as it will serve as the "index" for the series so you can quickly jump between articles (I will link to each article in the above table as they are released).
Then follow me on DEV.to if you don't already!
After that the only other thing you should do is follow me on Twitter as I will be releasing some bonus material over there and upping my Twitter game too this year!
Wrapping up
I hope this series will get people, both beginners and seasoned pros, more interested in accessibility and help you improve your designs and code!
Plus if people come up with better ways to explain things it is always good to get community feedback so I can improve my articles!
I hope this series is useful for everyone and (fingers crossed) becomes a well known resource that helps us all fix the 97.4% of websites that have accessibility errors!
Top comments (6)
Do you find WCAG confusing or do you think this series is a waste of time?
Let me know in the comments!
Oh and thanks for reading this (and my other articles I just released if you have read them), have (another) ❤ and 🦄 to show my appreciation!
It's not only confusing - it's regressive. We had to make our site less usable.
That is interesting, do you have an example as I would love to hear about it, I find anything that is "bending to fit the rules not the goal" fascinating and helpful!
I can't send you a link because I work for an elected official and it would put a big 'ol target on our backs.
The basic problem is that it is forcing developers to provide exactly the same experience for sighted and non-sighted users. That's ridiculous. The experience will never be the same.
I'll start by saying - I was the advocate for accessibility on our team. I encourage everyone to write semantic code, make accessible tables and provide descriptive links and alt text.
To that end, the site is built like a table of contents. So every item in the top nav goes to a page with all the next level links. We also have drop-down mega menus with shortcuts to the most frequently used pages in the section. They are coded as nested lists. The mobile version does not have the menus, but you can still navigate to anywhere on the site.
It used to be that you could hover to open the menu then click in the same spot to go to the landing page. But no - that confuses the SR. The SR can still read and follow all the links in the menu, it just doesn't tell you when the menu is opened or closed. For some reason it's important for someone who can't see the screen to know whether the menu is open or not - even though the SR user can skip easily skip nested links that aren't relevant.
So we had to re-code, adding a bunch of aria - which tripled the amount of code needed for the menu - AND you can no longer just click on the nav bar to go to the next level - you have to mouse over to another link. So the site now has more code, more fragile code because of aria, slower download times, and its harder to use for the overwhelming percentage of users who do not use a screen reader - including those who have motor-skill issues. But it passes WCAG.
All this when the mobile version of the site is perfectly accessible to everyone as is. There should be a media query for screen readers. You could strip out all javascript and css. And if the HTML was coded correctly, it would be perfectly accessible.
Sorry for the long rant - I just find it frustrating that we went from the spirit of the law to the letter of the law.
I'll also point out that when we originally built all this in 2016-17 it passed WCAG1.0. Our code didn't change - the rules changed.
Eagerly waiting for the series to released, especially
2.4.3
and4.1.2
😛Focus order is one of my favourites as it amazing how many
tabindex=2
You see out there breaking stuff!Hopefully my articles don’t disappoint! 🤞❤️