A Developer’s Checklist — SitePoint

This guide provides a practical, step-by-step checklist to help developers audit, fix, and future-proof their digital products to comply with the European Accessibility Act (EAA). 

Key Takeaways

• The EAA requires businesses operating in the EU to make their websites, apps, and digital interfaces accessible under WCAG 2.1 Level AA standards.
• It applies to companies with 10+ employees and €2M+ annual revenue, including non-EU businesses selling to EU customers.
• The compliance deadline is June 28, 2025. Failure to comply can result in fines (up to €50K—€100K), restricted market access, and even jail sentences.
• Developers must integrate accessibility into workflows early, automate testing, and ensure proper keyboard navigation, semantic HTML, ARIA usage, and assistive tech compatibility.

A Quick Overview of the European Accessibility Act

The European Accessibility Act (EAA) is a landmark regulation designed to improve accessibility across digital and physical products and services in the European Union (EU). It applies to organizations with more than 10 employees and an annual turnover exceeding €2 million, including businesses headquartered outside the EU selling to European customers. 

Compliance is mandatory by June 28, 2025, and failing to meet accessibility standards could lead to fines of up to €50K – €100K, market restrictions, or even prison sentences (in Ireland). 

The key objectives of the EAA are to:

• Remove barriers that prevent people with disabilities from accessing digital services and products.
• Standardize accessibility requirements across the EU, reducing fragmentation across member states.
• Enhance business opportunities by creating a unified, legally binding accessibility framework.

Industries and digital services affected

If your business falls into any of the following categories, the EAA directly applies to you:

• Financial services – Online banking platforms, ATMs, payment terminals.
• E-commerce – Online stores, checkout systems, digital product interfaces.
• Telecommunications – Customer self-service portals, VoIP applications.
• Transport & travel – Digital ticketing, scheduling, real-time passenger info systems.
• Publishing & media – E-books, streaming platforms, digital newspapers.

Certain businesses and services may qualify for “limited exemptions”, but these require proper justification:

• Microenterprises – Businesses with fewer than 10 employees and less than €2 million in revenue are not required to comply.
• Undue Burden – If achieving accessibility imposes disproportionate costs or requires fundamental changes to a product or service, companies can request an exemption. However, they must demonstrate financial or technical hardship in a formal assessment.
• Legacy Products – Digital services introduced before June 2025 have until 2030 to meet EAA requirements.

However, even if your company qualifies for an exemption, you must still provide an accessibility statement outlining its compliance efforts and any remaining barriers.

The Developer’s EAA Checklist

The EAA follows WCAG 2.1 Level AA and EN 301 549, ensuring digital products are perceivable, operable, understandable, and robust. The checklist below outlines practical steps to integrate accessibility into your workflow to meet EAA standards without last-minute compliance scrambles.

1. Start with a thorough accessibility audit

Run a full audit to identify high-impact issues that block users from navigating or interacting with your content. Start with automated tools like WAVE, axe DevTools, ARIA by Equally AI, or Lighthouse to find common accessibility issues like missing alt text, poor color contrast, and form fields without labels. However, note that automated scans can only detect about 30% of WCAG errors, so you must follow up with manual testing, focusing on:

• Keyboard-only navigation – Can users reach and interact with everything using Tab, Shift+Tab, Enter, and Space?
• Screen reader testing – Use NVDA (Windows) or VoiceOver (Mac) to check if the content is read logically.
• Focus management – Do modals and pop-ups correctly trap focus? Does focus return to the right place when elements close?

This two-step process—automated scans plus manual testing—provides a clear baseline for fixing accessibility issues before they become compliance risks.

2. Ensure keyboard accessibility

People using screen readers or alternative input devices often rely on keyboard-only navigation. As such, verify that all interactive elements (links, buttons, form controls) are accessible via Tab or Shift+Tab in a logical order. Also, include visible focus indicators—an outline or color change that lets users see exactly where they are on the page. Modals and pop-ups need special care: when one opens, move focus into it automatically and return focus to the trigger element once it’s closed. This prevents users from getting trapped or lost.

3. Use semantic HTML first, ARIA only when needed

One of the fastest ways to improve accessibility is to rely on proper HTML structure. It’s important to use elements for their intended purposes so that assistive technologies can interpret them correctly. For example use <header>, <main>, <section>, <footer> for layout; <h1> through <h6> for headings; <ul> and <ol> for lists, <label> for form fields, etc. 

ARIA (Accessible Rich Internet Applications) should only be used when necessary. Native HTML elements already support accessibility out of the box, so ARIA is only needed for complex interactions like live regions, custom dropdowns, or modals. Overusing ARIA can confuse screen readers, so focus on HTML’s built-in semantics first, then enhance with ARIA if necessary.

