Updated 15.2.2025 to better reflect points I was trying to made with the post.
When we start learning about accessibility we may get a feeling that it is mainly for screen reader users. And when we give it a bit of thought it’s kind of obvious that Web Content Accessibility Guidelines (WCAG) include a lot of focus on screen readers and perhaps not enough focus on other assistive technologies – it seems that they perhaps overly rely on the non-normative part of the Understanding documents (opens in new window) when doing so. My guess is that people just miss the warning “Informative explanations, not required to meet WCAG” and may even think that understanding documents are actually WCAG (normative).
Cognitive accessibility is even less represented. There seems to be quite a logical situation when we consider how different we – the people – are.
It’s way easier to define guidelines that can be interpreted by technology when we compare it to the diversity of the human experience (from sensory to cognition and beyond). I guess this may also be the reason for some people to give up on accessibility.
Similarly it’s also easier to write test rules for the guidelines that can be interpreted directly by technology. For example – screen reader needs to get the info about the label that is connected to an input field. Or screen reader needs status message when we add an item into shopping cart without the move of focus. These are obvious – code reflects design and interaction and screen reader interprets the underlying code (with help of accessibility tree and sometimes beyond).
That explains a bit, but let us check approximate numbers – what part of guidelines are dedicated fully or partially to screen readers.
Mapping screen reader to the guidelines
When we measure we need to first define how we will do it. I decided to count all WCAG 2.2 success criteria (opens in new window) that are solely dedicated to screen readers, but that would not be enough, so I also added criteria that are partially including screen readers (not based solely on the WCAG, but also on the non-normative understanding documents).
| WCAG 2.2 levels | Sum | Yes | No |
|---|---|---|---|
| A, AA and AAA | 87 | 37 | 50 |
| A and AA only | 56 | 29 | 27 |
When we think about levels A and AA, that are mostly used in most cases – from other standards like EN 301 549, to legislation – we may note that screen readers are directly or indirectly impacted by 30 out of 56 success criteria – especially when checking the understanding documents.
You probably wonder which success criteria are included, so I prepared a list of them (levels A, AA and AAA). Once again – some success criteria are only partially impacting screen readers and some are only there for screen readers.
- 1.1.1 Non-text Content (Level: A)
- 1.3.1 Info and Relationships (Level: A)
- 1.3.2 Meaningful Sequence (Level: A)
- 1.3.3 Sensory Characteristics (Level: A)
- 1.3.5 Identify Input Purpose (Level: AA)
- 1.3.6 Identify Purpose (Level: AAA)
- 1.4.1 Use of Color (Level: A)
- 1.4.13 Content on Hover or Focus (Level: AA)
- 2.1.1 Keyboard (Level: A)
- 2.1.4 Character Key Shortcuts (Level: A)
- 2.2.1 Timing Adjustable (Level: A)
- 2.2.2 Pause, Stop, Hide (Level: A)
- 2.2.3 No Timing (Level: AAA)
- 2.2.4 Interruptions (Level: AAA)
- 2.2.5 Re-authenticating (Level: AAA)
- 2.2.6 Timeouts (Level: AAA)
- 2.4.1 Bypass Blocks (Level: A)
- 2.4.2 Page Titled (Level: A)
- 2.4.3 Focus Order (Level: A)
- 2.4.4 Link Purpose (In Context) (Level: A)
- 2.4.5 Multiple Ways (Level: AA)
- 2.4.6 Headings and Labels (Level: AA)
- 2.4.9 Link Purpose (Link Only) (Level: AAA)
- 2.4.10 Section Headings (Level: AAA)
- 2.5.3 Label in Name (Level: A)
- 3.1.1 Language of Page (Level: A)
- 3.1.2 Language of Parts (Level: AA)
- 3.2.1 On Focus (Level: A)
- 3.2.2 On Input (Level: A)
- 3.2.3 Consistent Navigation (Level: AA)
- 3.2.4 Consistent Identification (Level: AA)
- 3.2.5 Change on Request (Level: AAA)
- 3.3.1 Error Identification (Level: A)
- 3.3.2 Labels or Instructions (Level: A)
- 4.1.1 Parsing (Level: A, deprecated in reality)
- 4.1.2 Name, Role, Value (Level: A)
- 4.1.3 Status Messages (Level: AA)
I’ve also counted all occurrences of “screen reader” in the understanding documents and found it in 55 cases.
Conclusion – bias is there, but we must inform about it
One can say that it makes sense people may focus too much on screen readers as they are over-represented in the WCAG supporting documents and therefore they can also be over-represented when we teach and learn about (digital) accessibility.
We must therefore make some additional effort when we learn about, promote, teach and implement accessibility to add context to this:
- It is about people first and foremost. We can think of the WCAG as an abstraction for this important fact. Like code is for design etc.
- WCAG is technology agnostic, but we still need to take into account accessibility supported (opens in new window) at the end of the day.
- Even if screen readers are seemingly (!) over-represented (they are not when we know more), we need to extend our knowledge to other assistive technologies like zooming, switch control, voice control and more.
- WCAG are mostly baseline – we can and must do better.
- We need more research and best practice for cognitive accessibility.
This lead to the fact that we have a lot of resources that go beyond screen readers. As mentioned – it’s not simple to make guidelines for cognitive accessibility, but thanks to amazing people and organizations we don’t have a blank ark.
Please check Cognitive and Learning Disabilities Accessibility Task Force (COGA, opens in new window) and their Making Content Usable for People with Cognitive and Learning Disabilities (opens in new window).
I think you’ve drawn an excellent conclusion at the end (accessibility is for people first) but just referring to criteria that benefit screen readers and saying they’re over-represented is a fallicy. A bunch of criteria benefit screen reader users AND others at the same time. Take 2.4.3, 1.3.2, 1.3.1, etc. etc. etc. Not to mention 2.1.1. I would say the greater flaw lies in how WCAG is taught and interpreted, not in WCAG itself.
Thank you for your comment.
I wrote about the fact that overlapping criteria benefits other users as well, totally agree, as I also agree with lot of potential improvements for teaching and interpreting WCAG.
And this does not change the fact that we need more guidelines that cover other areas (which are, as mentioned, often not so simple to define because of their complexity and diversity).
EN 301 549 is trying more, but I hope we can land on something even better with WCAG 3 (although it’s obvious that it will take a lot of time, research and compromises to get there).
> And when we give it a bit of thought it’s kind of obvious that Web Content Accessibility Guidelines (WCAG) include a lot of focus on screen readers and perhaps not enough focus on other assistive technologies
This is factually false. “Screen reader” is mentioned twice in WCAG, both in non-normative notes/examples.
The list of “SCs only for screen readers” also applies to a lot of other technologies like voice control, enabling users to set styles based on interactive elements.
Dragging movements is there to allow users to use drag and drop with the keyboard, without screen readers.
Yes, all of the SCs _also_ apply to screen readers, but they are important to make accessibility APIs work across assistive technologies.
WCAG is on purpose agnostic of the used technologies. Only because most people learn accessibility as screen readers accessibility and do not learn how SCs apply to other assistive tech, does not mean that WCAG applies only to screen readers.
Thank you for your comment.
Totally agree with your points – with this post really I wished I can, hopefully, make people stop thinking about accessibility as mostly for screen readers (as some still often do).
“Screen reader” (excluding the key terms section of course) can be found 55 times in the Understanding docs and that can be one of the reasons, I guess (added this to the blog with some minor corrections, thanks).
When I started to learn about accessibility I made similar mistakes and when I even bought courses where understanding documents were almost presented as the guidelines itself I don’t doubt others make same mistake.
Unfortunately I still hear about this often as people over rely on the non-normative understanding documents, so I hope we can do more to stop this and, as you wrote – let people know there are more assistive technologies that can benefit us because of WCAG, accessibility APIs and more.
So the Understanding documents should not explain how success criteria relate to screen reader usage at all?
Not saying that, no, it’s very useful to provide that info, it just seems that we need more info about other assistive tech.
Thanks, too often people teaching about accessibility just say screen readers when they mean assistive technology. That then reenforces this bias you want to advocate against in this post.
Totally agree that we need more info about other assistive technologies to spread awareness. That would also help to diminish the wrong idea of “accessibility is for blind people” and “we don’t have blind users” that come with it (still too many people that unfortunately think like that).
Thank you for your comment.
Very well put, was kind of trying to say that as well in the point of awareness, but like your summary.
It is also important to consider that the vast majority of the audience discussing accessibility within a project are not the engineers doing the work, but product and business people, and clients, who need tangible concepts and examples to point to. Screen readers provide a clear hook to hang your discussion onto and often act as a catchall “screen readers and other accessible technologies”.
If you want to convince somebody that its beneficial and worth spending time and money on, you need a target. Screen Readers are a hot topic that’s easy to bucket, whereas “some people who have varying degrees of cognitive issues” or “nameless assistive technologies that make some things easier” become increasingly hard to discuss conceptually. Especially as these rules are often the ones that become the most subjective.
I don’t see the literal guidelines as being the problem here, but instead the lack of good examples that make it clear how following accessibility guidance results in better experiences.
Thank you for your comment.
Totally agree, it makes it a bit simpler to say “screen readers and other assistive technology” indeed.
And when stakeholders actually see and hear how screen readers work for the first time in their lives it makes quite an impression on them, so I guess that is also a consideration.
It seems that I used guidelines too loosely, I can see this now after all the comments. And totally agree with the lack of good examples – we need more of them.
I learn most from people using different assistive technology and sometimes when I try to use them myself (can not be compared as people that depend on them are the real experts).