Accessible Future

Web accessibility (often abbreviated as A11y) means that websites, tools, and technologies are designed and developed so that people with disabilities can use them. Specifically, people can perceive, understand, navigate, and interact with the Web, and they can contribute to the Web.

WCAG stands for Web Content Accessibility Guidelines. It is a set of guidelines for making web content more accessible, primarily for people with disabilities, but also for all user agents, including highly limited devices, such as mobile phones.

POUR stands for: 1. Perceivable (users must be able to perceive the info), 2. Operable (users must be able to operate the interface), 3. Understandable (info and operation must be understandable), 4. Robust (content must be robust enough to be interpreted by a wide variety of user agents).

Level A is the minimum level of accessibility (basic features). Level AA is the mid-range and the most commonly used standard for most websites (e.g., for legal compliance). Level AAA is the highest and most stringent level of accessibility, often required for specialized sites catering specifically to people with disabilities.

Section 508 is a US federal law that requires federal agencies to make their electronic and information technology accessible to people with disabilities. It is often aligned with WCAG 2.0/2.1 AA standards.

The EAA is a European directive that sets common accessibility requirements for certain key products and services in the EU market, including websites and mobile apps of private companies like banks and e-commerce.

WCAG 2.2 builds on 2.1 by adding new success criteria, primarily focused on users with cognitive or learning disabilities, users with low vision on mobile devices, and users with disabilities on touch devices (e.g., focus appearance, dragging movements).

Every non-decorative image must have a concise alt attribute that describes its content or function. Decorative images should have an empty alt attribute (alt="") so they are ignored by screen readers.

The accessibility tree is a specialized version of the DOM tree that browsers create for assistive technologies. It filters out non-essential info and formats the rest in a way that screen readers can understand (Name, Role, State, Value).

For WCAG AA, normal text should have a contrast ratio of at least 4.5:1 against its background. Large text (18pt or 14pt bold) should have at least 3:1. AAA requires 7:1 for normal text.

It ensures that the reading order (the order in which content is presented in the DOM) matches the logical meaning of the content, which is critical for screen reader users and users with cognitive disabilities.

If a webpage can be navigated sequentially, the focusable components must receive focus in an order that preserves meaning and operability. Usually, this means following the DOM order.

Requires that all non-text content (images, videos, audio) has a text alternative that serves the equivalent purpose.

A link at the very beginning of the page (often hidden until focused) that allows keyboard users to bypass repetitive navigation and go straight to the main content area.

The WCAG requirement (2.4.1) that provides a mechanism to bypass blocks of content that are repeated on multiple Web pages (like navbars).

Criterion 1.3.1 requires that information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text (e.g., using proper <h1>-<h6> tags, <caption> for tables, <label> for inputs).