4. Provide meaningful text alternatives for media

Images, icons, and media elements must include descriptive text to give context when a user can’t see the screen. When dealing with purely decorative graphics, an empty alt attribute (alt="") suffices, but any image conveying crucial information should have a concise, meaningful description. Videos and audio content benefit from transcripts or captions so users with hearing impairments can still follow along. 

5. Maintain adequate color contrast ratios

Many users have color vision deficiencies or low vision, so a strong color contrast makes text and interactive elements easier to see. Aim for at least a 4.5:1 ratio for normal text and 3:1 for larger text, per WCAG guidelines. Tools like Contrast Checker or your browser’s built-in dev tools can quickly measure contrast levels. Remember that contrast extends beyond text: buttons, icons, and form elements must be clearly distinguishable from their backgrounds. 

6. Think ‘mobile and responsive’ 

Cramped layouts and small touch targets on mobile devices can frustrate users. Ensure text reflows properly when someone zooms in, and avoid horizontal scrolling that forces users to swipe left and right. Also, larger touch targets—around 44×44 pixels—help people with motor impairments or anyone on a smaller touchscreen. Bear in mind that responsive designs that adapt well to different screen sizes not only improve accessibility but create a seamless user experience overall. 

7. Document and continuously improve workflows

Accessibility is an ongoing process, and you must treat it as such. Keep a running list of known issues in your project management tool or version control system, documenting what’s been fixed and what still needs work. If possible, integrate automated accessibility checks into your CI/CD pipeline so you catch regressions whenever new code is deployed. Over time, this approach builds a culture of accessibility within your team, ensuring each update or new feature meets the EAA’s requirements from the start.

8. Publish an accessibility statement

Organizations covered by the EAA must publish an accessibility statement detailing their compliance status. This should outline:

• The current accessibility standard your product meets (e.g., WCAG 2.1 AA).
• Any known limitations or areas where the platform may not fully comply.
• Ongoing improvements and plans for addressing the gaps outlined.
• A contact method for users to report accessibility issues or request alternative formats.

Keeping this statement updated not only fulfills a legal requirement but also demonstrates transparency and commitment to accessibility. It helps users understand your approach, sets clear expectations, and ensures compliance is an ongoing priority.

Third-party tools like payment gateways, booking systems, and embedded widgets often introduce accessibility issues beyond your direct control. Before integrating them, check whether the vendor provides an accessibility statement or implementation guidelines.

If documentation is lacking, test the component yourself—look for keyboard accessibility, proper focus management, and screen reader support. However, if the third-party service remains inaccessible, I strongly recommend considering alternative providers or providing a clear workaround to ensure all users can complete essential tasks.

Why the EAA Matters for Developers

The EAA makes accessibility compliance a requirement for businesses operating in the EU, and developers play a direct role in ensuring that digital products meet these standards. Beyond compliance, there are strong business and competitive reasons to take accessibility seriously.

Legal & financial issues

The EAA mandates that penalties for non-compliance be “effective, proportionate, and dissuasive.” Depending on the country, this can mean fines of up to €100K–€500K, restricted EU market access, and even jail sentences. When the company faces penalties, the responsibility to fix compliance issues often falls on development teams—usually under intense pressure and tight deadlines. 

This translates to emergency sprints to retrofit accessibility into existing code, driving up costs and diverting resources from other projects. Worse, if the company loses contracts or market access, it could mean downsizing or reduced project funding, directly impacting developers’ workloads and job security.

Business risks

Ignoring accessibility cuts off a sizable audience (over 100 million people in the EU with disabilities), limiting revenue and exposing companies to damaged public perception. By contrast, accessible products lead to cleaner code, better UX, and stronger customer trust, giving businesses a competitive edge.

Companies that invest in accessibility are more likely to secure a broader client base, foster loyalty, and project a positive image—all of which benefit developers by securing long-term stability and meaningful projects.

Future-proofing

Accessibility laws are evolving worldwide, and the EAA itself may expand its scope over time, raising the stakes for companies that operate or plan to expand internationally.

Embedding accessibility into development workflows reduces the likelihood of repeated retrofits when new regulations emerge. It also ensures products are ready for technological advances—from voice interfaces to advanced AI—ensuring products remain inclusive and competitive as the digital landscape changes. 

Conclusion

Building accessible products isn’t just about compliance—it’s about creating software that works for everyone, including users who rely on assistive technology. The EAA just puts a legal deadline on something that should already be part of good development. The truth is—the earlier you integrate accessibility, the easier it is to manage. 

Waiting until the deadline means rushed patches, messy code, and unnecessary stress. By making accessibility part of your process now, you’re not just checking a legal box; you build a better, more future-proof software that works for everyone, including yourself.