Loading...
Every requirement of EN 301 549 v3.2.1, the European ICT accessibility standard behind the EAA and the Web Accessibility Directive, in plain language with 285 trackable requirements, WCAG 2.1 cross-links, notes, and Excel export.
Version note (reviewed 27 August 2026): this checklist follows v3.2.1, the version currently cited in the Official Journal and the one that carries legal presumption of conformity. The v4 revision aligned to WCAG 2.2 is in the ETSI approval pipeline; see exactly what changes in v4. Auditing against WCAG 2.2 AA today satisfies the WCAG 2.1 clauses here and is already aligned with where v4 lands.
0 of 285 requirements marked done (0%)
0 requirements shown
4.1 Meeting functional performance statements
Explains how the functional performance statements in clause 4.2 are used: they describe outcomes that let people locate, identify, and operate ICT functions regardless of physical, cognitive, or sensory ability, and Annex B maps every requirement to them.
Applies to: All ICT
4.2.1 Usage without vision
Where ICT has visual modes of operation, at least one mode of operation should not require vision at all.
Applies to: All ICT
4.2.2 Usage with limited vision
Where ICT has visual modes of operation, it should provide features (such as magnification or contrast adjustment) that let people with limited vision use it.
Applies to: All ICT
4.2.3 Usage without perception of colour
Where ICT has visual modes of operation, at least one visual mode should not depend on the user perceiving colour.
Applies to: All ICT
4.2.4 Usage without hearing
Where ICT has auditory modes of operation, at least one mode of operation should not require hearing.
Applies to: All ICT
4.2.5 Usage with limited hearing
Where ICT has auditory modes of operation, it should provide enhanced audio features (such as clarity enhancement or volume boost) for people with limited hearing.
Applies to: All ICT
4.2.6 Usage with no or limited vocal capability
Where ICT requires vocal input, at least one mode of operation should not require the user to speak.
Applies to: All ICT
4.2.7 Usage with limited manipulation or strength
Where ICT requires manual actions, it should offer alternatives that do not need fine manipulation, simultaneous actions, or hand strength.
Applies to: All ICT
4.2.8 Usage with limited reach
Where ICT products are free-standing or installed, every element needed for operation should be within reach of all users, including wheelchair users.
Applies to: All ICT
4.2.9 Minimize photosensitive seizure triggers
Where ICT has visual modes of operation, at least one mode should minimise the potential for triggering photosensitive seizures.
Applies to: All ICT
4.2.10 Usage with limited cognition, language or learning
ICT should provide features and presentation that make it simpler to understand, operate, and use for people with limited cognition, language, or learning.
Applies to: All ICT
4.2.11 Privacy
Where ICT provides accessibility features, using them should not cost the user more privacy than other users get.
Applies to: All ICT
33 requirements shown
ICT with closed functionality must meet the applicable requirements of clauses 5.2 to 13 for those closed functions.
Applies to: Closed functionality
Closed functionality must be operable without the user attaching, connecting, or installing assistive technology, and must meet clauses 5.1.3 to 5.1.6 instead of assuming AT support.
Applies to: Closed functionality
Where visual information is needed to use functions closed to screen readers, provide at least one non-visual mode of access (such as speech output) conveying the same information.
Applies to: Closed functionality
Auditory output used as non-visual access must be delivered either by a mechanism included with the ICT or through a standard personal headset connection that can be used without vision.
Applies to: Closed functionality
Advisory: where information is displayed on screen, auditory output should let the user correlate what they hear with what is on the screen.
Applies to: Closed functionality
Speech output must be interruptible and repeatable on request, where security requirements permit.
Applies to: Closed functionality
The ICT must interrupt current speech output when a user action occurs and when new speech output begins.
Applies to: Closed functionality
Alternatives for non-text content must be spoken aloud, unless the content is pure decoration or only visual formatting.
Applies to: Closed functionality
Where pre-recorded video is needed to use closed functions, speech output must present equivalent information for the video content.
Applies to: Closed functionality
Speech output must not read masked characters (such as PIN digits) aloud unless the user explicitly chooses audible unmasked entry.
Applies to: Closed functionality
Auditory output containing private data must only be delivered through a private listening mechanism (such as a headset) or another user-chosen private means.
Applies to: Closed functionality
The ICT must not automatically play interfering audio lasting longer than three seconds at the same time as the speech output.
Applies to: Closed functionality
Where auditory output is delivered through a private listening mechanism, at least one non-visual way to control the volume must exist.
Applies to: Closed functionality
Where auditory output is delivered through speakers, a non-visual incremental volume control with amplification up to at least 65 dBA must be provided.
Applies to: Closed functionality
On shared-use ICT, a function must reset the volume to 65 dBA or less after every use.
Applies to: Closed functionality
Speech output must be in the same human language as the displayed content, with narrow exceptions such as proper names, technical terms, and languages the ICT cannot speak.
Applies to: Closed functionality
Where an input error is automatically detected, speech output must identify and describe the item in error.
Applies to: Closed functionality
Receipts, tickets, and other transaction outputs from self-service ICT must have their essential information available via speech output (printed copies themselves are exempt).
Applies to: Closed functionality
Where functionality is closed to text-enlargement features, the ICT must itself provide a mode where text needed for all functionality is legible at distance-appropriate sizes.
Applies to: Closed functionality
Where auditory information is needed to use closed functions, the ICT must provide equivalent visual information, such as captions.
Applies to: Closed functionality
Where functionality is closed to keyboards and keyboard interfaces, all of it must be operable without vision as required by clause 5.1.3.
Applies to: Closed functionality
Where input focus can be moved to an element, it must also be movable away from that element using the same mechanism, so focus cannot get trapped.
Applies to: Closed functionality
Where speech is needed to operate closed functions, at least one alternative input mechanism that does not require speech must be provided.
Applies to: Closed functionality
Documented accessibility features must be activatable without relying on a method that the feature's target users cannot use.
Applies to: Generic ICT capabilities
ICT using biometrics must not make one particular biological characteristic the only way to identify a user or control the ICT.
Applies to: Generic ICT capabilities
When ICT converts information, it must preserve all documented non-proprietary accessibility information the destination format can hold.
Applies to: Generic ICT capabilities
Operable parts requiring grasping, pinching, or wrist-twisting must have an accessible alternative means of operation.
Applies to: Generic ICT capabilities
Every operable part must be discernible without vision and without performing its action, for example through tactile marking.
Applies to: Generic ICT capabilities
Where a locking or toggle control shows its status visually, at least one mode must expose the status by touch or sound as well.
Applies to: Generic ICT capabilities
Where a locking or toggle control exposes its status non-visually, at least one mode must make the status visually determinable too.
Applies to: Generic ICT capabilities
A key-repeat function that cannot be turned off must allow a repeat delay of at least 2 seconds and a rate adjustable down to 1 character per 2 seconds.
Applies to: Generic ICT capabilities
On keyboards and keypads, the delay for rejecting an accidental identical second keystroke must be adjustable up to at least 0.5 seconds.
Applies to: Generic ICT capabilities
Any operation requiring simultaneous user actions must have at least one mode of operation that does not.
Applies to: Generic ICT capabilities
17 requirements shown
Two-way voice communication must support speech encoding with an upper frequency limit of at least 7 000 Hz, for intelligible audio quality.
Applies to: Two-way voice communication
ICT providing two-way voice communication must also provide two-way real-time text (RTT), except where that would require adding input or output hardware.
Applies to: Real-time text (RTT)
Where voice and RTT are both provided, the ICT must allow concurrent voice and text over a single connection.
Applies to: Real-time text (RTT)
Displayed sent RTT text must be visually distinguishable from and separated from received text.
Applies to: Real-time text (RTT)
The send and receive direction of RTT text must be programmatically determinable, unless the RTT is closed functionality, so screen readers can voice who typed what.
Applies to: Real-time text (RTT)
Where speaker identification is available for voice, it must also be available for RTT participants.
Applies to: Real-time text (RTT)
Where voice and RTT are both active, a real-time visual indicator of audio activity must be shown on the display.
Applies to: Real-time text (RTT)
ICT with RTT functionality must interoperate with other RTT ICT using the applicable standard mechanisms listed in the clause (such as ITU-T T.140 for IP telephony).
Applies to: Real-time text (RTT)
RTT input must reach the network or platform within 500 ms of the smallest reliably composed unit of text being available, so text truly flows in real time.
Applies to: Real-time text (RTT)
Caller ID and similar functions must be available in text form and be programmatically determinable, unless the functionality is closed.
Applies to: Two-way voice communication
Where real-time voice services offer voicemail, auto-attendant, or interactive voice response, the same information and tasks must be achievable without hearing or speech.
Applies to: Two-way voice communication
Real-time video used with voice communication must support at least QVGA resolution, and preferably VGA or better.
Applies to: Voice + real-time video
Real-time video used with voice communication must support at least 20 frames per second, and preferably 30 or more.
Applies to: Voice + real-time video
The time difference between speech and video presented to the user must not exceed 100 ms, keeping lip-reading viable.
Applies to: Voice + real-time video
Where video is part of two-way voice communication, a real-time visual indicator of audio activity must be provided.
Applies to: Voice + real-time video
Where speaker identification exists for voice users, an equivalent means must identify who is currently signing in real-time video.
Applies to: Voice + real-time video
Advisory: where real-time video services offer answering machine, auto-attendant, or interactive response facilities, users should be able to access them through video as well.
Applies to: Two-way voice communication
9 requirements shown
ICT that displays video with synchronized audio must have a mode that displays available captions, including user-selectable closed captions.
Applies to: ICT with video capabilities
Caption display must stay synchronized: within 100 ms of the caption timestamp for recorded material, and within 100 ms of caption availability for live captions.
Applies to: ICT with video capabilities
ICT that transmits, converts, or records video must preserve caption data so captions can still be displayed correctly downstream.
Applies to: ICT with video capabilities
Users must be able to adapt caption display characteristics (such as size, colour, and background) except where captions are unmodifiable characters.
Applies to: ICT with video capabilities
ICT displaying video with synchronized audio must offer spoken output of the available captions (spoken subtitles), where caption content is programmatically determinable.
Applies to: ICT with video capabilities
A mechanism must exist to select and play available audio description to the default audio channel.
Applies to: ICT with video capabilities
Audio description playback must stay synchronized with the audio-visual content.
Applies to: ICT with video capabilities
ICT that transmits, converts, or records video must preserve audio description data for downstream playback.
Applies to: ICT with video capabilities
Controls to activate captions and audio description must sit at the same level of interaction as the primary media controls, not buried in deeper menus.
Applies to: ICT with video capabilities
31 requirements shown
The generic requirements of clause 5 also apply to hardware.
Applies to: Hardware
Where hardware provides input or output connection points, at least one must use an industry-standard non-proprietary format, directly or via commercially available adapters.
Applies to: Hardware
Hardware must not use colour as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing an element.
Applies to: Hardware
Hardware with speech output must allow speech volume adjustment over a range of at least 18 dB.
Applies to: Hardware with speech output
Where the volume control is incremental, at least one intermediate step of 12 dB gain above the lowest setting must exist.
Applies to: Hardware with speech output
Fixed-line handsets held to the ear must provide magnetic coupling meeting ETSI ES 200 381-1, marked with the T symbol, for hearing-aid users.
Applies to: Hardware with speech output
Wireless communication devices held to the ear must provide magnetic coupling to hearing technologies meeting ETSI ES 200 381-2.
Applies to: Hardware with speech output
Stationary ICT must meet either the forward-reach dimensions of clause 8.3.2 or the side-reach dimensions of clause 8.3.3.
Applies to: Stationary ICT
With unobstructed forward reach, at least one of each type of operable part must be no higher than 1 220 mm above the floor.
Applies to: Stationary ICT
With unobstructed forward reach, at least one of each type of operable part must be no lower than 380 mm above the floor.
Applies to: Stationary ICT
Where an integral obstruction hinders access, clear space must extend beneath it at least as far as the obstruction's own depth.
Applies to: Stationary ICT
With an integral obstruction shallower than 510 mm, forward reach to at least one of each type of operable part must be no higher than 1 220 mm.
Applies to: Stationary ICT
With an integral obstruction between 510 mm and 635 mm deep, forward reach must be no higher than 1 120 mm.
Applies to: Stationary ICT
Knee and toe clearance under an integral obstacle that forms part of the access space must be at least 760 mm wide.
Applies to: Stationary ICT
Toe clearance (space under 230 mm above the floor) must extend no more than 635 mm under the whole obstacle and meet the clause's minimum depth and height dimensions.
Applies to: Stationary ICT
Knee clearance (230 mm to 685 mm above the floor) must meet the clause's depth and height dimensions so a seated user can approach.
Applies to: Stationary ICT
With unobstructed side reach (obstruction under 255 mm), at least one of each type of operable part must be within a high side reach of no more than 1 220 mm.
Applies to: Stationary ICT
With unobstructed side reach, at least one of each type of operable part must be no lower than a side reach of 380 mm.
Applies to: Stationary ICT
With an integral side obstruction up to 255 mm deep and under 865 mm high, the side reach must be no higher than 1 220 mm.
Applies to: Stationary ICT
With an integral side obstruction between 255 mm and 610 mm deep and under 865 mm high, the side reach must be no higher than 1 170 mm.
Applies to: Stationary ICT
Any change of floor level within or entering stationary ICT must be ramped at no steeper than 1:48, with small level changes excepted.
Applies to: Stationary ICT
An operating area within stationary ICT must provide clear floor space of at least 760 mm by 1 220 mm.
Applies to: Stationary ICT
Where a forward approach into an alcove deeper than 610 mm is necessary, the access space must be at least 915 mm wide.
Applies to: Stationary ICT
Where a parallel approach to an alcove deeper than 380 mm is possible, the access space must be at least 1 525 mm wide.
Applies to: Stationary ICT
At least one of each type of display screen must be legible from a point 1 015 mm above the centre of the clear floor space.
Applies to: Stationary ICT
Installation instructions must be available and must cover installing the ICT so its operable parts and displays stay within accessible reach and sight ranges.
Applies to: Stationary ICT
Physical numeric keypads laid out in a rectangle must have a tactilely distinct number five key.
Applies to: Mechanically operable parts
Mechanical controls requiring grasping, pinching, or wrist-twisting must have an accessible alternative means of operation.
Applies to: Mechanically operable parts
Mechanical controls requiring more than 22.2 N of force must have an alternative requiring less than 22.2 N.
Applies to: Mechanically operable parts
Keys, tickets, and fare cards whose orientation matters for further use must have tactilely discernible orientation.
Applies to: Mechanically operable parts
Shared-use ICT with speech output must give a tactile indication (such as braille) of how to start the speech mode.
Applies to: Hardware
51 requirements shown
All non-text content has appropriate text alternatives that serve the equivalent purpose.
Applies to: Web pages
Provide alternatives for prerecorded audio-only and video-only content.
Applies to: Web pages
Captions are provided for all prerecorded audio content in synchronized media.
Applies to: Web pages
Audio description or full text alternative is provided for prerecorded video content.
Applies to: Web pages
Captions are provided for all live audio content in synchronized media.
Applies to: Web pages
Audio description is provided for all prerecorded video content.
Applies to: Web pages
Information, structure, and relationships can be programmatically determined.
Applies to: Web pages
Content can be presented in a meaningful sequence without losing meaning.
Applies to: Web pages
Instructions don't rely solely on sensory characteristics of components.
Applies to: Web pages
Content does not restrict its view to a single display orientation.
Applies to: Web pages
Color is not used as the only visual means of conveying information.
Applies to: Web pages
Audio that plays automatically can be paused, stopped, or controlled.
Applies to: Web pages
Text has a contrast ratio of at least 4.5:1 (3:1 for large text).
Applies to: Web pages
Text can be resized up to 200% without loss of content or functionality.
Applies to: Web pages
Text is used instead of images of text, except for customizable or essential images.
Applies to: Web pages
9.1.4.6 Void
Void. This slot keeps WCAG numbering alignment; the corresponding WCAG 2.1 criterion is Level AAA and is not required by EN 301 549.
Applies to: Web pages
9.1.4.7 Void
Void. This slot keeps WCAG numbering alignment; the corresponding WCAG 2.1 criterion is Level AAA and is not required by EN 301 549.
Applies to: Web pages
9.1.4.8 Void
Void. This slot keeps WCAG numbering alignment; the corresponding WCAG 2.1 criterion is Level AAA and is not required by EN 301 549.
Applies to: Web pages
9.1.4.9 Void
Void. This slot keeps WCAG numbering alignment; the corresponding WCAG 2.1 criterion is Level AAA and is not required by EN 301 549.
Applies to: Web pages
Content can be presented without horizontal scrolling at 320 CSS pixels width.
Applies to: Web pages
UI components and graphical objects have sufficient contrast (3:1 minimum).
Applies to: Web pages
No loss of content when text spacing is adjusted within certain parameters.
Applies to: Web pages
Additional content triggered by hover or focus can be dismissed and doesn't interfere.
Applies to: Web pages
Focus can be moved away from any component using standard keyboard methods.
Applies to: Web pages
9.2.1.3 Void
Void. This slot keeps WCAG numbering alignment; the corresponding WCAG 2.1 criterion is Level AAA and is not required by EN 301 549.
Applies to: Web pages
Moving, blinking, or auto-updating content can be paused, stopped, or hidden.
Applies to: Web pages
Content does not contain anything that flashes more than three times per second.
Applies to: Web pages
A mechanism is available to bypass blocks of content that are repeated.
Applies to: Web pages
Focusable components receive focus in an order that preserves meaning.
Applies to: Web pages
The purpose of each link can be determined from link text or context.
Applies to: Web pages
More than one way is available to locate a page within a set of pages.
Applies to: Web pages
Functionality that uses multipoint or path-based gestures has alternatives.
Applies to: Web pages
Functions triggered by single pointer can be cancelled or undone.
Applies to: Web pages
Functionality triggered by device motion can be disabled and has alternatives.
Applies to: Web pages
The default human language of each page can be programmatically determined.
Applies to: Web pages
The human language of each passage can be programmatically determined.
Applies to: Web pages
When a component receives focus, it does not initiate a change of context.
Applies to: Web pages
Changing settings of a component does not automatically cause context changes.
Applies to: Web pages
Navigational mechanisms are repeated in the same relative order.
Applies to: Web pages
Components with the same functionality are identified consistently.
Applies to: Web pages
Input errors are automatically detected and described to the user.
Applies to: Web pages
Labels or instructions are provided when content requires user input.
Applies to: Web pages
Markup can be reliably interpreted: elements have complete tags, are nested correctly, and do not contain duplicate attributes or non-unique IDs. Obsolete in WCAG 2.2 but still part of WCAG 2.1 and EN 301 549 v3.2.1.
Applies to: Web pages
Name, role, and value can be programmatically determined for UI components.
Applies to: Web pages
Status messages can be programmatically determined through role or properties.
Applies to: Web pages
Web pages must satisfy all five WCAG 2.1 conformance requirements at Level AA: conformance level, full pages, complete processes, accessibility-supported ways of using technologies, and non-interference.
Applies to: Web pages
48 requirements shown
All non-text content has appropriate text alternatives that serve the equivalent purpose.
Applies to: Non-web documents
Provide alternatives for prerecorded audio-only and video-only content.
Applies to: Non-web documents
Captions are provided for all prerecorded audio content in synchronized media.
Applies to: Non-web documents
Audio description or full text alternative is provided for prerecorded video content.
Applies to: Non-web documents
Captions are provided for all live audio content in synchronized media.
Applies to: Non-web documents
Audio description is provided for all prerecorded video content.
Applies to: Non-web documents
Information, structure, and relationships can be programmatically determined.
Applies to: Non-web documents
Content can be presented in a meaningful sequence without losing meaning.
Applies to: Non-web documents
Instructions don't rely solely on sensory characteristics of components.
Applies to: Non-web documents
Content does not restrict its view to a single display orientation.
Applies to: Non-web documents
The purpose of input fields can be programmatically determined.
Applies to: Non-web documents
Color is not used as the only visual means of conveying information.
Applies to: Non-web documents
Audio that plays automatically can be paused, stopped, or controlled.
Applies to: Non-web documents
Text has a contrast ratio of at least 4.5:1 (3:1 for large text).
Applies to: Non-web documents
Text can be resized up to 200% without loss of content or functionality.
Applies to: Non-web documents
Text is used instead of images of text, except for customizable or essential images.
Applies to: Non-web documents
10.1.4.6 Void
Void. This slot keeps WCAG numbering alignment; the corresponding WCAG 2.1 criterion is Level AAA and is not required by EN 301 549.
Applies to: Non-web documents
10.1.4.7 Void
Void. This slot keeps WCAG numbering alignment; the corresponding WCAG 2.1 criterion is Level AAA and is not required by EN 301 549.
Applies to: Non-web documents
10.1.4.8 Void
Void. This slot keeps WCAG numbering alignment; the corresponding WCAG 2.1 criterion is Level AAA and is not required by EN 301 549.
Applies to: Non-web documents
10.1.4.9 Void
Void. This slot keeps WCAG numbering alignment; the corresponding WCAG 2.1 criterion is Level AAA and is not required by EN 301 549.
Applies to: Non-web documents
Content can be presented without horizontal scrolling at 320 CSS pixels width.
Applies to: Non-web documents
UI components and graphical objects have sufficient contrast (3:1 minimum).
Applies to: Non-web documents
No loss of content when text spacing is adjusted within certain parameters.
Applies to: Non-web documents
Additional content triggered by hover or focus can be dismissed and doesn't interfere.
Applies to: Non-web documents
All functionality is available from a keyboard interface.
Applies to: Non-web documents
Focus can be moved away from any component using standard keyboard methods.
Applies to: Non-web documents
10.2.1.3 Void
Void. This slot keeps WCAG numbering alignment; the corresponding WCAG 2.1 criterion is Level AAA and is not required by EN 301 549.
Applies to: Non-web documents
Single character key shortcuts can be turned off or remapped.
Applies to: Non-web documents
Moving, blinking, or auto-updating content can be paused, stopped, or hidden.
Applies to: Non-web documents
Content does not contain anything that flashes more than three times per second.
Applies to: Non-web documents
10.2.4.1 Void
Void. The corresponding WCAG criterion is not applied in this context by EN 301 549 v3.2.1.
Applies to: Non-web documents
Focusable components receive focus in an order that preserves meaning.
Applies to: Non-web documents
The purpose of each link can be determined from link text or context.
Applies to: Non-web documents
10.2.4.5 Void
Void. The corresponding WCAG criterion is not applied in this context by EN 301 549 v3.2.1.
Applies to: Non-web documents
Any keyboard operable interface has a visible focus indicator.
Applies to: Non-web documents
Functionality that uses multipoint or path-based gestures has alternatives.
Applies to: Non-web documents
Functions triggered by single pointer can be cancelled or undone.
Applies to: Non-web documents
Functionality triggered by device motion can be disabled and has alternatives.
Applies to: Non-web documents
The default human language of each page can be programmatically determined.
Applies to: Non-web documents
The human language of each passage can be programmatically determined.
Applies to: Non-web documents
When a component receives focus, it does not initiate a change of context.
Applies to: Non-web documents
Changing settings of a component does not automatically cause context changes.
Applies to: Non-web documents
10.3.2.3 Void
Void. The corresponding WCAG criterion is not applied in this context by EN 301 549 v3.2.1.
Applies to: Non-web documents
10.3.2.4 Void
Void. The corresponding WCAG criterion is not applied in this context by EN 301 549 v3.2.1.
Applies to: Non-web documents
Input errors are automatically detected and described to the user.
Applies to: Non-web documents
Labels or instructions are provided when content requires user input.
Applies to: Non-web documents
Input error suggestions are provided when errors are detected.
Applies to: Non-web documents
Important transactions can be reversed, checked, or confirmed.
Applies to: Non-web documents
Markup can be reliably interpreted: elements have complete tags, are nested correctly, and do not contain duplicate attributes or non-unique IDs. Obsolete in WCAG 2.2 but still part of WCAG 2.1 and EN 301 549 v3.2.1.
Applies to: Non-web documents
Name, role, and value can be programmatically determined for UI components.
Applies to: Non-web documents
Status messages can be programmatically determined through role or properties.
Applies to: Non-web documents
Advisory: captions in synchronized media inside a non-web document should not obscure relevant information in the media.
Applies to: Non-web documents
Advisory: audio description in synchronized media inside a non-web document should not interfere with relevant audio information in the media.
Applies to: Non-web documents
84 requirements shown
All non-text content has appropriate text alternatives that serve the equivalent purpose.
Applies to: Software (open functionality)
Where software is closed to screen readers, it must meet clause 5.1.3.6: alternatives for non-text content are delivered as speech output.
Applies to: Software (closed functionality)
Provide alternatives for prerecorded audio-only and video-only content.
Applies to: Software (open functionality)
Where software is closed to screen readers and pre-recorded audio is needed to use closed functions, it must meet clause 5.1.5 by providing equivalent visual information.
Applies to: Software (closed functionality)
Where software is closed to assistive technology and pre-recorded video is needed to use closed functions, it must meet clause 5.1.3.7 by speaking equivalent information for the video content.
Applies to: Software (closed functionality)
Captions are provided for all prerecorded audio content in synchronized media.
Applies to: Software
Audio description or full text alternative is provided for prerecorded video content.
Applies to: Software (open functionality)
Where software is closed to screen readers, it must meet clause 5.1.3.7: speech output presents equivalent information for pre-recorded video.
Applies to: Software (closed functionality)
Captions are provided for all live audio content in synchronized media.
Applies to: Software
Information, structure, and relationships can be programmatically determined.
Applies to: Software (open functionality)
Advisory: where software is closed to screen readers and information is on screen, auditory output should let the user correlate the audio with the display.
Applies to: Software (closed functionality)
Content can be presented in a meaningful sequence without losing meaning.
Applies to: Software (open functionality)
Advisory: where software is closed to screen readers and information is on screen, auditory output should follow a sequence the user can correlate with the display.
Applies to: Software (closed functionality)
Instructions don't rely solely on sensory characteristics of components.
Applies to: Software
Content does not restrict its view to a single display orientation.
Applies to: Software
The purpose of input fields can be programmatically determined.
Applies to: Software (open functionality)
Where software is closed to assistive technology, at least one mode must present the purpose of each personal-data input field in audio form.
Applies to: Software (closed functionality)
Color is not used as the only visual means of conveying information.
Applies to: Software
Audio that plays automatically can be paused, stopped, or controlled.
Applies to: Software
Text has a contrast ratio of at least 4.5:1 (3:1 for large text).
Applies to: Software
Text can be resized up to 200% without loss of content or functionality.
Applies to: Software (open functionality)
Where software cannot access platform text-enlargement features, it must meet clause 5.1.4 by providing its own legible text mode.
Applies to: Software (closed functionality)
Text is used instead of images of text, except for customizable or essential images.
Applies to: Software (open functionality)
Where software is closed to screen readers, it must meet clause 5.1.3.6: text rendered as images is still delivered via speech output.
Applies to: Software (closed functionality)
11.1.4.6 Void
Void. This slot keeps WCAG numbering alignment; the corresponding WCAG 2.1 criterion is Level AAA and is not required by EN 301 549.
Applies to: Software
11.1.4.7 Void
Void. This slot keeps WCAG numbering alignment; the corresponding WCAG 2.1 criterion is Level AAA and is not required by EN 301 549.
Applies to: Software
11.1.4.8 Void
Void. This slot keeps WCAG numbering alignment; the corresponding WCAG 2.1 criterion is Level AAA and is not required by EN 301 549.
Applies to: Software
11.1.4.9 Void
Void. This slot keeps WCAG numbering alignment; the corresponding WCAG 2.1 criterion is Level AAA and is not required by EN 301 549.
Applies to: Software
Content can be presented without horizontal scrolling at 320 CSS pixels width.
Applies to: Software
UI components and graphical objects have sufficient contrast (3:1 minimum).
Applies to: Software
No loss of content when text spacing is adjusted within certain parameters.
Applies to: Software
Additional content triggered by hover or focus can be dismissed and doesn't interfere.
Applies to: Software
All functionality is available from a keyboard interface.
Applies to: Software (open functionality)
Where software is closed to keyboards and keyboard interfaces, it must meet clause 5.1.6.1: all functionality operable without vision.
Applies to: Software (closed functionality)
Focus can be moved away from any component using standard keyboard methods.
Applies to: Software
11.2.1.3 Void
Void. This slot keeps WCAG numbering alignment; the corresponding WCAG 2.1 criterion is Level AAA and is not required by EN 301 549.
Applies to: Software
Single character key shortcuts can be turned off or remapped.
Applies to: Software (open functionality)
Where software is closed to keyboards and keyboard interfaces, it must meet clause 5.1.6.1 rather than the character-key-shortcuts criterion.
Applies to: Software (closed functionality)
Moving, blinking, or auto-updating content can be paused, stopped, or hidden.
Applies to: Software
Content does not contain anything that flashes more than three times per second.
Applies to: Software
11.2.4.1 Void
Void. The corresponding WCAG criterion is not applied in this context by EN 301 549 v3.2.1.
Applies to: Software
11.2.4.2 Void
Void. The corresponding WCAG criterion is not applied in this context by EN 301 549 v3.2.1.
Applies to: Software
Focusable components receive focus in an order that preserves meaning.
Applies to: Software
The purpose of each link can be determined from link text or context.
Applies to: Software
11.2.4.5 Void
Void. The corresponding WCAG criterion is not applied in this context by EN 301 549 v3.2.1.
Applies to: Software
Functionality that uses multipoint or path-based gestures has alternatives.
Applies to: Software
The accessible name contains the visible label text.
Applies to: Software (open functionality)
Advisory: where software is closed to screen readers, it should meet clause 5.1.3.3 on auditory output correlation.
Applies to: Software (closed functionality)
Functionality triggered by device motion can be disabled and has alternatives.
Applies to: Software
The default human language of each page can be programmatically determined.
Applies to: Software (open functionality)
Where software is closed to screen readers, it must meet clause 5.1.3.14: speech output in the same human language as the displayed content.
Applies to: Software (closed functionality)
11.3.1.2 Void
Void. The corresponding WCAG criterion is not applied in this context by EN 301 549 v3.2.1.
Applies to: Software
When a component receives focus, it does not initiate a change of context.
Applies to: Software
Changing settings of a component does not automatically cause context changes.
Applies to: Software
11.3.2.3 Void
Void. The corresponding WCAG criterion is not applied in this context by EN 301 549 v3.2.1.
Applies to: Software
11.3.2.4 Void
Void. The corresponding WCAG criterion is not applied in this context by EN 301 549 v3.2.1.
Applies to: Software
Input errors are automatically detected and described to the user.
Applies to: Software (open functionality)
Where software is closed to screen readers, it must meet clause 5.1.3.15: speech output identifies and describes detected input errors.
Applies to: Software (closed functionality)
Labels or instructions are provided when content requires user input.
Applies to: Software
Markup can be reliably interpreted: elements have complete tags, are nested correctly, and do not contain duplicate attributes or non-unique IDs. Obsolete in WCAG 2.2 but still part of WCAG 2.1 and EN 301 549 v3.2.1.
Applies to: Software (open functionality)
11.4.1.1.2 Parsing (closed functionality)
Not applicable. Software closed to all assistive technology does not have to meet the Parsing criterion, whose intent is exposing information to assistive technology.
Applies to: Software (closed functionality)
Name, role, and value can be programmatically determined for UI components.
Applies to: Software (open functionality)
Not applicable. Software closed to all assistive technology does not have to meet Name, Role, Value, which exists to serve assistive technology interoperability.
Applies to: Software (closed functionality)
Status messages can be programmatically determined through role or properties.
Applies to: Software (open functionality)
Not applicable. Software closed to all assistive technology does not have to meet Status Messages, which exists to serve assistive technology interoperability.
Applies to: Software (closed functionality)
Software whose closed functionality conforms to clause 5.1 does not additionally need to meet the assistive-technology interoperability requirements of 11.5.2.
Applies to: Software & platforms (AT interoperability)
Platform software must provide documented services that let software with a user interface interoperate with assistive technology.
Applies to: Software & platforms (AT interoperability)
Platform software must provide documented accessibility services that let assistive technology interoperate with software running on the platform.
Applies to: Software & platforms (AT interoperability)
Software with a user interface must use the platform's documented accessibility services; where those are insufficient, other documented services may be used.
Applies to: Software & platforms (AT interoperability)
Assistive technology itself must use the documented platform accessibility services.
Applies to: Software & platforms (AT interoperability)
The role, states, boundary, name, and description of every user interface element must be programmatically determinable by assistive technology.
Applies to: Software & platforms (AT interoperability)
The row, column, and any headers of each data table cell must be programmatically determinable by assistive technology.
Applies to: Software & platforms (AT interoperability)
Current, minimum, and maximum values of a ranged element (such as a slider) must be programmatically determinable by assistive technology.
Applies to: Software & platforms (AT interoperability)
Label relationships between elements (labels and labelled-by) must be exposed to assistive technology.
Applies to: Software & platforms (AT interoperability)
Parent-child relationships between elements must be programmatically determinable by assistive technology.
Applies to: Software & platforms (AT interoperability)
Text contents, text attributes, and the boundary of text on screen must be programmatically determinable by assistive technology.
Applies to: Software & platforms (AT interoperability)
A list of the actions available on an element must be programmatically determinable by assistive technology.
Applies to: Software & platforms (AT interoperability)
Where security permits, assistive technology must be able to programmatically execute those exposed actions.
Applies to: Software & platforms (AT interoperability)
Information needed to track focus, the text insertion point, and selection attributes must be exposed to assistive technology.
Applies to: Software & platforms (AT interoperability)
Where security permits, assistive technology must be able to programmatically move focus, the text insertion point, and selection.
Applies to: Software & platforms (AT interoperability)
Assistive technology must be notified of changes to the programmatically determinable attributes of elements.
Applies to: Software & platforms (AT interoperability)
Where security permits, assistive technology must be able to modify states and properties of elements, where the user can modify them.
Applies to: Software & platforms (AT interoperability)
Where security permits, assistive technology must be able to modify values and text of elements, where the user can modify them.
Applies to: Software & platforms (AT interoperability)
Platform software must give users control over the platform accessibility features documented as intended for users.
Applies to: Platform software
Software must not disrupt documented platform accessibility features, except when the user asks it to.
Applies to: Platform software
Software that is not isolated from its platform must follow the user's platform preferences for measurement units, colour, contrast, font type, font size, and focus cursor, unless overridden by the user.
Applies to: Software
Authoring tools must meet clauses 11.8.2 to 11.8.5 to the extent that the output format supports the relevant accessibility information.
Applies to: Authoring tools
Authoring tools must enable and guide the production of content that conforms to clause 9 (web) or 10 (documents) as applicable.
Applies to: Authoring tools
Restructuring and re-coding transformations must preserve accessibility information where the output technology can hold it.
Applies to: Authoring tools
Where an authoring tool's checker detects a failure against clause 9 or 10, it must offer repair suggestions.
Applies to: Authoring tools
Where templates are offered, at least one accessible template supporting conformant content must be available and identified as such.
Applies to: Authoring tools
5 requirements shown
Product documentation must list and explain how to use the ICT's accessibility and compatibility features.
Applies to: Product documentation
Product documentation must be available in an accessible electronic format: web content conforming to clause 9, or a non-web document conforming to clause 10.
Applies to: Product documentation
Support services must be able to give information about the accessibility and compatibility features mentioned in the documentation.
Applies to: Support services
Support services must accommodate the communication needs of people with disabilities, directly or through a referral point.
Applies to: Support services
Documentation provided by support services must be available in an accessible electronic format conforming to clause 9 or clause 10.
Applies to: Support services
7 requirements shown
A text relay service must let text users and speech users interact by converting between the two modes of communication.
Applies to: Relay & emergency services
A sign relay service must let sign language users and speech users interact through interpretation.
Applies to: Relay & emergency services
A lip-reading relay service must let lip-readers and voice telephone users interact.
Applies to: Relay & emergency services
A captioned telephony service must caption the incoming side of a conversation for a deaf or hard of hearing user.
Applies to: Relay & emergency services
A speech-to-speech relay service must enable telephone use by people with speech impairments or limited cognition, language, or learning.
Applies to: Relay & emergency services
Where a system is specified for use with relay services, access to those relay services must not be blocked for outgoing or incoming voice, RTT, or video calls.
Applies to: Relay & emergency services
Where a system is specified for use with emergency services, access to those emergency services must not be blocked for outgoing or incoming voice, RTT, or video calls.
Applies to: Relay & emergency services
Websites & web apps
Chapter 9 (the WCAG 2.1 A/AA criteria) plus chapter 12 for documentation and support
Documents
Chapter 10 applies adapted WCAG criteria to PDFs, Office files, and e-books
Software & apps
Chapter 11, including assistive-technology interoperability and authoring tools
Hardware & terminals
Chapters 5 to 8: closed functionality, communication, video, and physical access
Version 3.2.1 (March 2021), the version cited in the Official Journal of the EU and therefore the one that carries a presumption of conformity for the European Accessibility Act and the Web Accessibility Directive today. A revised edition aligned to WCAG 2.2 (v4) is in the ETSI approval pipeline; until it is published and cited in the Official Journal, v3.2.1 remains the version to test and cite. Because WCAG 2.2 is backwards-compatible, work done against WCAG 2.2 AA already satisfies the WCAG 2.1 clauses here.
This checklist tracks 285 testable requirements across chapters 5 to 13, of which 50 in chapter 9 are the WCAG 2.1 Level A and AA success criteria applied to web pages. Chapters 10 (documents) and 11 (software) apply adapted versions of the same criteria, and chapters 5 to 8, 12, and 13 cover generic capabilities, communication, video, hardware, documentation, and relay services. The standard also contains 12 functional performance statements (chapter 4) and a number of void or not-applicable slots that keep the WCAG numbering aligned; those appear as information rows so the numbering makes sense.
No. The chapters apply by product type: a website is assessed against chapter 9 plus chapter 12 (documentation and support); downloadable documents add chapter 10; native software and mobile apps use chapter 11; hardware and self-service terminals bring in chapters 5 to 8. Use the scope buttons above the checklist to filter to your product type, and the progress bar recalculates for that scope.
EN 301 549 keeps its clause numbering aligned with WCAG so that, for example, clause 9.1.4.3 is always WCAG 1.4.3. Where a WCAG slot is Level AAA (such as 1.4.6) or a criterion does not apply in a context (such as Bypass Blocks for a single document), the standard marks the slot void rather than renumbering everything. This checklist shows void rows so auditors are not left wondering whether something is missing.
Yes, free and with no account. The Excel export contains every clause in your selected scope with its type, applicability, WCAG mapping, advisory flag, your status and notes, and the plain-language summary, plus a summary sheet. Your checkmarks and notes also auto-save to your browser's local storage between sessions on the same device.
No checklist is. EN 301 549 conformance gives a presumption of conformity with the European Accessibility Act's technical requirements, but the summaries here are plain-language explanations, not the normative text, and self-assessment against any checklist is only as good as the testing behind it. Use this to structure and track an assessment, verify findings against the published standard, and consider a professional audit for anything with legal exposure.