Mastering EAA Compliance with a Professional WCAG Accessibility Audit

Reading Time: 11 minutes

Change is always a good thing. Even though complying with the European Accessibility Act is a lot of work, the reward is well worth it. You’ll broaden your potential customer pool by 1.3 billion people. You’ll upgrade your brand reputation. You’ll improve your product’s UX for all users. And you’ll advance your revenue and save money on possible non-adherence fines, which can go up to €500,000 per violation.

So, think of EAA compliance as not something that you have to do, but something that you should do. Because that something will give your project an impressive number of advantages. And the first step in obtaining those advantages is holding a WCAG accessibility audit.

What Are EAA, EN 301 549, & WCAG 2.1 AA Requirements?

EAA is the law. EN 301 549 is the technical specification you must follow to comply with that law. And WCAG 2.1 accessibility standards are global guidelines designed to help companies secure accessibility. There’s a lot of info on this topic right now. And it can get confusing. So, first, let’s have a brief recap of business-relevant points.

EAA is a legally binding directive. If you sell products or services in the EU, you must comply with it. There is an exemption for micro enterprises, however. If you have fewer than 10 people on your team or make under €2 million in annual revenue, there’s no obligation for you to follow EAA.

EN 301 549 is the standard provided by EAA. It describes technical details all ICT products and software need to follow, explaining exactly what to do. This standard heavily overlaps with WCAG 2.1 accessibility guidelines. But it also includes extra points, such as requirements for:

Documentation and support services, e.g., support channels (phone, chat, documentation) must be accessible.
Biometric authentication alternatives, i.e., if a product uses facial, voice, or fingerprint recognition, it must offer substitutes.
ICT with closed functionality, e.g., products that can’t install assistive tech must have built-in accessibility mechanisms like speech-based interactions or magnification.

Web content accessibility guidelines (WCAG) 2.1 are an international standard that explains how to make web content accessible. It’s basically one big checklist for your team to work with. WCAG has three conformance levels: A (essential), AA (recommended), and AAA (ideal).

For level A, you must meet 30 success criteria described in WCAG 2.1 requirements.
For level AA, you must meet 50 success criteria.
And for level AAA, you must meet 78 success criteria.

The third level is mostly optional. So, QA accessibility testing needs to aim for level AA, as stated in the Accessibility Act.

Since the WCAG 2.1 compliance checklist is the bulk of the directive, we’ll focus on it further.

WCAG 2.1 Accessibility Guidelines Overview

WCAG 2.1 AA accessibility standards were developed thanks to global cooperation by the World Wide Web Consortium. The very first edition was released over two decades ago. So, WCAG is mature, universal, and tech-specific. That’s why they’re used all over the world. That’s why EAA included them in the Act. And that’s why your accessibility testing services need to comply with them first.

Here’s what you should know about WCAG 2.1 accessibility.

What Are the POUR Principles in WCAG 2.1 Level AA Requirements?

The POUR principles are characteristics an accessible product needs to have.

Perceivable. Whatever sense a person relies on, they must be able to perceive and use the content. That means adding captions, text descriptions, proper contrast, etc., to your project so that people with disabilities can enjoy it.
Operable. Whatever mode of interaction a person relies on, they must be able to easily navigate the content. That means adding alternative input methods, avoiding action traps or blockers, etc.
Understandable. A person must be able to “figure out” your product. That means readable content, predictable forms, clear error messages, and consistent behavior. Users need to clearly understand how to work with your app and not guess what to do.
Robust. A person must be able to interact with your product, no matter what environments they use. That means securing compatibility with different browsers, OSs, and their versions, using universal formats and valid code, etc.

These principles can be used as a guide on their own. But, of course, having a straightforward WCAG 2.1 guidelines checklist is much easier.

What Are the Main WCAG 2.1 AA Accessibility Requirements?

Key WCAG 2.1 AA accessibility standards mostly reference content alternatives, navigation, layout, and user control. The WCAG page goes into great detail so you can properly cover all success criteria. But it might look overwhelming if you’re just starting out.

So, we’ll take a look at the WCAG 2.1 AA accessibility guidelines summary.

