Wcag 2 2 A
30 wpisów
WCAG 1.1.1: Non-text Content
WCAG 1.1.1 requires that all non-text content — images, icons, controls, and media — has a text alternative that conveys the same purpose or information, enabling users who cannot perceive visual content to access it through assistive technologies such as screen readers.
WCAG 1.2.1: Audio-only and Video-only (Prerecorded)
WCAG 1.2.1 requires that prerecorded audio-only and video-only content have a text-based or media alternative so users who cannot hear or see the media can still access the information. This is a Level A requirement, meaning it is the minimum baseline for web accessibility compliance.
WCAG 1.2.2: Captions (Prerecorded)
WCAG 1.2.2 requires that all prerecorded audio content in synchronized media (video with audio) includes accurate captions. This ensures deaf and hard-of-hearing users can access spoken dialogue, sound effects, and other meaningful audio information.
WCAG 1.2.3: Audio Description or Media Alternative (Prerecorded)
WCAG 1.2.3 requires that prerecorded synchronized media (video with audio) provides either an audio description of the visual content or a full text alternative, ensuring users who are blind or have low vision can access information conveyed visually.
WCAG 1.3.1: Info and Relationships
WCAG 1.3.1 requires that information, structure, and relationships conveyed through visual presentation can also be determined programmatically or are available in text, ensuring that users of assistive technologies receive the same structural context as sighted users.
WCAG 1.3.2: Meaningful Sequence
WCAG 1.3.2 requires that when the order of content affects its meaning, that sequence must be determinable programmatically so assistive technologies can present it correctly. Failing this criterion causes screen reader users and other AT users to receive content in a confusing or meaningless order.
WCAG 1.3.3: Sensory Characteristics
WCAG 1.3.3 requires that instructions for using content do not rely solely on sensory characteristics such as shape, color, size, visual location, orientation, or sound. This ensures that users who cannot perceive those sensory cues — due to blindness, color blindness, deafness, or other disabilities — can still understand and operate all features.
WCAG 1.4.1: Use of Color
WCAG 1.4.1 requires that color is never the sole means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. This criterion ensures users who cannot perceive color differences—including people with color blindness or low vision—can still access all content and functionality.
WCAG 1.4.2: Audio Control
WCAG 1.4.2 requires that any audio playing automatically for more than three seconds must offer users a mechanism to pause, stop, or control its volume independently of the system volume. This prevents audio from interfering with screen reader output and protects users from unexpected, disorienting sound.
WCAG 2.1.1: Keyboard
WCAG 2.1.1 requires that all functionality available through a mouse or pointer is equally operable via a keyboard alone, with no specific timing required for keystrokes. This criterion is foundational for users who cannot use a mouse, ensuring they can navigate, interact with, and complete tasks on any website or application.
WCAG 2.1.2: No Keyboard Trap
WCAG 2.1.2 requires that keyboard users are never trapped inside a component — if focus can be moved into a UI element using a keyboard, it must also be possible to move focus away using only the keyboard. This criterion is essential for users who rely exclusively on keyboard navigation, including people with motor disabilities and screen reader users.
WCAG 2.1.4: Character Key Shortcuts
WCAG 2.1.4 requires that any keyboard shortcut implemented using only a single character key (letter, number, punctuation, or symbol) can be turned off, remapped, or activated only on focus — preventing accidental triggers that harm users who rely on speech input or have motor disabilities.
WCAG 2.2.1: Timing Adjustable
WCAG 2.2.1 requires that any time limit set by content can be turned off, adjusted, or extended by the user — ensuring people who need more time to interact with web content are not locked out. This Level A criterion is essential for users with motor, cognitive, and visual disabilities.
WCAG 2.2.2: Pause, Stop, Hide
WCAG 2.2.2 requires that moving, blinking, scrolling, or auto-updating content can be paused, stopped, or hidden by users. This protects people with cognitive disabilities, vestibular disorders, and attention-related conditions from content they cannot control.
WCAG 2.3.1: Three Flashes or Below Threshold
WCAG 2.3.1 requires that web content does not contain anything that flashes more than three times per second, unless the flash is below general or red flash thresholds. This criterion is critical for preventing seizures and physical reactions in users with photosensitive epilepsy or similar neurological conditions.
WCAG 2.4.1: Bypass Blocks
WCAG 2.4.1 requires that web pages provide a mechanism to skip repeated blocks of content, such as navigation menus, so keyboard and assistive technology users can reach main content without tabbing through every link. This is a Level A requirement, meaning it is the baseline for accessible keyboard navigation.
WCAG 2.4.2: Page Titled
WCAG 2.4.2 requires that every web page has a descriptive, meaningful title that identifies its topic or purpose. This ensures users — especially those relying on screen readers or managing multiple tabs — can quickly orient themselves and navigate efficiently.
WCAG 2.4.3: Focus Order
WCAG 2.4.3 requires that if a web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components must receive focus in an order that preserves meaning and operability. This criterion is essential for keyboard and assistive technology users who rely on a logical, predictable focus sequence to understand and interact with content.
WCAG 2.4.4: Link Purpose (In Context)
WCAG 2.4.4 requires that the purpose of every link can be determined from the link text alone, or from the link text together with its surrounding context. This ensures that screen reader users, keyboard-only users, and people with cognitive disabilities can understand where a link leads without needing to follow it.
WCAG 2.5.1: Pointer Gestures
WCAG 2.5.1 requires that all functionality using multipoint or path-based gestures (such as pinch-to-zoom or swipe) can also be operated with a single pointer without a path-based gesture, unless the gesture is essential. This protects users with motor impairments who cannot reliably perform complex touch gestures.
WCAG 2.5.2: Pointer Cancellation
WCAG 2.5.2 requires that functionality triggered by a single pointer (mouse, touch, or stylus) can be cancelled or reversed, preventing accidental activations. This protects users with motor impairments who may tap or click unintentionally.
WCAG 2.5.4: Motion Actuation
WCAG 2.5.4 requires that any functionality triggered by device or user motion (such as shaking or tilting) must also be operable through conventional user interface components, and users must be able to disable motion actuation to prevent accidental activation.
WCAG 3.1.1: Language of Page
WCAG 3.1.1 requires that the default human language of each web page can be programmatically determined, primarily by setting a valid lang attribute on the HTML element. This enables assistive technologies like screen readers to pronounce content correctly and helps users with cognitive and language-based disabilities understand the page.
WCAG 3.2.1: On Focus
WCAG 3.2.1 On Focus requires that when any user interface component receives keyboard focus, it must not trigger an unexpected change of context. This protects keyboard and assistive technology users from disorienting, unpredictable behavior that can make a page impossible to navigate effectively.
WCAG 3.2.2: On Input
WCAG 3.2.2 On Input requires that changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of that behavior beforehand. This protects users from disorienting, unexpected page changes triggered by form interactions.
WCAG 3.3.1: Error Identification
WCAG 3.3.1 requires that when an input error is automatically detected, the item in error is identified and the error is described to the user in text. This ensures users with disabilities can recognize, understand, and correct mistakes when filling out forms.
WCAG 3.3.2: Labels or Instructions
WCAG 3.3.2 requires that labels or instructions are provided when content requires user input, ensuring that all users — regardless of ability — can understand what is expected of them before submitting form data. Failing to label form fields is one of the most common and impactful accessibility barriers on the web.
WCAG 3.3.7: Redundant Entry
WCAG 3.3.7 requires that information users have already provided in a multi-step process is either auto-populated or made available for selection, so users never have to re-enter the same data twice. This prevents frustration and errors for users with cognitive, motor, or other disabilities.
WCAG 4.1.2: Name, Role, Value
WCAG 4.1.2 requires that all user interface components have a programmatically determinable name and role, and that states, properties, and values can be both read and set by assistive technologies. This ensures screen readers and other tools can accurately identify, describe, and interact with every element on the page.
WCAG 4.1.1: Parsing (Deprecated in WCAG 2.2)
WCAG 4.1.1 Parsing requires that web content be free of major HTML/XML errors—such as duplicate IDs—that could cause assistive technologies to misinterpret or fail to process the page. Although deprecated in WCAG 2.2, the underlying axe-core rules remain active and violations still indicate real accessibility risk.