Web Accessibility: Building For Every User

It is tempting to treat accessibility as a design nicety, something a QA pass adds at the end. In practice it is closer to type-safety or security: a property that has to be designed in from the first line of markup, because retrofitting it is exponentially more expensive.

The World Health Organization estimates that over a billion people, roughly 16% of the global population, experience some form of significant disability. That includes permanent conditions like blindness or motor impairment, but also temporary and situational ones — a broken arm, a bright sunlit screen, a noisy train platform where audio is unusable. Accessible markup benefits all of these cases simultaneously, because it is built on the same principle: don't assume a single way of consuming content.

Legally, many jurisdictions now mandate accessibility (ADA in the US, EN 301 549 in the EU) for public-facing and government-adjacent software, making this a compliance requirement as much as an ethical one.

The Web Content Accessibility Guidelines (WCAG) organize every success criterion under four umbrella principles, abbreviated POUR.

Perceivable — information must be presentable in ways every user can perceive: text alternatives for images, captions for video, sufficient color contrast. Operable — all functionality must be reachable via keyboard alone, with no time limits that can't be extended, and no content that flashes in a way that triggers seizures. Understandable — text must be readable, interfaces must behave predictably, and forms must help users avoid and correct mistakes. Robust — content must be interpretable by a wide range of user agents, including current and future assistive technologies, which is why valid, semantic HTML matters so much.

Every lesson in this module maps back to one or more of these four pillars.

Every modern browser builds two parallel trees from your HTML: the DOM, used for rendering and scripting, and the accessibility tree, used to communicate with assistive technology through OS-level APIs (like UIA on Windows or AX on macOS).

Each node in the accessibility tree carries a role (button, heading, navigation), an accessible name (usually derived from text content, aria-label, or an associated <label>), and a state (checked, expanded, disabled). Native HTML elements populate all three automatically. Generic elements like <div> and <span> populate none of them unless you add ARIA attributes manually.

This is why the guiding rule of accessible development is: prefer a native element with built-in semantics over a generic element with ARIA bolted on. Native elements are tested across every browser and assistive technology combination that exists; hand-rolled ARIA is not.

Accessibility Is Not Optional. Roughly one in six people worldwide lives with some form of disability. Accessibility (shortened A11Y, for the 11 letters between 'A' and 'Y') is the practice of building interfaces that this entire population can perceive, operate, and understand — using the browser's native semantics as the foundation.

Accessibility Is An Engineering Requirement. Accessibility is not a visual theme you bolt on at the end. It is a structural property of your HTML, exactly like performance or security. A div-soup interface styled to look like a button is invisible to a screen reader, no matter how good it looks visually.

Structural Accessibility. A <div> styled with CSS to look exactly like a button is clicked with a mouse just fine. Why does it still fail an accessibility audit?

• →It fails because the color contrast is wrong
• →It fails because it carries no keyboard or screen-reader semantics
• →It doesn't fail; visual matching is sufficient

The Four POUR Principles. Every accessibility guideline traces back to four principles known as POUR: Perceivable, Operable, Understandable, and Robust. Content must be perceivable through more than one sense, operable without a mouse, understandable in its language and behavior, and robust enough to work with assistive technology.

POUR Principles. Which one of these is NOT one of the four WCAG POUR principles?

• →Performant
• →Operable
• →Robust

Assistive Technology Reads The DOM, Not The Screen. Screen readers, switch devices, and braille displays never see your pixels. They query the accessibility tree, a parallel structure the browser builds from your DOM. If an interactive control has no name, no role, or no state in that tree, it effectively does not exist for those users.

The Accessibility Tree. A screen reader user navigates your page. What structure is it actually querying to know what's on screen?

• →The rendered pixel buffer, like a screenshot
• →The accessibility tree derived from the DOM
• →The compiled CSSOM stylesheet rules

Foundation Secured. You now understand accessibility as a structural engineering discipline governed by the POUR principles, and why assistive technology depends entirely on the accessibility tree generated from your HTML. Every lesson in this module builds directly on this foundation.

Add The Core Landmarks. Semantic landmarks like <nav> and <main> let assistive tech users jump straight to key regions.