European Accessibility Act (EAA) is an EU directive designed to improve the accessibility of products and services for people with disabilities. It establishes clear accessibility requirements that apply to a wide range of digital and physical products and services offered in the EU.
Purpose:
To ensure that services and products are accessible to all users, including people with disabilities, covering public bodies and private businesses operating in the EU.
Key requirements
When implementing websites or applications, the following are some of the core requirements to consider:
- Accessibility of your websites and mobile applications
- Usability of your CMS and eCommerce solution for people with disabilities
- Compliance with the latest WCAG 2.2 at Level AA
The WCAG standard is maintained by the World Wide Web Consortium (W3C) and is considered the baseline for EAA digital accessibility compliance.
DynamicWeb and Swift EAA Compliance
DynamicWeb solutions can be implemented to meet WCAG 2.2 Level AA requirements:
- Websites built with DynamicWeb must implement WCAG 2.2 AA features, including semantic markup, ARIA roles, keyboard navigation, and proper use of alt texts.
- Content types, templates, and modules must be configured to support accessibility attributes (alt, title, aria-label, roles, headings, etc.).
Swift (DynamicWeb’s default frontend) is designed to be WCAG 2.2 AA-compliant by default:
- Swift uses semantic HTML and ARIA attributes out of the box
- Around 99% of common accessibility requirements are supported by default
- Content authors must use the features correctly to achieve full compliance
- Example:
- ❌ Three buttons all labeled “Read more” → Not accessible (unclear purpose)
- ✅ Buttons labeled “Read more about PIM”, “Read more about Commerce”, “Read more about Integration” → Accessible (clear purpose)
- Example:
Technical vs. Editorial WCAG Compliance
Achieving true accessibility requires addressing both technical and editorial compliance.
Technical WCAG Compliance
This is what the platform/framework provides and developers implement:
- Semantic HTML structure (
<header>,<nav>,<main>,<footer>) - Keyboard navigability and visible focus states
- ARIA labels and roles
- Text alternatives (alt text on images)
- Form labeling and error handling
- Screen reader compatibility
This is the part that DynamicWeb and Swift handle out of the box, assuming correct implementation.
Editorial WCAG Compliance
This relates to how content is authored:
- Clear and descriptive link and button texts (avoid “Read more” everywhere)
- Meaningful headings with logical hierarchy
- Sufficient text contrast and color choices
- Avoiding information conveyed by color alone
- Providing transcripts/captions for multimedia
- Writing in plain, understandable language
This is the responsibility of editors, marketers, and content authors working in the CMS.
Example of Good vs. Bad Content
Bad content example:
<h2>Learn more</h2>
<p>Click <a href="#">here</a> to read about our product.</p>
<img src="product.jpg">
<button>Read more</button>
Good content example:
<h2>Explore our PIM solution</h2>
<p>Read more about our <a href="/pim">Product Information Management platform</a>.</p>
<img src="product.jpg" alt="Screenshot of the PIM dashboard">
<button>Learn more about PIM</button>
Example of Bad Colors
| Text Color | Background | Contrast Ratio | Status |
|---|---|---|---|
#999999 |
#FFFFFF |
3.0:1 | ❌ Fail |
#666666 |
#FFFFFF |
5.0:1 | ✅ Pass |
#FFFFFF |
#007ACC |
8.6:1 | ✅ Pass |
Best practice: Maintain a minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text (18pt+).
WCAG 2.2 Compliance Checklist
| WCAG 2.2 SC | Requirement | Responsibility | Notes |
|---|---|---|---|
| 1.1.1 | Provide alt text for all meaningful images | Editor | Mandatory for product/media images |
| 1.3.1 | Use semantic HTML (<header>, <nav>, <main>, <footer>) |
Developer | Built into Swift templates |
| 1.3.2 | Content should read in a logical order when read by screen readers | Developer | Avoid layout hacks (tables/div soup) |
| 1.3.5 | Inputs with known purpose should have autocomplete attributes |
Developer | Especially forms (name, email, etc.) |
| 1.4.1 | Don’t rely on color alone to convey meaning | Editor | Add icons, labels or text cues |
| 1.4.3 | Maintain 4.5:1 contrast for normal text | Developer | Validate using axe or Google Lighthouse |
| 1.4.11 | Ensure contrast of icons, form borders, focus states (3:1) | Developer | Often missed in custom components |
| 2.1.1 | All functionality available via keyboard | Developer | Tab order and focus management |
| 2.1.2 | Users can tab into and out of any component | Developer | Especially modal dialogs |
| 2.4.1 | Provide skip links or other bypass mechanisms | Developer | Swift includes skip links by default |
| 2.4.3 | Logical tab order | Developer | Defined by DOM structure |
| 2.4.4 | Links must be descriptive | Editor | Avoid repeated “Read more” links |
| 2.4.6 | Use clear, descriptive headings and labels | Editor | Helps orientation for all users |
| 2.4.7 | Visible focus indicators for all interactive elements | Developer | Swift includes default focus styles |
| 3.1.5 | Use clear and simple language | Editor | Avoid jargon, explain terms |
| 3.2.2 | Changing input should not trigger unexpected context changes | Developer | No auto-submits on blur |
| 3.3.1 | Clearly describe input errors | Editor | Don’t use just “invalid input” |
| 3.3.2 | Provide clear labels/instructions for all fields | Developer | Use <label> correctly |
| 3.3.3 | Suggest how to correct errors | Editor | “Use at least 8 characters” etc. |
| 3.3.4 | Confirm important submissions | Developer | E.g. confirm purchases |
| 4.1.2 | All UI components must expose accessible name, role, and state | Developer | Use ARIA for custom controls |
| 4.1.3 | Important changes announced to screen readers | Developer | Use aria-live for form results, carts, etc. |
Other EAA Requirements
- Product Design: Physical products (smartphones, ATMs, POS terminals) must be accessible
- Service Accessibility: Services like banking and transportation apps must be accessible
- Cross-Border Compliance: Unified rules across the EU simplify cross-border trade
- Staff Training: Regular training on accessibility best practices
- Audits & Reviews: Regular accessibility audits and reports
Accessibility in the Website Lifecycle
Planning
Include accessibility as a core requirement. Define user stories for people with disabilities.
Design
Involve accessibility experts and test designs with assistive technologies.
Development
Use semantic HTML and ARIA attributes. Build accessibility in from the start.
Testing
Use automated tools (like axe, Google Lighthouse) and manual tests with users using assistive tech (JAWS, NVDA, ZoomText).
Maintenance
Review accessibility monthly or quarterly, especially when new features/content are added.