Web Accessibility Basics: WCAG, Screen Readers, and Inclusive Design

Over 1 billion people worldwide live with some form of disability. An additional 15-20% of the population has situational or temporary impairments — a broken arm, bright sunlight on a screen, a loud environment, or simply aging eyes. Accessibility ensures your website works for all of these users.

Beyond ethics, there are concrete business reasons:

• Legal compliance — The EU European Accessibility Act (2025), US ADA lawsuits, and similar legislation worldwide make accessibility a legal requirement. Lawsuits against websites with poor accessibility have increased by 300% since 2018.
• SEO benefits — Accessible sites have better HTML semantics, proper heading structure, descriptive links, and alt text — all of which are SEO best practices.
• Larger audience — Accessible design doesn't just serve disabled users. Captions help people in noisy environments. Keyboard navigation helps power users. Good contrast helps everyone in bright light.
• Better code quality — Building for accessibility forces you to write semantic, well-structured HTML, which is easier to maintain and more performant.

The Web Content Accessibility Guidelines (WCAG) are the international standard for web accessibility. The current version is WCAG 2.2, organized around four principles (POUR):

• Perceivable — Users must be able to perceive the content. Provide text alternatives for images, captions for video, and sufficient color contrast.
• Operable — Users must be able to operate the interface. All functionality must work with a keyboard. Users must have enough time to read and interact with content.
• Understandable — Content must be readable and predictable. Navigation should be consistent. Error messages should be helpful.
• Robust — Content must work with current and future assistive technologies. Use valid, semantic HTML.

WCAG has three conformance levels:

• Level A — Minimum accessibility. Addresses the most critical barriers.
• Level AA — The standard most laws require and most organizations target. Covers contrast ratios, resize support, and consistent navigation.
• Level AAA — The highest level. Difficult to achieve for all content but worth targeting for specific features.

Screen readers convert web content to speech or Braille output. They're used by blind and low-vision users, but also by people with cognitive disabilities and learning differences. To work well with screen readers:

• Use semantic HTML — Use <nav>, <main>, <header>, <footer>, <article>, <aside>, and <section> landmarks. Screen readers let users jump between these landmarks. A page built entirely of <div>s is a wall of unlabeled content.
• Heading hierarchy — Screen reader users navigate by headings. Use a logical hierarchy (H1 → H2 → H3). Never skip levels (H1 → H3). Never use headings purely for visual styling.
• Descriptive link text — "Click here" and "Learn more" are meaningless out of context. Screen reader users often navigate by jumping between links. Each link should make sense on its own: "View pricing plans" not "Click here."
• Form labels — Every input must have an associated <label> element. Placeholder text is not a substitute for labels — it disappears on focus and isn't reliably read by screen readers.
• Dynamic content — When content changes dynamically (modals, alerts, live updates), use ARIA live regions (aria-live="polite" or aria-live="assertive") to announce changes to screen reader users.

Alt text describes images for screen reader users and displays when images fail to load. Good alt text is one of the simplest and highest-impact accessibility improvements:

• Be specific and concise — Describe what the image shows in 1-2 sentences. "Woman using a laptop at a coffee shop" not "Image" or "Photo."
• Convey the purpose — Why is this image on the page? A chart should describe the key data point. A product photo should describe the product. A decorative background doesn't need alt text (use alt="").
• Skip "image of" or "picture of" — Screen readers already announce it's an image. Starting alt text with "image of" is redundant.
• Decorative images — Use an empty alt="" attribute (not omitted entirely). This tells screen readers to skip the image. Omitting alt entirely causes screen readers to read the file name, which is worse.
• Complex images — Charts, infographics, and diagrams need detailed descriptions. Use alt text for a summary and provide a longer description in the surrounding text or via aria-describedby linking to a hidden description.

Many users navigate entirely by keyboard — people with motor disabilities, power users, and screen reader users. Every interactive element must be accessible without a mouse:

• Tab order — Pressing Tab should move focus through interactive elements in a logical order (typically left-to-right, top-to-bottom). The default tab order follows the DOM order, so structure your HTML logically. Avoid positive tabindex values (like tabindex="5") — they create confusing tab orders.
• Visible focus indicators — Users must see which element is currently focused. Never use outline: none without providing an alternative focus style. A 2-3px solid outline in your brand color works well. CSS: :focus-visible shows focus only for keyboard users, not mouse clicks.
• Custom components — If you build custom dropdowns, modals, tabs, or carousels with <div>s, you must add keyboard handling manually. Use native HTML elements (<button>, <select>, <input>) whenever possible — they have built-in keyboard support.
• Focus trapping in modals — When a modal is open, Tab should cycle only within the modal, not escape to the page behind it. Return focus to the triggering element when the modal closes.
• Skip navigation link — Add a "Skip to main content" link as the first element in your HTML (visible on focus) so keyboard users can bypass repeated navigation on every page.

ARIA (Accessible Rich Internet Applications) attributes add accessibility information to elements when semantic HTML alone isn't sufficient. The first rule of ARIA: don't use ARIA if native HTML can do the job. A <button> is always better than <div role="button">.

Essential ARIA attributes:

• role — Defines what an element is: role="navigation", role="dialog", role="alert", role="tab". Use when you can't use the equivalent HTML element.
• aria-label — Provides an accessible name when visible text isn't available. Use for icon-only buttons: <button aria-label="Close menu"><svg>...</svg></button>.
• aria-labelledby — Points to the ID of an element that labels this one. Useful for dialog titles: <div role="dialog" aria-labelledby="dialog-title">.
• aria-expanded — Indicates whether a collapsible element (dropdown, accordion) is expanded or collapsed. Toggle between true and false on interaction.
• aria-hidden="true" — Hides decorative elements from screen readers. Use for icons that duplicate text labels, decorative images, and visual-only elements.
• aria-live — Announces dynamic content changes. Use "polite" for non-urgent updates (new search results) and "assertive" for urgent alerts (error messages).

Incorrect ARIA is worse than no ARIA — it actively confuses assistive technology. Validate with screen reader testing, not just automated tools.