Web Accessibility Glossary

Numeronym for accessibility, representing the 11 letters between A and Y.

A systematic evaluation—manual and automated—of digital experiences against standards such as WCAG, ADA, AODA, or Section 508.

A formal document summarizing a product’s accessibility conformance, commonly based on a completed VPAT.

A public statement describing an organization’s commitment to digital accessibility, scope, known gaps, and contact path for assistance.

Methods to verify accessibility including automated scans, manual reviews, and user testing with assistive technologies.

Authentication flows that avoid cognitive function tests such as solving puzzles or memorizing passwords, and provide alternatives like copy/paste and password managers.

Supplemental help text associated with an element, often via aria-describedby, that provides additional guidance beyond the accessible name.

The computed name exposed to assistive technologies for an element, derived from label, aria-label, aria-labelledby, or text content.

A disclosure pattern made of headers that expand or collapse content. Must be keyboard operable with correct ARIA roles and states.

A visible caret or pointer state that helps users track input focus or text insertion position, essential for low-vision and cognitive accessibility.

U.S. civil rights law prohibiting discrimination based on disability. Covers public accommodations, employment, and digital accessibility.

Covers state and local government services, including websites and digital services provided by public entities.

Covers places of public accommodation and commercial facilities, increasingly applied to websites and mobile apps.

A neurodevelopmental condition affecting attention, hyperactivity, and impulse control. Interfaces benefit from clear focus management and minimal distractions.

Text alternative for images that conveys purpose or meaning when the image cannot be perceived. Decorative images should have empty alt ("").

Ontario, Canada legislation requiring accessibility compliance for organizations, including WCAG 2.0 Level AA for websites.

A language disorder affecting ability to communicate. Designs benefit from multiple communication modes and clear visual cues.

ARIA role indicating custom widgets that require specific keyboard interaction patterns, bypassing standard browser navigation.

A specification that defines roles, states, and properties to improve accessibility of complex UI when native semantics are insufficient.

An area of the page that notifies assistive technologies about dynamic updates. Use sparingly with polite or assertive announcements.

ARIA attribute that references elements providing additional description for an interactive element.

ARIA state indicating whether a collapsible element is currently expanded (true) or collapsed (false).

ARIA attribute that hides decorative content from assistive technologies while keeping it visually present.

ARIA attribute providing an accessible name when visible text is insufficient or unavailable.

ARIA attribute that references other elements to compose an accessible name.

ARIA attribute indicating dynamic content that should be announced by assistive technologies. Values: off, polite, assertive.

Software or hardware that helps people with disabilities use digital products, e.g., screen readers, magnifiers, switch devices, voice input.

Narration track that describes important visual details in video for blind or low-vision users; can be pre‑recorded or via extended description.

Neurodevelopmental condition affecting social communication and behavior. Benefits from predictable interfaces and sensory considerations.

Popular automated accessibility testing engine by Deque Systems, available as browser extension and programmatic API.

ARIA landmark role for site-oriented content, typically containing site title, logo, and main navigation.

A tactile writing system for blind or low-vision users, represented with raised dots and supported by refreshable braille displays.

A navigational aid that shows the page’s position in the hierarchy. Mark up with nav and aria-label="breadcrumb".

ARIA role for clickable elements that trigger actions. Prefer native <button> elements when possible.

Mechanisms such as skip links and landmarks that let users jump past repeated content directly to main sections.

Timed text for videos that transcribes speech and relevant sounds for people who are deaf or hard of hearing. Distinct from subtitles.

A rotating banner of content. Often problematic for accessibility: ensure keyboard control, visible focus, pause/stop, and proper semantics.

Motor disability affecting movement and posture. Benefits from generous target sizes and alternative input methods.

Single‑letter keyboard shortcuts that must be remappable, turned off, or only active on focus to prevent accidental activation.

ARIA role for dual-state controls. Support keyboard activation and clear checked/unchecked indication.

Captions that can be toggled on/off by the user, containing dialogue and meaningful sounds synchronized with the video.

Practices that improve comprehension and task completion for users with cognitive and learning disabilities, including plain language and consistency.