Provide text alternatives for all non-text content (images, icons, charts, audio, video).
Include captions for video, transcripts for audio, and audio descriptions for video.
Ensure sufficient color contrast, allow text resizing, support spacing adjustments, and avoid images of text unless essential.
Content should reflow for small screens, work in both portrait and landscape, and avoid layout issues.
Give users control over time-limited or moving content, and avoid flashing content that could trigger seizures.
Tooltips, popovers, and hover content should remain visible, be dismissible, and not disappear too quickly.
All functionality must be accessible via keyboard, with a visible focus indicator, logical tab order, and multiple ways to navigate.
Use consistent labels, headings, and link text. Avoid actions that trap users or behave unexpectedly.
Ensure all actions can be performed without complex gestures or device motion.
Use clear language, indicate language changes, and maintain consistent navigation and labels.
Provide clear instructions, helpful error messages, and mechanisms to prevent or correct mistakes, especially for critical tasks.
Avoid unexpected changes in context, such as auto-refreshes or sudden focus shifts.
Use valid code, proper roles, and ARIA attributes so content works reliably with current and future tools.

It’s still quite a lot. We know. So, how do you figure out what success criteria to start with?

Where to Start with WCAG 2.1 Level AA Accessibility Standards?

We’d recommend covering aspects that usually suffer the most first. WebAIM study found that the majority of websites have the following issues:

Low contrast text.
Missing alt text.
Missing form input labels.
Empty links.
Empty buttons.

These same problems have stayed at the top for over five years now. That’s why it’s worth addressing them early. However, your starting point can be different. Maybe you don’t need alt text at all. Or maybe your entire product is in black and white (high contrast). So, here’s how you can prioritize WCAG 2.1 accessibility checks.

Start with the criteria that affect the most people or create the biggest barriers. For example, unlabeled form fields block screen reader users completely.
Some regulations may mandate certain accessibility features first (e.g., captions for public service videos). Check industry-specific rules or contracts.
Identify critical user flows (checkout, registration, search, etc.). Prioritize criteria that affect these flows, since they impact business outcomes and user satisfaction the most.
Fixes that are quick, easy, and broad-reaching should come early to build momentum (e.g., adding missing alt text or correcting headings).
Some criteria require foundational changes (e.g., improving HTML semantics or ARIA roles) before other fixes. Address them first, so later fixes are easier and less likely to break. For instance, if a user doesn’t know what to input in a field, an error message wouldn’t help them.

But this is not where your EAA adherence actually starts. The very first thing on the official WCAG 2.1 compliance checklist is an audit.

What Is a WCAG 2.1 AA Level Web Accessibility Audit?

A WCAG accessibility audit is a review of a product that checks whether it meets the guides’ standards. With it, you can determine your app’s present accessibility state and map out further actions. Typically, you’d run a complete audit once or twice a year. But it should be supplemented with smaller interim checks as well as pre-release evaluations.

Because digital products evolve quickly, you don’t want to leave accessibility to chance. So, these compliance investigations aren’t redundant. They’re necessary to secure continuous adherence to the EAA. Plus, we can pretty much guarantee that new amendments and rules will appear. You’ll have to keep up with any changes.

Why Do You Need a WCAG 2.1 Accessibility Audit?

An WCAG audit lets you objectively identify accessibility issues, prioritize the most critical fixes, and provide a clear, actionable plan for improvement. It isn’t a quick scan. Automation testing services alone wouldn’t be enough here. They aren’t capable of evaluating meaningful alt text or logical reading order. And they can only locate around 30% of errors.

An expert-led WCAG accessibility audit, on the other hand, allows you to:

Systematically check your product against WCAG criteria rather than relying on assumptions.
Uncover problems that might be invisible to your team due to complexity, lack of expertise, limited resources, etc.
Classify issues by severity, impact, and dependency, helping you focus on what matters most first.
Provide a baseline report, so future updates can be measured against it.
Demonstrate continuous improvement to stakeholders or regulators.
Guide designers and developers on how to build more accessible interfaces from the start.
Reduce the risk of introducing new accessibility issues in future updates.
Show that your company actively evaluates and improves accessibility, which is important for legal defense, certifications, and internal governance.

