EAA Annex I — Accessibility requirements
A practical map of the EAA — section by section, with direct links to the official EU sources. We summarise the structure; the canonical text lives on EUR-Lex and ETSI.
Read the official sources
These are the canonical regulatory texts. We deep-link rather than reprint — the original is always more authoritative.
Section I — General Accessibility Requirements
Core requirements applicable to all products and services covered by the EAA.
I.1 · 4 clauses
Information about how to use the product or service
Provide accessibility information for the product or service in more than one sensory channel — in the product itself or via a website.
How to meet it
- Provide clear documentation of all accessibility features
- Describe compatibility with common assistive technologies (screen readers, switch devices, voice control)
- Make this information available in accessible formats (HTML, accessible PDF)
- Include accessibility information in user manuals and help sections
User interface and functionality design
The user interface — interaction, navigation, comprehension — must be operable through more than one sensory channel.
How to meet it
- Ensure UI elements are programmatically determinable (proper semantic HTML)
- Provide text alternatives for all non-text UI elements
- Support multiple input modalities (mouse, keyboard, touch, voice)
- Use ARIA roles and properties where native semantics are insufficient
Information, identification and operation functions
Information needed to operate the product, identify elements and perform functions must be perceivable and operable regardless of sensory capability.
How to meet it
- Ensure all interactive elements have accessible names
- Provide visual and programmatic identification for all controls
- Use consistent identification across pages and states
- Ensure status messages are communicated to assistive technologies
Perceivable information presentation
Information must be presented in perceivable ways — text alternatives for non-text content, and content that can be presented in different ways without losing meaning.
How to meet it
- Provide text alternatives for images, icons, and media
- Ensure sufficient colour contrast (4.5:1 for text, 3:1 for large text)
- Do not rely on colour alone to convey information
- Ensure content is meaningful when linearised or restyled
I.2 · 14 clauses
Communication services accessibility
Where the service provides communication functions, support real-time text, voice and video in accessible formats.
How to meet it
- Support real-time text (RTT) alongside voice communication
- Provide captioning for video calls where technically feasible
- Ensure communication features work with assistive technologies
- Offer alternative communication channels (text, voice, video)
Information about accessibility features
Publish information about the accessibility features of the service and its compatibility with assistive technologies, in accessible formats.
How to meet it
- Publish an accessibility statement describing features and known limitations
- Document supported assistive technologies and browsers
- Provide contact information for accessibility-related inquiries
- Keep accessibility documentation up to date with each release
Text content readability and contrast
Text must allow alternative rendering: adjustable font size, sufficient contrast, configurable spacing.
How to meet it
- Maintain minimum contrast ratio of 4.5:1 for normal text, 3:1 for large text
- Allow text to be resized up to 200% without loss of content or functionality
- Support user-defined text spacing (line height, letter spacing, word spacing)
- Use relative units (em, rem, %) instead of fixed pixel sizes for text
Content resizing and reflow
Content must reflow to fit the viewport without horizontal scrolling at standard zoom; users must be able to resize without loss of information.
How to meet it
- Ensure content reflows at 320px viewport width (equivalent to 400% zoom on 1280px)
- Avoid horizontal scrolling for vertical-scrolling content
- Use responsive design techniques (CSS Grid, Flexbox)
- Test with browser zoom at 200% and 400%
Alternative text for non-text content
Non-text content (images, charts, audio, video) must have text alternatives that serve an equivalent purpose.
How to meet it
- Provide alt text for all informative images
- Use empty alt="" for decorative images
- Provide text transcripts for audio content
- Provide captions for video content and audio descriptions where needed
Audio and video alternatives
Audio and video must have synchronised alternatives: captions for audio, audio descriptions for video, transcripts for pre-recorded media.
How to meet it
- Provide synchronised captions for all pre-recorded video with audio
- Provide audio descriptions for pre-recorded video where visual information is essential
- Provide transcripts for pre-recorded audio-only content
- Ensure captions are accurate, synchronised, and include speaker identification
Keyboard operability
All functionality must be operable via keyboard without specific keystroke timings; no keyboard traps.
How to meet it
- Ensure all interactive elements are reachable and operable via keyboard (Tab, Enter, Space, Arrow keys)
- Provide visible focus indicators for all focusable elements
- Ensure no keyboard traps exist — users can always navigate away
- Support standard keyboard patterns for custom widgets (ARIA Authoring Practices)
Adjustable timing
Where time limits exist, users must be able to turn off, adjust or extend them — unless the time limit is essential.
How to meet it
- Allow users to turn off, adjust, or extend any time limits
- Warn users before time expires and allow extension
- Avoid automatic content updates that cannot be paused or controlled
- Exceptions: real-time events, essential time limits (auctions, exams)
Restrictions on flashing content
Content must not flash more than three times per second unless it is below the general flash and red flash thresholds.
How to meet it
- Avoid content that flashes more than 3 times per second
- If flashing is necessary, ensure it falls below the general flash threshold
- Provide warnings before content with potential seizure triggers
- Allow users to disable animations and motion effects
Navigation mechanisms
Navigation must be consistent and predictable. Multiple ways to find content. Link purpose must be determinable.
How to meet it
- Provide skip navigation links to bypass repeated content
- Use descriptive page titles that identify the topic or purpose
- Ensure focus order follows a logical, meaningful sequence
- Provide multiple navigation mechanisms (menu, search, sitemap)
- Use descriptive link text that makes sense out of context
Language identification
The default human language of the page and any language changes within content must be programmatically determinable.
How to meet it
- Set the lang attribute on the <html> element
- Mark language changes within content using the lang attribute
- Use valid IETF BCP 47 language tags (e.g., "en", "de", "fr")
- Ensure assistive technologies can detect and switch language pronunciation
Predictable behaviour
Components must behave predictably. Focus must not trigger unexpected context changes. Similar components must be identified consistently.
How to meet it
- Do not change context on focus (no unexpected navigation or popups)
- Do not change context on input unless the user is advised beforehand
- Use consistent navigation and labelling across pages
- Identify similar components consistently throughout the service
Input assistance and error handling
Input errors must be detected and described. Labels and instructions must be provided. Error suggestions and prevention for legal or financial data.
How to meet it
- Provide visible labels for all form inputs
- Identify input errors clearly and provide text descriptions
- Suggest corrections when input errors are detected
- Allow users to review, correct, and confirm submissions with legal/financial consequences
- Use autocomplete attributes for common input fields (name, email, address)
Compatibility with assistive technologies
Content must be compatible with current and future assistive technologies. Name, role and value of UI components must be programmatically determinable.
How to meet it
- Use valid, well-formed HTML markup
- Ensure all UI components have accessible names and roles
- Expose state and property changes to the accessibility API
- Test with screen readers (NVDA, JAWS, VoiceOver) and other assistive technologies
Section III — Web-Specific Requirements
Additional requirements for websites and web applications under the EAA.
WCAG 2.1 Level AA web conformance
Websites and web applications must conform to WCAG 2.1 Level AA as referenced by EN 301 549 v3.2.1.
How to meet it
- Conduct a full WCAG 2.1 AA audit using industry-standard automated tools and manual testing
- Address all Level A and Level AA success criteria
- Test with multiple browsers, screen readers, and input devices
- Establish a remediation plan for any non-conformances
Web content accessibility
Web content must be perceivable, operable, understandable and robust across all content types — text, media, forms, dynamic content.
How to meet it
- Ensure all page content is accessible to assistive technologies
- Provide alternatives for complex content (charts, infographics, data tables)
- Make dynamic content updates (AJAX, SPA navigation) accessible
- Test single-page application navigation with screen readers
Mobile web accessibility
Mobile-delivered web content must meet the same accessibility requirements. Touch targets, gestures and responsive behaviour must be accessible.
How to meet it
- Ensure touch targets are at least 44x44 CSS pixels
- Support both portrait and landscape orientations
- Provide alternatives to complex gestures (pinch, swipe, multi-finger)
- Test with mobile screen readers (VoiceOver on iOS, TalkBack on Android)
Section IV — Sector-Specific Requirements
Requirements for specific service sectors — electronic communications, audiovisual media, transport, banking, e-books, e-commerce.
E-commerce accessibility
E-commerce services must ensure the entire purchasing journey is accessible — browsing, selection, checkout, payment, confirmation.
How to meet it
- Ensure product listings, filters, and sorting are keyboard accessible
- Provide accessible product descriptions and image alternatives
- Make the entire checkout flow operable with assistive technologies
- Ensure payment forms have proper labels and error handling
Banking and financial services accessibility
Banking and financial services must make account management, transactions and financial information accessible — without security mechanisms creating barriers.
How to meet it
- Ensure authentication mechanisms are accessible (CAPTCHA alternatives, biometric options)
- Make transaction flows fully keyboard and screen reader operable
- Provide accessible account statements and financial documents
- Ensure security features (2FA, session timeouts) accommodate users with disabilities
Transport services accessibility
Transport ticketing and traveller information services must be accessible — booking, real-time information, self-service terminals.
How to meet it
- Ensure booking and ticket purchase flows are fully accessible
- Provide real-time travel information in accessible formats
- Make self-service terminals accessible (or provide accessible alternatives)
- Ensure mobile apps for transport services meet accessibility requirements
Electronic communications services accessibility
Electronic communications services must support real-time text, total conversation where feasible, and accessible customer interfaces — including relay services.
How to meet it
- Support real-time text (RTT) in voice communication
- Provide total conversation (voice + text + video) where feasible
- Ensure customer self-service portals are accessible
- Make service configuration and account management accessible
Audio-visual media services accessibility
Audio-visual media services must provide access through captions, audio descriptions, and accessible electronic programme guides.
How to meet it
- Provide captions/subtitles for all audio-visual content
- Provide audio descriptions for visual-only content
- Ensure media players are keyboard accessible
- Make electronic programme guides (EPGs) accessible
E-book and digital publishing accessibility
E-books and digital publications must support text-to-speech, adjustable display, accessible navigation, and DRM that does not block accessibility.
How to meet it
- Ensure e-books support text-to-speech and screen reader navigation
- Allow font size, spacing, and colour adjustments
- Provide alternative descriptions for images and charts
- Ensure DRM does not block assistive technology access
Electronic identification services (eIDAS-related)
Note: eID is governed by Regulation (EU) 910/2014 and 2024/1183 (eIDAS), not EAA Annex I. It matters here because authentication often gates EAA-covered services.
How to meet it
- Ensure login and authentication flows are accessible
- Provide alternatives to visual CAPTCHAs
- Make multi-factor authentication accessible (not reliant on a single sensory channel)
- Ensure digital signature processes are operable with assistive technologies
Annex V — Accessibility declaration template
Mandatory format of the EAA accessibility declaration that service providers must publish (separate from Annex I).
Provider identification (Annex V)
The accessibility declaration must include the name and address of the economic operator (manufacturer, importer, distributor or service provider).
How to meet it
- Include full legal name of the organisation
- Include registered business address
- Include contact details for accessibility inquiries
- For importers/distributors, identify the manufacturer as well
Product or service identification (Annex V)
The declaration must identify the product or service — model, type, batch, serial number or any other element allowing identification.
How to meet it
- Clearly identify the product or service covered by the declaration
- Include version numbers for software/web services
- Specify the scope (e.g., which URLs, apps, or product models)
- Include the date of the assessment or declaration
Applicable harmonised standards (Annex V)
The declaration must reference the harmonised standards (EN 301 549) or technical specifications used to assess conformity.
How to meet it
- Reference EN 301 549 v3.2.1 (or later) as the harmonised standard
- Reference WCAG 2.1 Level AA as the underlying technical standard
- List any additional standards applied (e.g., ATAG, UAAG)
- If no harmonised standard was used, describe the technical specifications applied
Article 14 — Exemptions (disproportionate burden + microenterprise)
Criteria for limiting accessibility requirements under Article 14 EAA, plus the microenterprise exemption from Article 4(5).
Disproportionate burden assessment (Article 14)
Accessibility requirements may be limited where compliance imposes a disproportionate burden — assessed by net cost, organisation size and benefit to people with disabilities.
How to meet it
- Document the specific requirements claimed as disproportionate
- Provide cost-benefit analysis for each claimed exemption
- Reassess disproportionate burden claims when products/services are updated
- The exemption does not apply to the obligation to produce an accessibility declaration
Microenterprise exemption (Article 4(5))
Microenterprises providing services (fewer than 10 employees AND turnover or balance sheet ≤ €2 million) are exempt from the service accessibility requirements.
How to meet it
- Exemption applies only to services, not products
- Both criteria must be met: fewer than 10 employees AND turnover/balance sheet under EUR 2 million
- Microenterprises are still encouraged to voluntarily comply
- If the enterprise grows beyond the thresholds, the exemption no longer applies
What no automated tool can check
Automated testing finds only part of the barriers WCAG describes. These checks need a person; do them before you publish an accessibility statement.
-
Keyboard only
Put the mouse away and reach every link, button, menu and form field with Tab, Shift+Tab, Enter, Space and the arrow keys. Focus must never get stuck, must follow a logical order and must always be visible.
-
Screen reader
Listen to the page with NVDA or JAWS (Windows), VoiceOver (macOS, iOS) or TalkBack (Android). Headings, landmarks, buttons and form fields should be announced with names that make sense.
-
Quality of text alternatives
Automation can tell that alternative text exists, not whether it is right. Check that each description says what the image shows or does, and that decorative images are silent.
-
Captions, transcripts and audio description
Watch every video with the sound off: captions must be accurate and in sync. Audio needs a transcript, and important visual information needs audio description or a text alternative.
-
Reading and focus order
The order in which a screen reader reads the page and the keyboard moves through it must match the visual order and the meaning of the content.
-
Zoom, reflow and text spacing
Zoom the browser to 200% and to 400% (a 320 px wide window). No text or function may be lost, nothing may need horizontal scrolling, and increased text spacing must not cut off content.
-
Links, labels and error messages
Every link, button and form label says what it does in its context. Error messages name the field, explain what went wrong and say how to fix it.
-
Colour and sensory cues
Information is never conveyed by colour, shape, size or position alone. Check contrast on images of text, gradients, and hover and focus states, which automated tools cannot measure reliably.
-
Motion, timing and flashing
Carousels, animations and auto-updating content can be paused or stopped, time limits can be turned off or extended, and nothing flashes more than three times per second.
-
Predictable behaviour
Focusing or filling in a field never changes the page or opens a new window unexpectedly. Navigation and repeated components appear in the same place and work the same way on every page.
-
Accessibility statement and feedback
Publish an accessibility statement that lists known limitations and gives users a working way to report barriers and get a reply.
About this audit framework
This is RankProof’s audit scoring tree, derived from Directive (EU) 2019/882 (European Accessibility Act) — Annex I (technical requirements), Annex V (declaration format) and Article 14 (exemptions) — combined with the harmonised standard EN 301 549 v3.2.1 and WCAG 2.1 Level AA success criteria. Section labels indicate the source within the Directive. The official numbering is preserved on each clause page with a direct link to the canonical EUR-Lex text.
How does your site measure up?
Run the free accessibility audit: it tests your page against the WCAG 2.1 AA checks behind these clauses and lists what to fix.