The mental effort required to process information or complete a task. Interfaces should minimize unnecessary complexity.

The contrast ratio between foreground and background colors. WCAG requires 4.5:1 for body text and 3:1 for large text, icons, and UI.

A range of conditions where certain colors are harder to distinguish. Designs must not rely on color alone to convey information.

Input widget combining text field with popup list. Requires complex ARIA states and keyboard navigation patterns.

ARIA landmark role for supporting content like sidebars, often containing related links or secondary information.

Ability of content to adapt without loss of information or functionality when zoomed up to 400% or on small screens.

ARIA landmark role for page footer content containing metadata, copyright, or secondary navigation.

Numeric ratio expressing luminance difference between two colors. Common thresholds: 4.5:1 for normal text, 3:1 for large text or UI.

U.S. law requiring accessibility for advanced communications and video programming, including mobile apps and video players.

Community and identity of deaf individuals with shared language (sign language), values, and communication preferences.

Combined hearing and vision loss requiring tactile communication methods and specialized assistive technologies.

A property of interfaces that can be used with a variety of inputs (keyboard, touch, voice, switch), not requiring a specific device.

An overlay that requires user interaction before returning to the main UI. Must trap focus, label the dialog, and provide accessible dismissal.

A pattern to show or hide additional content, typically via a button that toggles aria-expanded and controls a region.

Voice recognition software enabling hands-free computer control and dictation for users with motor disabilities.

A learning difference affecting reading and spelling. Designs benefit from clear typography, spacing, and predictable layouts.

European standard defining accessibility requirements for ICT products and services, closely aligned with WCAG.

WCAG requirement to clearly identify and describe input errors to users in text form.

Design patterns that reduce mistakes (confirmation, reversible actions, previews) required for important transactions by WCAG.

Clear, actionable guidance to fix mistakes, including inline error messages associated with inputs via aria-describedby.

EU legislation requiring accessibility for key products and services. Complements EN 301 549 requirements.

Detailed alternative content for complex images, charts, or diagrams, often provided via adjacent text or modal.

A visible outline or style that shows which element has keyboard focus. WCAG requires adequate contrast and size.

Strategies to set and maintain focus order during dynamic changes such as modals, route transitions, and component mounts.

Sequential navigation order when using Tab key. Should be logical and match visual reading flow.

Text associated with an input that communicates its purpose. Implement with <label for> or ARIA labelling.

ARIA landmark role for form regions. Use when form lacks a native form element or needs additional identification.

ARIA role for interactive tabular data where cells are focusable and may be editable, requiring 2D navigation.

ARIA role for individual cells within a grid, supporting focus and potentially editing capabilities.

In WCAG, a guideline groups related success criteria under the POUR principles and provides intent and techniques.

Partial hearing loss. May benefit from captions, visual alerts, and audio enhancement features.

ARIA role with aria-level attribute for custom headings when semantic HTML headings are insufficient.

Semantic structure using h1–h6 to convey document outline. Avoid skipping levels and use headings to label sections.

Operating system display mode that increases contrast. Respect system preferences and ensure custom styles remain legible.

Transient content that appears on hover or focus, which must be dismissible, hoverable, and persistent while being hovered.

Extended text that conveys complex visual content such as charts or infographics, linked from the image or adjacent text.

Text presented within an image instead of actual characters. Generally discouraged; use real text where possible.

Form helpers like labels, instructions, formatting hints, and auto-complete that help users enter information accurately.

Method of interaction (keyboard, mouse, touch, voice). Interfaces should support multiple modalities.

Condition affecting intellectual functioning and adaptive behavior. Benefits from simplified language and clear navigation.

A popular Windows screen reader (Job Access With Speech) widely used by blind and low-vision users.

The full name for JAWS screen reader, emphasizing its role in employment access for blind users.

Ensuring all interactive functionality is available through keyboard interface alone, without requiring mouse or touch.

The ability to operate all functionality using a keyboard alone. Requires logical tab order, focus styles, and skip links.

A defect where focus cannot be moved away using the keyboard. Users must be able to navigate away with standard keys.