As you can see, a WCAG 2.1 accessibility audit isn’t about simply finding and fixing issues. It’s about creating a reliable strategy that secures continuous compliance.

How to Do a WCAG Accessibility Audit?

The audit usually includes 5 stages:

Reviewing the product’s content.
Testing the product with automation tools and human expertise.
Linking found issues to WCAG criteria to establish which still need to be met.
Reporting the findings.
Providing recommendations on fixing errors (optional).

This might not seem like much. Let’s be honest, the bulk of a WCAG accessibility audit is testing. Which is something you’re well familiar with. Yet, at the same time, you know that testing is never simply about running checks. So, you need to come prepared.

How to Prepare for WCAG 2.1 Standards Compliance?

Teams need to get a few foundations in place before an audit. Otherwise, the process becomes slow, expensive, and full of rework. Preparation isn’t about ticking boxes. It’s about building enough internal capability to fix issues and keep accessibility sustainable.

Help each team learn how WCAG 2.1 requirements apply to their daily work. The goal is to make the crew capable of preventing basic issues before the audit.
Assign a few people in each team who understand accessibility deeper and can answer questions, review work, and keep accessibility considerations from being ignored.
Create simple internal guides: how to structure headings, how to label form fields, etc. This gives the team a consistent reference and reduces inconsistent fixes.
Update development processes so accessibility tests happen early: adding accessibility checks to developers’ “done” criteria, adding basic accessibility criteria to QA, etc.
Set priorities, deadlines, and owners for fixing audit findings. Without clear capacity and accountability, audit results sit untouched.
Make sure all stakeholders agree on goals, timelines, and acceptable risk. This prevents delays and disagreements once the audit’s finalized.
Prepare design files, component library access, code samples, content guidelines, and user flows so auditors understand your product and give precise, relevant recommendations.

These steps are necessary to make sure the WCAG accessibility audit is sustainable and used to its maximum. But of course, if you’re in a time crunch, auditors can still do their work. It won’t be as effective, however. So, try to prepare ahead of time to get help from a QA services provider to get a jump start.

What Does a WCAG Accessibility Audit Include?

Okay, now let’s talk about how the audit actually goes and what a QA company will be doing for you. We can’t speak for everyone. So, we’ll review how QA Madness conducts this process.

1. Planning & Scope Definition

Our QA specialists review your product structure, noting potential accessibility risks and planning the most efficient path through the WCAG accessibility audit. We define what content and workflows are critical to review. And we determine the devices and assistive technologies to include. This ensures the audit focuses on the areas that impact real users most.

2. Automated Scanning

We use tools like Playwright, Lighthouse, and WAVE to quickly “outline” your app. Automated scans give a broad overview, flagging high-volume issues and highlighting areas that need closer inspection. The tools crawl the interface, analyze code and markup, and summarize found errors. The reports are then organized for review, providing a structured starting point for the next phase of the WCAG accessibility audit.

3. Manual Review

Automation can’t catch context-specific problems. So our team performs a detailed manual review:

Ensuring all interactive elements can be accessed and operated without a mouse.
Using NVDA, JAWS, and VoiceOver to verify that content is correctly read aloud and interactions make sense.
Checking usability on different devices and screen sizes, including gestures and orientation changes.
Examining forms, modals, tables, and dynamic content for clarity, usability, and predictable behavior.
Evaluating headings, labels, links, and instructions for clarity and consistency, and more.

Now, we know what you’re worried about — how to do accessibility testing manually and quickly? The answer is simple. Our team is made up of Middle and Senior QA specialists, so they’re precise and consistent. We also assign experts with experience relevant to your project. So, our engineers won’t get stuck on something unexpected or new. Plus, our crew is ISO and ISTQB certified, which comes with quality best practices and processes.

4. Real-World User Scenarios

The WCAG 2.1 guidelines checklist isn’t just about technical compliance. It’s also about real user experiences. We simulate typical user journeys to uncover issues that may not appear in isolated tests, such as navigating a dashboard with a screen reader. Our accessibility and assistive tech specialists ensure that your product makes both EAA and users happy.

