Accessibility beyond WCAG

Robots or humans?

For many developers, the Web Content Accessibility Guidelines (WCAG) are second nature. But ticking all the boxes still doesn’t automatically mean a great user experience. The way we think about accessibility has shifted from “make sure machines can read it” to “make sure people can understand it”.
Surveys show most people using assistive technology feel their experience could be improved a lot by better websites, but won’t report problems they encounter. Your site could be compliant but still pose challenges to your users without you knowing.

Who are we designing for?

Accessibility is about reducing friction for many kinds of users, each with their own tools, habits, and challenges. Some have permanent disabilities, others temporary injuries, neurodivergence or other needs that can make interacting with a website challenging:

• Blind users who want to get an overview of the content quickly.
• Low-vision users who zoom to 200–400% and rely on contrast or custom stylesheets.
• Colour-blind users who miss important cues when colour is the only signal.
• Deaf and hard-of-hearing users who rely on captions and transcripts.
• Motor-impaired users who navigate by keyboard or speech recognition.
• Neurodivergent users who might benefit from plain language, short paragraphs, predictable flow, or reduced motion.
• Older adults who are more likely to have reduced vision, hearing, dexterity, and less familiarity with new interfaces.

Sometimes the needs of different groups can almost contradict each other; e.g. blind users often want concise, skimmable pages, while low-vision users may prefer fuller descriptions to make sense of elements they perceive but can’t see properly.

As developers, it’s easy to fall into shorthand thinking like lumping “keyboard and screenreader” together and assuming things like a screenreader-only skip link works for everyone. But accessibility isn’t a single combination of tools. Not all keyboard users rely on screenreaders, and not all screenreader users navigate primarily by keyboard. Many people browse with mobile screenreaders like VoiceOver (iOS) or TalkBack (Android). Others use braille displays, switch devices, or eye-tracking systems — each creating a different experience.

To design accessibly, we need to think beyond a single setup and account for the diverse ways people actually interact with the web.

Why developer testing often falls short

• Sight bias: As sighted developers, we might tab through a page for testing, but we don’t realise how much we’re leaning on visual cues. Try covering your screen and navigating only by audio — it can be very disorienting.
• Experience gap: Skilled assistive-tech users move quickly and customise heavily. A quick “tab test” by a developer barely scratches the surface.
• Diversity of needs: As developers, it can be very hard to imagine what the web is like with accessibility needs we haven’t experienced ourselves. It’s even harder to keep all those needs in mind while working within the limits of time and budget.

Guidelines like WCAG are invaluable to simplify that process, but they don’t guarantee a good user experience. In some contexts, they even create friction: we’ve come across several cases where users found them unhelpful or actually hindering.
This doesn’t make the guidelines wrong — it just means we need to also think about how real people actually use the web.

The reality of accessibility needs

People interact with the web in many different ways, using a mix of assistive technology, devices, and personal strategies. Navigation styles, preferences, and experience levels can vary widely, as does the way assistive technology interprets and presents content. 
The best way to get an idea of that is through real user testing (e.g. through seemeplease.com). Watching people try to accomplish common tasks, or exploring complex tables, widgets, or menus, provides insights beyond the checklists. Just keep in mind that one person’s experience may not represent everyone’s.

Moving from checklists-only to user experience

In the end, it’s nearly impossible to design perfectly for every need. But aside from just following the WCAG, we can focus on patterns and practices that help multiple groups, keep in mind where groups might differ, and spend more time testing the complex and/or fundamental parts of our sites — like menus, forms, or data tables.

If this feels like a lot of work, remember that many things originally designed for accessibility now benefit everyone. The typewriter was invented for a blind countess who couldn’t write letters by hand. Curb cuts (sidewalk “ramps”) were created for wheelchairs, and audiobooks for vision-impaired readers. That’s just to name a few. Accessibility solutions often become universal improvements.

Insights from real users

Surveys and user testing highlight common pain points – not all of which are automatically covered by WCAG compliance:

• CAPTCHAs, especially image-based ones that block access.
• Complexity, such as layouts, forms, data tables and navigation, or even just too many links.
• “Reveal” patterns like pop-ups, dialogs or expanding sections — anything that changes content can easily be confusing.
• Poor contrast and content that becomes unreadable when enlarged.
• Lack of “skip to main content” links or skip links that are hidden.
• Poor keyboard accessibility.

At the same time, people consistently point to practices that make the web easier to use:

• Correct heading levels: The vast majority of screenreader users rely on headings for navigation. If you choose levels just for styling, you break their map of the page.
• Thoughtful semantic structure: Even as landmark navigation declines, they’re still a good check of your page structure. Semantic HTML makes pages easier to scan and navigate for everyone. We often see everything wrapped in <article> or <section> for everything. This easily happens in a CMS where components are reused in different places.
• Correctly labeled form fields: These give keyboard focus to the field when the text label is selected. Most mouse-users are unaware of this, but keyboard and alt-input-device users find this very helpful.
• Concise, descriptive link texts that work out of context: Screenreaders offer lists of pretty much any element on the page (all headings, all images, all links etc). The list of links is one of the more used ones, but not of much use if links just say “Read more” or spell out the whole teaser.

Conclusion: beyond compliance

Accessibility isn’t about ticking boxes — it’s about reducing friction for real people. WCAG gives us a vital foundation, but it’s not the finish line. The real test is listening to users as they complete real tasks and questioning our own assumptions.

That means:

• Treating guidelines as a baseline, not a guarantee.
• Testing with real users whenever possible.
• Being aware of a diversity of needs, not just “typical” assistive setups.
• Focusing extra care on complex, high-friction areas like navigation and forms.
• If we shift our mindset from ticking boxes to user experience, accessibility stops being a compliance exercise and becomes a shared responsibility for building a more inclusive web.

Further reading:

• https://www.youtube.com/watch?v=OUDV1gqs9GA&list=PLCe6HerpDhgl-jTGcXkYpiChZp_xiHn0B
• https://webaim.org/projects/screenreadersurvey10
• https://webaim.org/projects/lowvisionsurvey
• https://webaim.org/projects/motordisabilitysurvey
• https://prospect.org.uk/article/designing-content-for-users-of-screen-readers/ (also in related articles: designing for motor disabilities, users hard of hearing, dyslexia, anxiety)
• https://www.youtube.com/watch?v=C_BUmpqH9LI