Web Accessibility Guide: What Are the Key Conformance Criteria of WCAG 2.2 Level A?

In the digital age, the internet has become an indispensable part of daily life. However, for individuals with disabilities, accessing websites often presents significant challenges. To address this issue, the World Wide Web Consortium (W3C) introduced the Web Content Accessibility Guidelines (WCAG).

WCAG 2.2, the current version of these guidelines, includes three levels of conformance: Level A, AA, and AAA. Level A represents the most fundamental accessibility requirements. This article will focus on explaining the key criteria included in WCAG 2.2 Level A.

Web Design Fundamentals: About the W3C's Web Content Accessibility Guidelines (WCAG)



The Web Content Accessibility Guidelines (WCAG) are part of the W3C Web Accessibility Initiative (WAI). They aim to assist web designers and developers in creating websites that are more accessible to people with disabilities or those affected by age-related limitations.

WCAG explains how to implement accessible design so that websites can be used by people with disabilities. While the guidelines may seem complex, their logic and content are actually very clear. Any web developer can understand how to adopt and comply with them with a little study.

Web Design Fundamentals: What Are the Key Conformance Criteria of WCAG 2.2 Level A?



Non-text Content: Provide text alternatives for all non-text content so it can be changed into other forms people need, such as large print, braille, speech, symbols, or simpler language. All images must have descriptive alt text that accurately conveys their content or function for screen readers. Exceptions include CAPTCHAs or purely decorative images that do not convey information.

Audio-only and Video-only (Prerecorded): Provide alternatives for prerecorded audio-only and video-only content, such as transcripts for audio or audio descriptions/an alternative time-based media for video, so users who cannot perceive the content through one medium can access it.

Captions (Prerecorded): Provide captions for all prerecorded audio content in synchronized media (e.g., videos), enabling deaf or hard-of-hearing users to access the auditory information.

Audio Description or Media Alternative (Prerecorded): Provide an audio description of the video content or a full text alternative for prerecorded video content. This allows blind or visually impaired users to understand the visual information.

Info and Relationships: Use semantic markup (like headings, lists, tables) to convey information, structure, and relationships between sections of content programmatically. This ensures screen readers can correctly interpret the page structure.

Meaningful Sequence: When the sequence of content affects its meaning, ensure a correct reading sequence can be programmatically determined (e.g., using proper HTML structure like ol, ul, or heading tags h1-h6).

Sensory Characteristics: Do not rely solely on sensory characteristics like shape, size, color, or visual location to provide instructions (e.g., "click the round button"). Include text cues to ensure instructions are unambiguous.

Use of Color: Color must not be used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. Use additional patterns, text labels, or icons.

Audio Control: If audio plays automatically on a page for more than 3 seconds, provide a mechanism to pause, stop, or control the volume. This is crucial for screen reader users who need to focus on the synthesized speech.

Keyboard Accessibility: All page functionality must be operable through a keyboard interface without requiring specific timings for individual keystrokes (e.g., using Tab, Enter, arrow keys). Provide easy ways to dismiss modal dialogs or pop-ups.

Character Key Shortcuts: If a keyboard shortcut uses only letter, punctuation, number, or symbol characters, at least one of the following must be true: it can be turned off, remapped, or is only active when the relevant component has focus.

Timing Adjustable: For any time-limited content or session, provide options to turn off, adjust, or extend the time limit (with notable exceptions like real-time events or auctions).

Pause, Stop, Hide: For any moving, blinking, scrolling, or auto-updating information that starts automatically and lasts more than five seconds, provide a mechanism for users to pause, stop, or hide it.

Three Flashes or Below Threshold: Web pages must not contain anything that flashes more than three times in any one second period, or the flash must be below the general flash and red flash thresholds to avoid triggering seizures.

Bypass Blocks: Provide a mechanism (like a "Skip to Main Content" link) to bypass blocks of content that are repeated on multiple web pages, allowing users to reach primary content directly.

Page Titled: Give each web page a descriptive and informative title using the title element to help users identify the page's purpose and content.

Focus Order: If navigating sequentially through the page (e.g., with Tab key), the focus order should follow a logical sequence that preserves meaning and operability.

Link Purpose (In Context): The purpose of each link must be determinable from the link text alone or from the link text combined with its programmatically determined link context. Avoid vague text like "click here."

Pointer Gestures: All functionality that uses multipoint or path-based gestures (like pinching or swiping) must also be operable with a single pointer without a path-based gesture (e.g., a simple click or long press alternative).

Pointer Cancellation: For functionality operated by a single pointer (e.g., mouse click, single-tap), the down-event (like mouse down) should not execute the function. The function should be initiated on the up-event (like mouse up), allowing users to cancel the action.

Label in Name: For user interface components with visible labels (like buttons), the accessible name (programmatic name) must contain the text presented in the visible label. This ensures speech input users can activate controls by speaking the visible label.

Motion Actuation: If functionality is triggered by device motion (e.g., shaking, tilting) or user gesture interpretation, it must also be operable by standard user interface components, and motion actuation must be able to be disabled.

Language of Page: The default human language of each web page must be programmatically determinable (e.g., using the lang attribute in HTML) so assistive technologies can correctly pronounce text.

On Focus: When any component receives focus (e.g., via Tab key), it must not initiate an automatic change of context (like opening a new window or submitting a form). Changes must be initiated by the user.

On Input: Changing the setting of any user interface component (e.g., selecting a dropdown option) must not automatically cause a change of context (like submitting a form). The user should be informed of the behavior before using the component.

Consistent Help: If a help mechanism (e.g., contact link, self-help option) is available on multiple pages, it should be presented in the same relative order/location each time.

Error Identification: If an input error is automatically detected, the error item must be identified and described to the user in text. This allows screen reader users to be aware of the error.

Labels or Instructions: Provide clear labels and/or instructions when content requires user input (e.g., in forms), including examples of expected data formats if necessary.

Redundant Entry: In multi-step processes (like forms or checkouts), do not require users to re-enter the same information they provided in a previous step, unless essential for security.

Parsing: In content implemented using markup languages (like HTML), elements must have complete start and end tags, be nested according to their specifications, and not contain duplicate attributes. This ensures robust interpretation by assistive technologies.

*Note: This criterion was removed from WCAG 2.2 but was required in WCAG 2.1 and 2.0 for content using HTML/XML.*

Name, Role, Value: For all user interface components (like form fields, buttons), the name (accessible name) and role (e.g., 'button', 'checkbox') must be programmatically determinable. For components that can change state (e.g., checkboxes), the current state/value must also be settable and programmatically exposed to assistive technologies.

Adhering to WCAG 2.2 Level A success criteria ensures your website is friendly and accessible to the majority of users. If you aim to provide a more inclusive and convenient digital experience for people with disabilities, striving for higher conformance levels (AA and AAA) is recommended to ensure optimal accessibility for all users.