DEV Community

Cover image for WCAG in plain English [🦾 EP0: Series introduction and posts for the year! 🦾]
GrahamTheDev
GrahamTheDev

Posted on • Edited on

WCAG in plain English [🦾 EP0: Series introduction and posts for the year! 🦾]

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:


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!


 

 

**I hope you have a fantastic 2021!**

 

 


Top comments (6)

Collapse
 
grahamthedev profile image
GrahamTheDev • Edited

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!

Collapse
 
riobrewster profile image
RioBrewster

It's not only confusing - it's regressive. We had to make our site less usable.

Collapse
 
grahamthedev profile image
GrahamTheDev

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!

Thread Thread
 
riobrewster profile image
RioBrewster • Edited

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.

Collapse
 
itzsrikanth profile image
itzsrikanth

Eagerly waiting for the series to released, especially 2.4.3 and 4.1.2 😛

Collapse
 
grahamthedev profile image
GrahamTheDev

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! 🤞❤️