Content should not rely solely on sensory characteristics like shape, color, size, or sound to convey instructions (e.g., don't say 'Click the big red button' to find the submit).

Color should not be the *only* visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element (e.g., use an icon or text alongside red for error states).

If any audio on a Web page plays automatically for more than 3 seconds, a mechanism must be available to pause or stop the audio, or to control the volume independently from the system.

Captions are provided for all prerecorded audio content in synchronized media (like videos), except when the media is a media alternative for text.

An additional narration track for people who are blind or low-vision, describing important visual details that aren't conveyed in the main dialogue (e.g., character movements, facial expressions).

All functionality of the content must be operable through a keyboard interface without requiring specific timings for individual keystrokes.

If focus can be moved to a component of the page using a keyboard interface, then focus must also be able to be moved away from that component using only a keyboard interface.

For any time limit set by the content (like session timeouts), the user must be able to turn off, adjust, or extend the limit before it expires.

For moving, blinking, scrolling, or auto-updating information (like carousels or stock tickers), the user must be given a mechanism to pause, stop, or hide it.

Web pages do not contain anything that flashes more than three times in any one-second period, as this can trigger seizures in people with photosensitive epilepsy.

Web pages must have titles that describe topic or purpose. This is the first thing a screen reader announces when a page loads.

The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context (avoid generic 'click here').

More than one way is available to locate a Web page within a set of Web pages, except where the Web Page is the result of, or a step in, a process (e.g., search + site map + nav menu).

Headings (<h1>-<h6>) and labels properly describe their topic or purpose.

Any keyboard-operable user interface must have a mode of operation where the keyboard focus indicator is visible. Never use 'outline: none' without providing a custom focus style.

The default human language of each Web page can be programmatically determined (using the lang attribute on the <html> tag).

If a specific block of text is in a different language than the rest of the page, it should have its own lang attribute so screen readers use the correct pronunciation.

When any component receives focus, it does not result in a change of context (like automatically submitting a form or opening a new window).

Changing the setting of any user interface component (like checking a box or selecting from a dropdown) does not automatically cause a change of context unless the user has been advised before use.

Navigational mechanisms that are repeated on multiple Web pages within a set of Web pages occur in the same relative order each time they are repeated.

If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text.

If an input error is detected and suggestions for correction are known, then the suggestions are provided to the user, unless it would jeopardize security.

In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique (this was deprecated in WCAG 2.2 as browsers handle this well now).

The core requirement for custom UI components. For all UI components, the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically determined.

Semantic HTML provides built-in accessibility. It automatically gives elements the correct roles, states, and keyboard behaviors in the accessibility tree, which non-semantic <div> and <span> tags do not.

Represents the dominant content of the <body>. There should only be one non-hidden <main> per document. It is a landmark region for screen readers.

Represents a section of a page that links to other pages or to parts within the page; a section with navigation links.

Represents introductory content, typically a group of introductory or navigational aids. It may contain some heading elements but also a logo, a search form, an author name, etc.

Represents a footer for its nearest sectioning content. A footer typically contains information about the author, copyright data or links to related documents.

<article> is for self-contained content that could be distributed independently (like a blog post). <section> is for a thematic grouping of content, typically with a heading.

Represents a portion of a document whose content is only indirectly related to the document's main content (like sidebars or pull quotes).

Headings should reflect the structure of the document, not the visual size. Don't skip levels (e.g., from H1 to H3). There should typically be only one H1 per page.

Use <button> for actions that happen on the current page (e.g., opening a modal, submitting a form). Use <a> for navigation that changes the URL or location on the page.

Provides a label for a form control. It's bridged to the input via the 'for' attribute (matching the input's 'id'). Clicking the label also focuses the input.

<fieldset> is used to group related elements in a form (like a group of radio buttons). <legend> provides a caption for the group, which is announced by screen readers for each item in the group.

Used with <table> to provide a title or description for the data. Recommended for accessibility to give context to the table's content.

Table Header cell. Use 'scope="col"' or 'scope="row"' to explicitly define what the header applies to.

Used to provide contact information for the nearest <article> or the entire <body>. Not for random postal addresses.

<figure> is for self-contained content (image/code/diagram). <figcaption> is the description. In A11y, it's safer and more powerful than just alt text for complex diagrams.

<cite> is for the title of a work. <q> is for short inline quotations. They help provide semantic meaning to quoted content.

It programmatically links a label to an input. Without this, screen readers might not announce the label when the input is focused.

Represents a specific period in time. Use the datetime attribute to provide a machine-readable format.

<time datetime="2026-03-13">March 13th</time>

Screen readers announce the list type and the number of items. This helps users understand the scope of the list before navigating individual items.

Indicates text that is marked or highlighted for reference or notation purposes. Important for indicating search result matches semantically.

Indicates the defining instance of a term. Useful for making explanations more discoverable.

Used for abbreviations or acronyms. Use the title attribute to provide the full expansion for assistive technology.

Both hide the element from view and the accessibility tree. 'visibility: hidden' hides it but keeps the space. aria-hidden="true" only hides it from the accessibility tree (screen readers).

Native HTML way to create collapsibles. Screen readers handle the expanded/collapsed state automatically without custom JS/ARIA.

Native modal/dialogue box. It handles focus trapping and aria-modal behavior automatically when opened with showModal().

It breaks the natural tab order of the page, leading to a confusing and frustrating experience for keyboard users. Use only 0 (focusable) or -1 (programmatically focusable).

aria-label takes a string. aria-labelledby take an ID of another element that acts as the label. Labelledby is usually preferred as it's easier to translate/maintain.

Links an element to another that provides more detailed information (like hint text or error messages) that isn't the primary label.

Use aria-hidden="true". Useful for decorative icons or redundant text.

Use a specialized CSS utility (often called .sr-only or .visually-hidden) that positions it off-screen but keeps it accessible to AT.

.sr-only {
  position: absolute;
  width: 1px;
  height: 1px;
  padding: 0;
  margin: -1px;
  overflow: hidden;
  clip: rect(0, 0, 0, 0);
  white-space: nowrap;
  border-width: 0;
}

<progress> is for task completion (loading). <meter> is for a scalar measurement within a known range (like disk space or fuel).

Description list, term, and description. Semantically superior to <div> for key-value pairs or glossary entries.

