Web Accessibility (a11y)

Definition: Designing and building products usable by people with disabilities, including visual, auditory, motor, and cognitive impairments, guided by the WCAG (Web Content Accessibility Guidelines) standard.

How It Works

Semantic HTML (<button>, <nav>, <h1>, <label>) gives assistive technology the structure it needs to interpret a page correctly, without semantic elements, a screen reader has no reliable way to know what anything is
The browser builds an “accessibility tree” from the DOM, a parallel structure exposing each element’s role, name, and state to assistive technology, this is what a screen reader actually reads, not the visual page
Captions and transcripts make audio and video content perceivable for deaf and hard-of-hearing users, and are also what makes that content searchable and usable without sound at all
Sufficient color contrast, resizable text, and full keyboard-only navigation cover a large share of common accessibility needs without any specialized markup
ARIA (Accessible Rich Internet Applications) attributes fill gaps when semantic HTML alone can’t describe a complex interactive widget, like a custom dropdown or a tab panel
WCAG defines success criteria across four principles, commonly remembered as POUR: Perceivable, Operable, Understandable, Robust
WCAG conformance comes in three levels, A (minimum), AA (the level most legal standards require), and AAA (the strictest, rarely required in full for an entire site)
Keyboard focus order and visible focus indicators let users who can’t use a mouse navigate and know exactly where they are on the page
Motion and animation settings should respect prefers-reduced-motion, since some vestibular disorders can be triggered by large, uncontrollable on-screen motion
Automated tools (axe, Lighthouse, WAVE) catch a meaningful subset of issues, roughly a third to a half of WCAG success criteria, the rest require manual testing with a keyboard and a screen reader
Screen readers (VoiceOver, NVDA, JAWS) are the most commonly tested assistive technology, but switch access, screen magnification, and voice control all rely on the same underlying accessibility tree
Form fields need programmatically associated labels (<label for="email">), a placeholder alone disappears once text is typed and isn’t reliably announced by every screen reader

The Four POUR Principles

Principle	Meaning	Example requirement
Perceivable	Content must be presentable in ways users can perceive	Alt text for images, captions for video
Operable	Interface components must be operable	Full keyboard access, no seizure-inducing flashing
Understandable	Content and operation must be understandable	Clear error messages, consistent navigation
Robust	Content must work with a wide range of assistive tech	Valid semantic markup, correct ARIA usage

Under the Hood

The accessibility tree is the real mechanism, not a metaphor. A <div onclick="..."> styled to look exactly like a button produces no entry in that tree with a “button” role, so a screen reader announces nothing meaningful, maybe just “clickable” or nothing at all, regardless of how visually convincing the fake button is. A real <button> element gets a “button” role, its text content as its accessible name, and keyboard operability (Enter and Space trigger it) automatically, for free, from the browser.

ARIA only changes what’s announced, it does not add any actual behavior. Adding role="button" to a <div> makes a screen reader announce “button,” but the div still isn’t focusable or keyboard-operable unless tabindex="0" and a keydown handler are added manually. This is the source of the widely repeated accessibility guidance: “No ARIA is better than bad ARIA,” because bad ARIA can make an element sound accessible while it’s functionally still broken for keyboard and screen reader users.

Focus order follows DOM order by default, which is why visually reordering elements with CSS alone, without also reordering the underlying markup, can produce a confusing focus order: a sighted keyboard user sees focus jump somewhere unexpected because the visual layout and the document’s actual structure no longer match.

Worked Example 1

Given: A button is built as <div class="btn" onclick="submit()">Submit</div> instead of a real <button>.
Step: A screen reader user tabs through the page and the div is skipped entirely, it’s not in the keyboard tab order and carries no accessible role.
Answer: The user never discovers the submit action exists; replacing the div with <button>Submit</button> fixes keyboard access and screen reader announcement simultaneously, with zero extra code.

Worked Example 2

Given: A custom dropdown widget is built from styled <div> elements with no semantic markup.
Step: role="listbox" and role="option" are added to the container and its items, aria-expanded tracks whether the dropdown is open, and JavaScript adds arrow-key and Enter-key handling manually.
Answer: A screen reader now announces “listbox, collapsed” and, once opened, reads each option correctly, matching the behavior of a native <select> that would have needed none of this extra work.

Worked Example 3

