From June 28, 2025, all web and mobile applications available in the European Union must meet specific digital accessibility requirements. This is the result of implementing the European Accessibility Act (EAA). These regulations are significant for app owners and, consequently, for frontend developers.
In the article below, I will briefly describe what the new regulations are about and what a developer can expect when implementing solutions in web applications.
For more concrete examples and accessibility implementation solutions, you can read -> here.
What is the EAA?
The European Accessibility Act (EAA) is an EU directive designed to ensure equal access to digital products and services for people with disabilities. It applies to, among others, online stores, mobile apps, e-books, online banking, and transport services.
When does it take effect and with what consequences?
The new regulations come into effect on June 28, 2025. Failure to comply may result in penalties, including fines for missing an accessibility declaration or more serious sanctions for non-compliance with the requirements.
What does this mean for a frontend developer?
Business requirements will have to include additional technical requirements that the developer will be obligated to implement. These will comply with:
- WCAG 2.1 or 2.2 at level AA
- EN 301 549 standard
- UI/UX adjustments
WCAG 2.1 / 2.2 – Level AA
WCAG (Web Content Accessibility Guidelines) is a global standard developed by the W3C that describes how to design websites and web applications to be accessible to as wide an audience as possible, including people with disabilities.
– WCAG 2.1 has been in effect since June 2018.
– WCAG 2.2, published in 2023, extends 2.1 with new criteria (e.g., touch targets, keyboard navigation).
Level AA is required by the EAA — it is the middle level of rigor (there are also A — minimal, and AAA — maximum levels).
EN 301 549 Standard
This is a European technical standard defining ICT (Information and Communication Technology) accessibility requirements — including web, desktop, and mobile applications, terminals, and electronic documents. EN 301 549 is the official document based on which EU member states implement the EAA.
It extends requirements to, among others:
- Electronic documents (PDF, DOCX) — must be accessible
- Multimedia — required captions, audio description, or transcripts
It also describes application testing and accessibility evaluation criteria.
UI/UX Adjustments
Accessibility is not only about code but also about designing interfaces so that their functions can be used easily and intuitively. Below are some examples:
From a developer’s perspective:
- Avoid pitfalls: tabindex=”-1″ in wrong places, custom selects without keyboard support
- Use tools like Angular CDK A11y to manage focus, traps, and aria-live
- Add automated accessibility tests to CI/CD
From a UX/UI perspective:
- Buttons must be appropriately large, important in WCAG 2.2
- Text and labels must be unambiguous
- For colors: don’t rely solely on color (consider users with color blindness)
- Forms: clear error messages, field grouping (fieldset/legend), aria-describedby
Accessibility Declaration
An accessibility declaration is a public document informing users how well a website or application meets digital accessibility requirements. It’s like a „quality label” sewn onto clothing — showing what works, what doesn’t, and how to report issues.
This declaration is usually available at a dedicated URL, e.g.:
https://your-app.com/accessibility
Add a link in the footer or main menu of your application.
For mobile apps, the declaration link should be in the Google Play / App Store description or the app’s menu.
9 Example Aspects to Take Care Of
This is a basic list of solutions that should be included in the application code:
- HTML semantics and ARIA
Use correct tags (<header>, <nav>, <button>, <section>)
Add aria-label, aria-describedby, and roles - Keyboard accessibility
All actions must be accessible via Tab and Enter/Space
Use cdkTrapFocus, cdkMonitorFocus from Angular CDK - Contrast and colors
Text contrast: at least 4.5:1 (3:1 for large text)
Check with tools like WebAIM Contrast Checker - Visible focus
Focus style (:focus-visible) should be clear — don’t remove it!
Angular Material supports this by default - Alternative texts
All images must have alt attributes, SVG icons with aria-hidden=”true”, or alternative descriptions - Responsiveness and gesture accessibility
Don’t rely only on drag & drop
Provide alternatives for touch interactions (e.g., „left/right” buttons) - Handling app changes
After content changes, ensure:
- Focus is moved to the new area
- User notification (aria-live, cdkAriaLive)
- Focus is moved to the new area
- Form validation
Error messages must be understandable and linked to the specific field (aria-describedby)
Forms must work with keyboard and screen readers
- Automated accessibility testing
Add to CI: jest-axe, axe-core, pa11y, lighthouse-ci
Example Tools
- Angular CDK A11y: focus management, aria-live, interactions
- Lighthouse: accessibility analysis in the browser
- axe-core / jest-axe: CI/CD tests
- Angular Material: ready-made components compliant with WCAG
Summary
The new regulations are not just a legal requirement but also a real opportunity to improve product quality. Better accessibility means better user experience (UX), wider reach, improved SEO, and fewer problems for users. Given the circumstances, it’s worth addressing this early, which benefits both sides.