5. Documentation & Prioritization

Each finding is documented with screenshots, detailed descriptions, and references to the relevant WCAG 2.1 requirements. Issues are prioritized by severity and impact, helping your team tackle the most critical problems first and plan remediation efficiently.

6. Remediation Roadmap

We provide a clear, actionable roadmap, including guidance for design, development, and content improvements. Recommendations focus on long-term, sustainable fixes, not quick patches.

7. Follow-Up Support

After remediation, we can re-test and verify fixes, ensuring that improvements are effective and maintained over time. Our team can also advise on integrating accessibility into your ongoing QA and development workflows.

A likely question on your mind is “How long does a WCAG accessibility audit take?” Well, that depends on the amount of work. You also can’t rule out that more tasks could pop up. For example, in this accessibility testing case study, our team had to perform checks on more items than initially planned. It’s “anything can happen” in IT. But while the typical timeline ranges from one to 6+ weeks (based on app size) for a complete audit, things can be sped up.

A partnership with a professional QA company gives you a boost by:

Providing ready-to-deploy QA specialists with experience and skills relevant to your project, so no slow starts.
Sharing infrastructure needed for thorough testing, so no time is spent on setup and maintenance.
Following industry best practices (ISO, ISTQB, GDPR), so no hiccups during the WCAG accessibility audit.
Freely scaling testing efforts (add or downsize the team as needed), so no delays.
Managing QA teams and processes without needing your involvement (if you wish), so coordination is taken care of.

So, time isn’t such a big worry. And overall, it’s better to be a bit late but ready than early and unprepared.

Long-Term Business Benefits of a WCAG 2.1 Accessibility Audit

Let’s say you’ve done the audit, and now you’re EAA compliant. Is that it? No. Because it doesn’t just mean not being in trouble with the law.

A WCAG accessibility audit removes legal and commercial risks before they turn into costly problems. When accessibility gaps go unnoticed, companies face fines, lawsuits, and public complaints. And many organisations, especially in the EU, simply won’t work with a product that doesn’t meet accessibility standards.

It also has a direct impact on customer experience and conversion. Accessible interfaces are easier to navigate, more consistent, and more predictable. This helps users find information faster, complete tasks with fewer errors, and stay longer instead of bouncing. Which means more completed checkouts, more sign-ups, and higher retention.

Stronger accessibility also enhances brand reputation. When customers see that a product works well for everyone, it signals a company that is inclusive, mature, and trustworthy. This builds long-term goodwill and reduces the risk of public criticism around exclusion or poor usability.

A WCAG accessibility audit expands your total addressable audience as well. Over 24% of the EU population lives with a disability. And many more experience temporary or situational limitations, like using a phone in bright sunlight, holding a baby in one arm, or recovering from an injury. When your product accommodates these scenarios, you convert and retain users you would otherwise lose.

Long-term development costs also drop significantly. Accessibility issues found early are cheaper to fix because they don’t require designers to redo layouts or engineers to redesign entire components. Without an audit, teams often discover problems late in the release cycle — or after launch — when fixing them requires rewiring workflows, reworking code structure, or pushing urgent patches that disrupt the roadmap.

Compliance with WCAG 2.1 accessibility standards strengthens your competitiveness in the market as well. App stores often reward accessible apps with better visibility. And they may suppress apps with accessibility barriers. Beyond that, accessibility increasingly influences partner decisions, enterprise procurement, and cross-border expansion. Companies that invest early position themselves as compliant, stable vendors in the EU and global markets.

Finally, accessibility improvements make the entire product more robust. Many accessibility best practices lead to cleaner code, better performance, stronger SEO, and easier long-term maintenance. These aren’t just compliance benefits. They’re product quality advantages continue to pay off, release after release.

That is just a few reasons to be happy about the Accessibility Act and work with a trusted partner for the audit.

To Sum Up

The EU’s 2025–2030 EAA transition period is already in motion. So, it’s high time to make sure your accessibility work is moving in the right direction. You’ll want to act quickly to get all the perks of WCAG 2.1 accessibility compliance early and stay ahead of the curve. And we can help you jump-start the process and ensure lasting, impactful success.