Use <th scope="col"> for column headers and <th scope="row"> for row headers. Without this, complex tables become unintelligible to screen readers.

aria-hidden="true" on a parent hides all children from AT. Useful for modals to prevent users from 'leaving' the modal while it's open.

Placeholders are NOT a replacement for labels. They disappear when the user types, and many screen readers don't announce them reliably. Always use a <label>.

Helps users with cognitive or motor disabilities to quickly fill out forms. It also allows browsers to provide specialized input methods (like address/credit card pickers).

Hints to the browser which keyboard to show (numeric, tel, email) on mobile devices, easing the interaction for those with motor impairments.

Used to group a main <h1>-<h6> and secondary introductory text, ensuring they are treated as a single heading unit.

If the button has no text, you MUST use aria-label or a .sr-only span inside the button to give it a name.

<button aria-label="Close">
  <i class="bi bi-x" aria-hidden="true"></i>
</button>

For image maps, each <area> must have an alt attribute describing where that specific link leads.

WAI-ARIA (Web Accessibility Initiative – Accessible Rich Internet Applications) is a specification from the W3C that provides attributes to help bridge gaps in semantic HTML, especially for dynamic content and complex UI components.

If a native HTML element or attribute has the semantics and behavior you require already built-in, use that instead of adding an ARIA role, state or property.

A role defines the type of element it is. Roles like 'button', 'alert', 'tabpanel', 'navigation' tell the screen reader how to interpret and interact with the element.

States (like aria-expanded, aria-checked) change with user interaction. Properties (like aria-required, aria-labelledby) are usually static and define relationships or requirements.

These roles remove the semantic meaning of an element from the accessibility tree (though its children remain). Used to fix legacy code or for decorative table layouts.

Indicates that an element will be updated, and describes the types of updates the user agent, assistive technologies, and user can expect. Values: polite (waits for pause), assertive (interrupts), off (default).

Both are live regions. 'status' is polite and used for non-essential updates. 'alert' is assertive and should be used for critical info requiring immediate attention.

Tells the screen reader that the content outside of this element should be ignored. It's a key part of making custom modals accessible.

Indicates whether a collapsible element (like a menu or accordion) is currently open (true) or closed (false). You must update this via JS during interaction.

Indicates the current item within a set. Common values: 'page' (current link in nav), 'step' (current step in progress), 'date' (current day in calendar).

Indicates that the element has a popup (menu, listbox, tree, grid, or dialog) associated with it.

Identifies the element (or elements) whose contents or appearance are controlled by the current element. Mostly used for tabs to link a tab button to its panel.

Indicates that the entered value does not conform to the expected format. Usually used in tandem with aria-describedby pointing to an error message.

Indicates that user input is required on the element before a form may be submitted. AT will announce 'Required' to the user.

Used for 'toggle' buttons (like a Play/Pause button or a Like button) to indicate whether the button is currently in a pressed state.

Indicates an element is being modified and that assistive technologies may want to wait until the modifications are complete before informing the user about updates.

Landmarks (banner, navigation, main, complement, search, contentinfo) allow users to jump quickly to different sections of the page using skip keys.

Selected is usually for tabs or listbox items. Checked is specifically for checkboxes and radio buttons.

Indicates whether the element's orientation is horizontal, vertical, or unknown/ambiguous.

Used with aria-live to specify what types of changes should trigger an announcement (removals, additions, text changes).

Default is false. If true, the entire live region is announced when any part changes. If false, only the changed part is announced.

CAUTION: This role tells the screen reader to turn off its default shortcut keys and pass all input strictly to the web app. Use very sparingly for things like Google Docs or highly complex WebGL apps.

Defines a parent-child relationship between elements that are not children of each other in the DOM tree.

Used when only a partial set of items is loaded in the DOM (like virtual scrolling). It tells the AT 'this is item 5 of 100'.

Used for sliders (role="slider") or progress bars to communicate the current, minimum, and maximum numerical values.

Used on table headers to indicate if the column is sorted in ascending or descending order.

Type of live region for sequential info where new information is added to the end (e.g., a chat window history).

Numerical counter that indicates the amount of elapsed time from a starting point, or the time remaining until an end point.

A contextual popup that contains a descriptive text which provides information about an element. It should be linked to the trigger via aria-describedby.

Self-explanatory properties for text inputs and list components to communicate their capability.

Indicates whether inputting text could trigger display of one or more predictions of the user's intended value for an input.

A collection of commonly used functions represented as compact buttons; usually requires arrow key navigation between buttons for best UX.