Page sections identified by semantic elements or ARIA roles (main, navigation, complementary, banner, contentinfo) for quick navigation.

Conditions affecting information processing. Designs benefit from multiple presentation modes and clear structure.

Built-in Chrome DevTools accessibility testing powered by axe-core, providing automated accessibility scoring.

The destination or action of a link must be clear from its text or accessible name and its context.

ARIA role for navigation elements. Prefer native <a> elements with proper href attributes.

ARIA role for grouping related items, used with listitem role elements.

ARIA listitem role for individual items within list containers. Essential for screen reader navigation and semantic markup accessibility.

Dynamic content area that announces updates to assistive technologies without moving focus.

The sequence in which content is read by assistive tech and reached by focus should match the visual and semantic order.

Significant visual impairment not correctable by glasses. Benefits from magnification, high contrast, and large text.

Browser and OS zoom that enlarges content. Interfaces must remain usable and not block zoom.

ARIA landmark role for primary content area. Should be unique per page and contain the main topic.

Content order that preserves meaning and operability when styles change or linearized for assistive technologies.

ARIA role for application menus with specific keyboard navigation patterns (arrow keys, escape).

ARIA role for horizontal menu container, typically containing menu items or submenus.

ARIA menuitem role for individual options within menu widgets. Critical for keyboard navigation and assistive technology compatibility.

Sensitivity to motion or flashing content. Respect prefers-reduced-motion and avoid seizure-triggering flashes.

Physical impairment affecting movement, dexterity, or stamina. Benefits from keyboard access and generous target sizes.

Information that assistive technologies must be able to determine for interactive components to ensure operability.

ARIA landmark role for groups of navigation links to other pages or parts within the page.

Recognition that neurological differences like ADHD, autism, and dyslexia are natural variations requiring inclusive design.

NonVisual Desktop Access: a free Windows screen reader with broad usage among blind and low-vision users.

Controls should not require precise pointer targeting; provide generous hit areas and visible affordances.

ARIA role for selectable items within listbox, combobox, or similar selection widgets.

Content and functionality should not be restricted to one display orientation unless essential.

Command-line accessibility testing tool that can be integrated into development workflows and CI/CD pipelines.

One of the four WCAG POUR principles: information and UI components must be presented in ways users can perceive.

Automated accessibility testing within Playwright browser automation, often using axe-playwright integration.

Design that allows users to cancel or undo pointer actions to prevent accidental activation.

Actions like pinch, swipe, or drag. WCAG requires a single-pointer alternative that does not depend on complex gestures.

ARIA role that removes semantic meaning from elements, making them invisible to assistive technologies.

Form label associated to inputs via label for/id, aria-label, or aria-labelledby so assistive technologies announce purpose.

ARIA role for progress indicators, requiring aria-valuenow and optionally aria-valuemin/aria-valuemax.

Build for the simplest, most robust experience first, then layer advanced features so the core remains accessible.

Testing processes to verify accessibility requirements are met throughout the development lifecycle.

Alt text that is accurate, concise, and task-focused, describing purpose rather than appearance.

Screen reader feature to move by headings, landmarks, lists, and other structures using single-letter keys.

ARIA role for single-selectable options within a group. Use with radiogroup role container.

ARIA role for grouping related radio button options where only one can be selected.

Plain language, short sentences, and clear structure that improves comprehension for everyone, especially cognitive disabilities.

A user preference indicating they prefer limited motion. Use CSS media query prefers-reduced-motion to respect it.

Requirement that content supports 320 CSS px viewport width without loss of information or functionality and without horizontal scroll.

ARIA landmark role for significant page sections that users might want to navigate to. Requires accessible name.

Fourth WCAG POUR principle: content must work with various assistive technologies and remain functional as technologies advance.

ARIA attribute that defines an element’s type to assistive tech. Prefer native HTML roles before adding ARIA roles.

Assistive technology that enlarges content on screen, often with enhanced tracking and contrast features.

Assistive technology that converts on-screen text and semantics to speech or braille output.

