Accessibility As An Equivalent Experience
Embracing an equivalent experience in digital design often starts with a fundamental shift in how you approach development. It means questioning established practices and taking a hard look at your existing work through the lens of inclusion. The Web Content Accessibility Guidelines (WCAG) serve as the canonical, internationally recognized standard for what makes a digital experience usable, having been codified as an ISO standard over a decade ago. While the guideline document is comprehensive and dense, it provides a definitive framework for accessibility.
For developers looking to internalize this framework before diving into the specifics of WCAG, a powerful self-check question can be: “How would I use this if…?” This approach forces you to surface and examine personal biases that may unknowingly shape your design decisions.
Useful completions to that question might include:
- …I can’t see the screen?
- …I can’t move my arms?
- …I’m sensitive to flashing and strobing animation?
- …English isn’t my primary language?
- …I have a limited budget for bandwidth?
- …I’ve set a large default type size?
This framing aligns with the broader principle that accessibility goals are usability goals. A design that is easy to see, easy to hear, easy to interact with, and easy to understand will inherently serve a wider range of people. By focusing on these four parameters—visual, auditory, motor, and cognitive—you elevate the overall quality of the web product for everyone.
For a more digestible entry point into the concepts covered by WCAG, the Inclusive Design Principles offer a gentler introduction. Its seven principles are designed to map directly back to WCAG’s success criteria, making it an ideal resource for teams that want to understand the underlying philosophy of accessible design before tackling the full technical specification.
What Screen Reader Users Actually Run Into
The people I spoke with for this article raised several recurring problems. Each one is a concrete failure of equivalence — and each has a well-understood fix that is worth building in from the start.
Wayfinding: Headings and Landmarks
Heading elements do double duty. For sighted readers, they create a visual hierarchy that makes scanning easy. For screen reader users, they are the primary navigation tool: a way to get a quick outline of the page and jump straight to relevant sections. WebAIM’s screen reader survey consistently ranks headings as the most important method for finding information.
When headings are authored poorly — skipped levels, styled <div>s standing in for real headings — that navigation breaks down. Justin Yarbrough, one of the people I interviewed, echoed a common frustration: badly structured heading elements leave users to wade through content that should have been skippable.
Landmarks are the second major wayfinding tool. These roles come implicitly from HTML sectioning elements like <main>, <nav>, and <header>, and they let assistive technology users get a sense of the page's overall layout — or jump directly to a region. Without a main landmark, Justin describes being "stuck trying to scan the page to find it arrowing through the page."
The lesson is to treat structural HTML elements with the same care you would give to layer names in a design file. A class named c-nav-primary conveys intent to other developers; a nav element conveys that same intent to the browser and to assistive technology.
Labels Must Be Real Labels
Form fields without programmatically associated labels were another frequent complaint from my interviewees. Brian Moore described it plainly as "form fields with no label or at least one that isn't programmatically associated so it doesn't read anything."
The fix is not exotic. Pair a label element with a valid for/id attribute, and you have a solution with broad, dependable support. That means using the label element itself — not a clickable div, not a placeholder, and not an aria-label used as a substitute. Those alternatives tend to be brittle or to fall short in unexpected ways.
There is a subtlety worth noting: a label element should always describe a corresponding input. Assistive technology offers shortcuts that jump to input labels, so when a label exists without a paired control, users are taken to a dead end. Reserve label for form fields, and use other elements for labeling diagrams or illustrations.
Alternative Text Is a Participation Requirement
The alt attribute on an image is the mechanism that lets someone with low or no vision understand what that image contributes. The same principle extends to captions for video and audio content, including podcasts. But providing the mechanism is only half the work; the description itself has to be useful.
Kenny Hitt described how a lack of alternative text on social media stops conversation cold: when every image in a thread prompts a request for a description, participation becomes exhausting. The comparison to Mastodon is instructive — there, image descriptions are enabled by default rather than buried in a preference menu, which changes how regularly they are actually provided.
Soren Hamby offered a podcast app example where the alt text had been filled in with the UI state (“unselected” / “selected”) rather than the content they were choosing (“sci-fi genre”). That kind of near-miss is common: the description is present and technically correct but misses the point entirely.
Getting the content right matters enough that services compete on it. Soren noted that accessible features are "often the deciding factor, especially between services," pointing to Netflix's audio descriptions as a loyalty-builder.
ARIA Is Not a Spackle
ARIA exists to extend HTML where native elements fall short. But it is frequently applied where a plain HTML element would have accomplished the same thing — often with worse results. Brian Moore describes the outcome from a user's perspective: "there seems to be a perception that more ARIA fixes accessibility and it can help, but too much either reads wrong things or just talks way too much." The First Rule of ARIA Use is to prefer native elements; ARIA is for filling gaps, not for replacing working semantics.
Over-description is a related failure. A link that says “privacy policy” on screen does not need to be announced as “this link will open our privacy policy, this link will open in a new window.” Assistive technology announces the element type for you, so a concise description of content is all that's required — the same standard you apply for sighted users.
The deeper problem with ARIA is that its behavior is hard to verify. Support varies across operating systems, browsers, and assistive technology products, and it is virtually invisible in code review. Misapplied ARIA can fail to report functionality, announce the wrong functionality, or over-describe it. None of those outcomes produce an equivalent experience.
If you want to know how the ARIA you write actually behaves, hire people who use it daily. Services such as Accessible360, AccessWorks (by Knowbility), Fable Tech Labs, and Perkins School For The Blind all offer exactly that kind of testing.
Contrast: Both Low and High
Color contrast issues were the fifth most significant problem in the Click-Away Pound Survey, and the share of respondents reporting them grew from 44% in 2016 to 55% in 2019. The design community has responded with an abundance of tools: Stark for auditing designs before they are coded, plus options like Eightshape's Contrast Grid and Atul Varma's Accessible color palette builder for assembling accessible palettes from the start.
Contrast is unusual among these issues because it is visible in a literal sense — you can see when a color combination fails. Automated checkers such as Deque's axe will flag contrast failures, and those reports deserve to be taken seriously rather than dismissed, since the difference between passing and failing is, for the affected user, whether the content is readable at all.
For users whose needs go beyond standard contrast ratios, operating systems offer inverted colors mode and High Contrast Mode. Many of the people I interviewed use these modes daily. Semantic HTML handles most of the work here — the key is to actually check your pages in both modes to confirm that your styling doesn't break down when they are active.
Progress, Not Perfection
Léonie Watson’s guidance on accessibility is worth keeping close: it doesn’t have to be flawless, just better than it was yesterday. That mindset shifts the work from an overwhelming, all-or-nothing goal to a series of manageable improvements. When you understand the common barriers users face and know how to address them, you can create experiences that are both functional and genuinely pleasant for everyone.
Tools And Reading For Your Accessibility Work
Expanding your toolkit is one of the most effective ways to keep moving forward. A few resources stand out for their practical focus:
- Accessibility For Teams — A project by Peter van Grieken that helps integrate accessibility into team workflows.
- “One Of My Favourite Accessibility Testing Tools: The Tab Key” by Manuel Matuzović — A reminder that sometimes the simplest tools reveal the most about keyboard navigation.
- Designer-oriented standards overviews — Yichen He has written two solid primers: one for The Next Web and a more detailed version for UX Collective, both covering the web accessibility standards designers should know.
- “What A Year Of Learning And Teaching Accessibility Taught Me” by Sara Soueidan for 24 Accessibility — A candid reflection on the learning curve and the lessons that stick.
The insights shared by Brian Moore, Damien Senger, Jim Kiely, Justin Yarbrough, Kenny Hitt, and Soren Hamby also underscore that accessibility is shaped by real people with real experiences — listening to them is part of the process.
Every small step you take to remove a barrier compounds. You do not need to overhaul everything at once; you just need to make today’s version of your product a little more inclusive than yesterday’s. That steady, deliberate progress is what turns accessibility from a checklist into a lasting practice.