Specialized type of textbox used for entering search criteria. Allows AT to provide specialized search shortcuts.

A type of checkbox that represents an 'on' or 'off' state. Visually usually looks like a toggle switch.

Used in listboxes/comboboxes to manage focus virtually. Instead of moving focus to each item, focus stays on the container, which points to the 'active' child ID.

Table is for static data. Grid is for interactive data where the user needs complex keyboard navigation between cells (Excel-like behavior).

The standard trio for tabbed interfaces. Tab is the button, tabpanel is the content, and tablist is the wrapper.

Similar to aria-describedby but specifically for error messages. It's newer and often used in conjunction with aria-invalid.

Used in complex grids with virtual scrolling to maintain the correct table coordinates in the AT.

Use automated tools like Axe-core, Lighthouse, or browser extensions like WAVE. But ultimately, verify with a real screen reader like NVDA or VoiceOver.

Keyboard accessibility means ensuring that all interactive elements can be accessed and operated entirely using a keyboard, without requiring a mouse or other pointing device.

The primary way to move between focusable elements like links, buttons, and form inputs.

Moves the focus backwards through the focusable elements.

A technique used for components like modals and menus where the focus is constrained within the component until it is closed, preventing the user from tabbing to background content.

1. Save the reference to the last focused element. 2. Move focus into the modal (title or first button). 3. Trap focus inside. 4. Restore focus back to the trigger button when the modal closes.

Since page loads don't refresh the browser in SPAs, you must manually move focus to the new content (usually the H1 or a skip link) to inform screen reader users that the view has changed.

Remove the default outline with caution, and ALWAYS replace it with a high-contrast equivalent (using border, background-color, or box-shadow).

button:focus {
  outline: 3px solid #ffcc00;
  outline-offset: 2px;
}

It only applies a focus style when the browser determines that the focus was initiated by a keyboard or other assistive device, preventing 'unnecessary' outlines when clicking with a mouse.

A native HTML attribute that makes a section of the page completely non-interactive and hidden from AT. Very useful for hiding main content while a modal is open.

Both usually activate buttons. For links, only Enter is expected. For checkboxes/radios, Space is the standard toggle key.

The Escape key should close any overlays, modals, or menus that are currently open.

A technique for complex widgets (like radio groups or toolbars) where only one item has tabindex="0" and the rest have "-1". Arrow keys are used to move the 0-index between items.

Handle Up/Down arrow to cycle items, Enter/Space to select, Escape to close, and maybe character keys for 'jump to letter' functionality.

The path focus takes as a user moves through an interaction. It must be logical and predictable (e.g., if I delete an item, focus should go to the next logical item, not the top of the page).

Provide a 'Load More' button instead of auto-scrolling, or use live regions to announce new content. Ensure users can still reach the footer.

WCAG 2.1 requires a minimum of 44x44 CSS pixels for interactive targets. WCAG 2.2 reduced this to 24x24 in some contexts but with stricter spacing rules.

Provide keyboard-only alternatives (e.g., using 'Move Up' / 'Move Down' buttons) and use aria-live to announce status changes.

Ensuring that animations can be disabled or significantly reduced for users with vestibular disorders. Use the 'prefers-reduced-motion' media query.

@media (prefers-reduced-motion: reduce) {
  * {
    animation-duration: 0.01ms !important;
    transition-duration: 0.01ms !important;
  }
}

Functionality that can be operated by complex gestures (pinch-to-zoom, swipe) must also be operable by a single pointer without path-based movement (e.g., simple click buttons).

For components with a visible text label, the accessible name must contain the visible text label. This helps users of voice input software who 'say what they see'.