ARIA search landmark role for search functionality regions within web pages. Helps screen readers locate and navigate search features.

U.S. federal law requiring accessibility for government ICT, updated in 2018 to incorporate WCAG 2.0 Level AA.

Using HTML elements for their intended purpose to convey meaning and relationships, forming the foundation of accessibility.

Inputs from motion, orientation, or location sensors. Provide alternatives that do not require device motion.

An in-page link placed early in the DOM that jumps directly to the main content, aiding keyboard and screen reader users.

ARIA role for range input controls, requiring aria-valuenow and keyboard increment/decrement support.

ARIA role for numeric input with increment/decrement buttons or keyboard arrow support.

Non-interruptive updates, like success alerts, announced to assistive tech using aria-live or role="status".

Timed text for videos that translates speech into another language and usually omits non-speech audio cues.

Documented methods from W3C that reliably meet a WCAG success criterion when properly implemented.

ARIA role for on/off toggle controls, similar to checkbox but representing state rather than selection.

The sequence focus follows when users press Tab. It should match the visual reading order and never be manipulated with positive tabindex.

ARIA role for tab navigation elements, used with tablist and tabpanel roles.

HTML attribute controlling focus order and focusability. Use -1 for programmatic focus, avoid positive values.

ARIA role for container of tab elements, requiring arrow key navigation between tabs.

ARIA role for content area associated with a tab, revealed when the tab is selected.

UI pattern using tablist, tab, and tabpanel roles with arrow key navigation and automatic tab activation.

Minimum recommended dimensions for interactive controls to ensure comfortable touch and pointer operation.

Pain management device that may affect sensitivity to touch interfaces and vibration feedback.

Equivalent text for non-text content such as images, icons, and media, enabling access by assistive technologies.

ARIA role for text input elements, supporting both single-line and multiline configurations.

Session time limits must warn users, allow extension, or be essential. Provide clear timers and recovery paths.

Temporary message overlay. Must be announced to screen readers via live regions and be dismissible.

ARIA role for grouping interactive controls, typically with arrow key navigation.

Contextual popup triggered by hover or focus. Must be keyboard accessible and dismissible.

ARIA role for hierarchical list structures with expandable/collapsible nodes.

ARIA role for individual nodes within a tree widget, supporting selection and expansion states.

A WCAG POUR principle: interfaces must be clear and interactions predictable to minimize confusion or errors.

Designing products for the broadest range of users without adaptation, benefitting people with and without disabilities.

Testing method involving real users to evaluate effectiveness, efficiency, and satisfaction of interfaces.

Evaluations that involve people with disabilities to validate real-world usability beyond automated and expert reviews.

Standards-compliant markup that avoids errors. Validity improves parsing by assistive technologies and user agents.

Primary page scroll direction on the web. Ensure content does not rely on horizontal scrolling except for necessary data tables and code blocks.

Control of foreground/background color, line spacing, and text size to support readability and preference customization.

Input method that allows users to operate interfaces via speech. Controls need clear labels and visible text for command recognition.

Built-in screen reader for macOS and iOS devices, providing speech and braille output.

Document format for reporting product accessibility conformance against standards like WCAG, Section 508, or EN 301 549.

W3C initiative developing accessibility guidelines, techniques, and resources including WCAG and ARIA.

W3C guidance on building accessible widgets and patterns using ARIA in conjunction with semantic HTML.

Browser extension and online tool by WebAIM for visual accessibility evaluation and error identification.

International standard defining success criteria for accessible web content, currently at version 2.x with levels A, AA, AAA.

Levels A, AA, AAA indicate increasing strictness of success criteria met by content; most policies require at least AA.

Performance metrics (LCP, CLS, INP) intersect with accessibility by ensuring fast, stable, and responsive experiences.

A common tool to verify color contrast ratios meet WCAG requirements for text and UI components.

Built-in Windows screen reader providing basic accessibility features for system navigation and web browsing.

Practices for ensuring data-oriented markup remains usable, including meaningful element names and text alternatives for embedded media.

Magnification software that enlarges content and may enhance contrast or cursor visibility for low-vision users.