Given: Text on a page is styled as light gray (#AAAAAA) on a white background, a 2.3:1 contrast ratio.
Step: WCAG AA requires at least 4.5:1 for normal-size text; the color fails an automated contrast check.
Answer: Darkening the text to #595959 (a 7:1 ratio) passes AA and meets AAA, fixing the issue for low-vision users without changing the visual design’s intent.

Worked Example 4

Given: A product image has alt="image123.jpg" instead of a description, a common result of an auto-generated filename left unedited.
Step: A screen reader user shopping the page hears the filename read aloud instead of any useful description of the product shown.
Answer: Changing the attribute to alt="Red leather ankle boot, side view" gives the same information a sighted user gets from glancing at the photo.

Why It Matters

A meaningful share of any user base has some disability, and inaccessible products carry real legal risk in many countries, lawsuits under laws like the ADA in the US have increased significantly
Accessible patterns tend to benefit everyone, captions help in a loud environment, keyboard shortcuts help power users, high contrast helps outdoor mobile use in bright sunlight
Semantic, accessible markup is also what search engines and other automated tools parse most reliably, accessibility and SEO overlap substantially
Voice assistants, browser reader modes, and translation tools all depend on the same clean semantic structure that assistive technology needs, accessibility work pays off across more surfaces than screen readers alone
Retrofitting accessibility after launch costs far more than building it in from the start, structural issues (a whole component built without semantic markup) often require a rebuild, not a patch
Expands the addressable market, an inaccessible checkout flow actively loses sales from users who simply cannot complete it
Reduces legal exposure proactively rather than reactively, fixing issues before a demand letter arrives is cheaper than fixing them under litigation pressure
Public sector and many enterprise vendors require WCAG AA conformance contractually, an inaccessible product can be disqualified from government and enterprise procurement entirely
Signals product quality and craftsmanship broadly, teams that get accessibility details right tend to get other implementation details right too
Aging users, a growing share of the population, increasingly rely on the same accommodations, larger text, higher contrast, simpler navigation, originally built for permanent disabilities
Situational impairments matter too, a bright-sunlight glare or a broken arm temporarily creates the same access needs a permanent disability would
Automated and manual accessibility testing together catch far more than either alone, treating them as complementary rather than redundant closes real coverage gaps

Common Pitfalls

Relying only on color to convey meaning, like red/green for error/success, which fails entirely for colorblind users
Bolting on accessibility at the end of a project instead of building it in from the start, semantic structure is far harder to retrofit than to build correctly the first time
Adding ARIA roles without adding the matching keyboard behavior, producing an element that sounds accessible but isn’t actually operable
Trusting an automated scanner’s clean report as proof the page is accessible, automated tools only catch a subset of issues, manual keyboard and screen reader testing is still required
Using a placeholder as a form field’s only label, leaving no persistent, associated name once the user starts typing
Hiding content visually with display: none when it should remain in the accessibility tree, or the reverse, leaving decorative content exposed to screen readers when it should be hidden
Removing focus outlines with outline: none for aesthetic reasons without providing any visible replacement, leaving keyboard users with no way to see where they are
Writing alt text that describes an image’s filename or generic content instead of its actual informational purpose on the page
Building a modal dialog that doesn’t trap keyboard focus inside it, letting a keyboard user tab out into the page hidden behind the overlay
Assuming accessibility is only a legal or engineering concern, without involving actual disabled users in testing at any point

Comparison

	WCAG Level A	WCAG Level AA	WCAG Level AAA
Strictness	Minimum, baseline	Mid-tier	Strictest
Legal standard in most jurisdictions	Rarely sufficient alone	Yes, most common legal requirement	Rarely mandated site-wide
Contrast ratio (normal text)	Not specified	4.5:1	7:1
Practical target for most products	Too low	Industry default	Specific pages/features only
Contrast ratio (large text, 18pt+)	Not specified	3:1	4.5:1
Example requirement	Alt text present	Contrast, resizable text, keyboard access	Sign language for video, extended audio descriptions

Example

A screen reader announces a button’s purpose correctly because it’s a real <button> element with clear text, instead of a <div> with a click handler and no semantic meaning, one of the single most common and most consequential accessibility fixes in real codebases.

The UK government’s GOV.UK design system publishes its accessibility approach openly and is frequently cited as a reference implementation: semantic-first markup, WCAG AA as the enforced baseline, and accessibility audits built into its component review process rather than treated as a final QA pass.

Apple, Google, and Microsoft each publish their own platform accessibility APIs (UIAccessibility, Android Accessibility, UI Automation) that browsers translate the web accessibility tree into, which is why the same well-marked-up web page works correctly with VoiceOver on iOS, TalkBack on Android, and Narrator on Windows without any platform-specific code.

Referenced by

Dig deeper

Spot an error in this note?