Content revealed on hover must be: 1. Dismissible (via Esc), 2. Hoverable (user can move mouse over the new content), 3. Persistent (doesn't disappear until user wants).

Designing interactions that don't assume the user has a specific input device (like a mouse, touch screen, or stylus).

Don't lock the UI to only work in Portrait or Landscape mode. Users with devices mounted on wheelchairs may not be able to rotate them.

Allowing users to use standard input methods (like biometric login or password managers) rather than forcing custom, inaccessible flows.

Ensure enough gap between buttons so users with motor impairments don't accidentally click the wrong one.

Complementary to 'Focus Visible', ensuring that the focus outline is not only present but has a high enough contrast to be seen by low-vision users.

When content is inserted dynamicall (like an alert or new list item), consider moving focus to it if it requires immediate action.

Unplugging your mouse and trying to complete all tasks on your site using only Tab, Shift+Tab, Enter, Space, and Arrows.

Requirement 1.4.13 ensures that users won't accidentally trigger content that blocks other content and that they can easily dismiss it.

The order in which focus moves through the page; it should prioritize header -> nav -> main -> footer in a logical flow.

The engine that powers most accessibility testing tools. It's an automated library that catches about 30-50% of accessibility issues by running against the DOM.

A tool built into Chrome DevTools that provides a score (0-100) based on automated A11y checks.

Automated tests generally catch about 30% to 50% of accessibility errors. Manual testing with screen readers and keyboard remains essential for full compliance.

NonVisual Desktop Access. A free, open-source screen reader for Windows. Very popular and excellent for developer testing.

The built-in screen reader for Apple devices (macOS, iOS). It's the industry standard for mobile A11y testing.

Job Access With Speech. One of the oldest and most powerful commercial screen readers for Windows, primarily used in professional settings.

A suite of evaluation tools that helps authors make their web content more accessible by providing visual overlays of errors and landmarks.

Allows you to view the calculated Accessibility Tree for any element, its computed ARIA name, role, and source of its accessible name.

When you inspect an element's text color, DevTools shows you the contrast ratio and whether it passes WCAG AA or AAA.

A DevTools feature (Rendering tab) that allows you to see the page as someone with color blindness or blurred vision would see it.

Enable 'High Contrast' in Windows settings and verify that all content, especially icons and focus states, remain visible and clearly distinguished.

An integration for the Cypress test runner that injects the Axe engine into your E2E tests to catch accessibility regressions in CI.

A command-line tool that lets you run semi-automated accessibility audits on your site. Great for quick checks or automated pipelines.

A document that explains how a product meets or doesn't meet specific accessibility criteria. Often required for government contracts.

Using tools like eslint-plugin-jsx-a11y to flag accessibility issues in your code (like missing alt tags) before you even run the app.

Navigate the page without looking at the screen (or using a screen curtain) to ensure you can understand the layout, navigate sections, and complete all actions.

A manual evaluation technique where an expert reviews the interface against a list of recognized principles (heuristics) like WCAG guidelines.

Use Dragon NaturallySpeaking or Built-in Voice Control to see if you can trigger all actions by saying the labels.

Ensuring that bug fixes or new features don't break existing accessibility compliance.

WCAG requires that content should be operable and no functionality is lost when zoomed up to 400%. Ensure no horizontal scrolling appears and content doesn't overlap.

Firefox DevTools includes an excellent Accessibility panel that highlights issues and visualizes landmarks very clearly.

A professional-grade Chrome extension that provides detailed audits, including aria-live tracking and complex component analysis.

The gold standard of A11y testing. Recruit actual assistive technology users to find real-world usability barriers that automated tests miss.

The formal report generated after a full audit, detailing how well a site adheres to standards like WCAG 2.1 AA.

A set of free tools (web/android/windows) that guides you through a semi-automated and manual assessment of your site.

Learn the primary keys: 'H' for headings, 'L' for lists, 'T' for tables, and 'F' for form fields to quickly navigate sections during testing.

Look for 'aria-labelledby' or 'aria-describedby' pointing to IDs that don't exist, which AT will simply ignore.

Using clamp() or rem units ensures that text scales correctly with the user's browser font size settings.

Disable all CSS to see if the DOM order remains logical and understandable. This is the raw sequence a screen reader user experiences.

Verify that custom play/pause/volume buttons are keyboard focusable and provide proper ARIA labels for their current state.

The complex algorithm AT uses to determine the text for an element (Inner text > aria-label > aria-labelledby > title > alt).

Captchas are inherently inaccessible (visual checks vs bots). Always provide an audio alternative or use modern 'no-captcha' solutions like Cloudflare Turnstile.

Ensure they don't have titles that produce redundant tooltips, and they have proper aria-hidden or labels depending on purpose.

An addon that runs Axe-core on every story, allowing developers to catch A11y errors at the component level during development.

A 100 on Lighthouse doesn't mean your site is accessible; it just means it passed the automated checks. True compliance requires manual verification.

Open the modal, close it via button and Esc key, and ensure the focus returns exactly where it started. Use 'document.activeElement' in console to verify.

A tool or extension that draws arrows on the screen to show how focus moves from element to element.

The definitive guide from W3C on how to build common UI patterns (tabs, accordions) with the correct ARIA/Keyboard behaviors.

Verify that new content (like a search result count update) is announced automatically without the user having to move focus to it.

Test early, test often, and always think about the user behind the assistive technology.