Accessibility testing and accessibility remediation are two distinct but interconnected processes in achieving WCAG compliance. Testing identifies accessibility barriers in your website, while remediation fixes those barriers in your source code. Understanding when you need each process, which tools serve each purpose, and how they work together is essential for building and maintaining accessible websites. This guide clarifies the differences and helps you implement both effectively.

Key Takeaways

Understanding the distinction between testing and remediation is crucial for effective accessibility work. Here are the critical points you need to know:

• Testing identifies accessibility barriers; remediation eliminates them through source code changes
• Both processes are necessary for achieving and maintaining WCAG compliance
• Automated testing catches approximately 30-40% of accessibility issues; manual testing is essential for complete coverage
• Source code remediation provides lasting fixes, unlike overlays that attempt to mask problems without solving them
• Continuous testing prevents regression after remediation is complete

Defining Accessibility Testing and Remediation

What Is Accessibility Testing?

Accessibility testing is the process of evaluating a website or application against accessibility standards, primarily WCAG 2.2, to identify barriers that prevent users with disabilities from accessing content and functionality. Testing produces a list of issues, their locations, their severity, and often guidance on how to fix them.

Testing methods include:

Automated Testing: Software tools scan your website's code and rendered pages to detect accessibility violations with programmatic rules. Automated testing excels at finding issues like missing alternative text, insufficient color contrast, missing form labels, and invalid ARIA attributes.

Manual Testing: Human evaluators use WCAG success criteria as a checklist to identify issues that automated tools cannot detect. Manual testing catches problems with logical reading order, meaningful link text, consistent navigation, and complex interaction patterns.

Assistive Technology Testing: Testers use screen readers, keyboard-only navigation, voice control, and other assistive technologies to verify that real-world users can actually navigate and interact with your site.

User Testing: People with disabilities test your website and provide feedback on usability and accessibility from their lived experience.

What Is Accessibility Remediation?

Accessibility remediation is the process of fixing the issues identified during testing by modifying your website's source code. Remediation transforms a list of problems into a list of completed fixes, resulting in a website that meets accessibility standards at the code level.

Remediation activities include:

HTML Modifications: Adding or correcting semantic elements, heading structures, landmark regions, form labels, and alternative text.

CSS Changes: Fixing color contrast, focus indicators, text spacing, and visual presentation issues.

JavaScript Fixes: Implementing keyboard accessibility, focus management, ARIA live regions, and accessible custom components.

Content Updates: Rewriting link text, providing text alternatives for media, improving readability, and adding captions or transcripts.

Architecture Changes: Restructuring navigation, fixing heading hierarchies, and improving overall document structure.

When Do You Need Testing vs Remediation?

Scenarios Requiring Accessibility Testing

Launching a New Website: Before any website goes live, comprehensive accessibility testing ensures you are not shipping barriers to users. Testing during development is far more efficient than remediating after launch.

Redesigning or Rebranding: Visual changes often introduce accessibility issues. New color palettes may fail contrast requirements, new fonts may affect readability, and new layouts may break navigation patterns.

Adding New Features: Any new functionality should undergo accessibility testing before deployment. Interactive components, forms, and dynamic content are particularly prone to accessibility issues.

Responding to Complaints or Legal Demands: When users report accessibility barriers or you receive a legal demand letter, testing establishes your current compliance state and identifies what needs fixing.

Conducting Due Diligence: Before acquiring a company or platform, accessibility testing reveals compliance risks and potential remediation costs.

Periodic Compliance Verification: Regular testing, typically quarterly or annually, catches regression and ensures ongoing compliance.

Scenarios Requiring Accessibility Remediation

Following an Accessibility Audit: After testing reveals issues, remediation addresses them. The audit report becomes your remediation roadmap.

Settling or Avoiding Legal Action: Demand letters and lawsuits require not just acknowledgment of issues but actual fixes. Remediation demonstrates commitment to compliance.

Improving User Experience: When analytics or user feedback indicates that visitors with disabilities struggle with your site, remediation removes those barriers.

Meeting Contractual Requirements: Government contracts, enterprise clients, and educational institutions often require documented accessibility compliance that only remediation can achieve.

Launching in Regulated Markets: Entering markets with accessibility regulations like the European Union (European Accessibility Act) or Canada (Accessible Canada Act) requires remediation to meet legal requirements.

Key Differences Between Testing and Remediation

Purpose and Outcomes

+------------------+-------------------------+---------------------+
|      Aspect      |         Testing         |     Remediation     |
+------------------+-------------------------+---------------------+
|     Purpose      |    Identify problems    |    Solve problems   |
+------------------+-------------------------+---------------------+
|     Outcome      |       Issue report      |      Fixed code     |
+------------------+-------------------------+---------------------+
|   Deliverable    |   Audit documentation   |   Updated website   |
+------------------+-------------------------+---------------------+
|   Who performs   |     Testers/auditors    |      Developers     |
+------------------+-------------------------+---------------------+
|    Frequency     |   Periodic/continuous   |      As needed      |
+------------------+-------------------------+---------------------+
|     Duration     |      Days to weeks      |   Weeks to months   |
+------------------+-------------------------+---------------------+

Skills Required

Testing requires:

• Understanding of WCAG success criteria
• Proficiency with accessibility testing tools
• Experience with assistive technologies
• Attention to detail and documentation skills
• Understanding of user impact

Remediation requires:

• Front-end development skills (HTML, CSS, JavaScript)
• Understanding of accessibility patterns and best practices
• Ability to interpret accessibility requirements
• Testing skills to verify fixes
• Version control and deployment knowledge

Tools and Technologies

Testing tools focus on detection:

• Automated scanners (axe, WAVE, Lighthouse)
• Browser developer tools with accessibility panels
• Screen readers (NVDA, JAWS, VoiceOver)
• Color contrast analyzers
• Keyboard testing procedures

Remediation tools focus on implementation:

• Code editors and IDEs
• Browser developer tools for debugging
• Version control systems
• Accessibility linting tools
• Component libraries with accessible patterns

How Testing and Remediation Work Together

The Continuous Improvement Cycle

Testing and remediation form a cycle rather than a one-time sequence:

1. Initial Testing: Comprehensive audit establishes baseline
2. Prioritization: Issues ranked by severity and impact
3. Remediation: Developers fix prioritized issues
4. Verification Testing: Confirm fixes work and did not introduce regression
5. Ongoing Testing: Continuous monitoring catches new issues
6. Repeat: New issues trigger new remediation

Integration Points

During Remediation:

• Testing verifies each fix before deployment
• Regression testing ensures fixes did not break other functionality
• Assistive technology testing confirms real-world accessibility

After Remediation:

• Full re-audit confirms overall compliance improvement
• Documentation updates accessibility statement
• Baseline established for ongoing monitoring

In Development Workflow:

• Pre-commit testing catches issues before code is merged
• CI/CD integration fails builds with accessibility violations
• Automated monitoring alerts to new issues

Common Misconceptions

Misconception: Automated Testing Is Sufficient

Automated testing catches only 30-40% of accessibility issues. Many critical accessibility requirements cannot be evaluated programmatically:

• Whether alternative text is meaningful and accurate
• Whether heading hierarchy is logical
• Whether keyboard focus order is intuitive
• Whether error messages are helpful
• Whether timing requirements are reasonable

Automated testing is necessary but not sufficient. Manual testing and assistive technology testing complete the picture.

Misconception: Remediation Is a One-Time Project

Websites change continuously through content updates, feature additions, and design modifications. Each change can introduce new accessibility barriers. Remediation establishes compliance at a point in time; ongoing testing and maintenance preserve it.

Misconception: Overlays Are a Form of Remediation

Accessibility overlays from companies like AccessiBe and UserWay are not remediation. They layer JavaScript on top of your website that attempts to modify the rendered page. This approach fails because:

• The underlying code remains inaccessible
• Screen readers receive conflicting signals from original code and overlay modifications
• Keyboard navigation issues in the source code cannot be fixed by overlays
• Courts and regulators have consistently found overlays do not constitute compliance

True remediation modifies your source code, creating lasting accessibility improvements that work consistently across all browsers and assistive technologies.

Misconception: Testing Alone Demonstrates Compliance

Having accessibility testing reports does not mean your website is accessible. Testing identifies problems; only remediation solves them. Organizations sometimes commission audits to understand their risk exposure without committing to fix the issues. This approach provides documentation but not protection.

Building an Effective Testing and Remediation Program

Establish Testing Infrastructure

Automated Testing Integration: ```javascript // Example: Adding axe-core to your test suite const axe = require('axe-core');

describe('Accessibility Tests', () => { it('should have no accessibility violations', async () => { await page.goto('https://example.com');

const results = await axe.run(document); expect(results.violations).toHaveLength(0); }); }); ```

CI/CD Pipeline Integration: ```yaml

Example: GitHub Actions accessibility check

• name: Accessibility Test

run: | npm install -g @axe-core/cli axe https://staging.example.com --exit ```

Create Remediation Capacity

Developer Training: Invest in accessibility training for your development team. Developers who understand accessibility principles create fewer issues and fix existing ones more efficiently.

Accessibility Champions: Designate team members as accessibility specialists who review code, answer questions, and advocate for accessibility in design decisions.

Design System Updates: Build accessibility into your component library. When buttons, forms, and navigation components are accessible by default, developers cannot easily create inaccessible implementations.

Maintain Continuous Improvement

Regular Audits: Schedule comprehensive accessibility audits at least annually, with automated scanning running continuously.

Issue Tracking: Treat accessibility issues like any other bugs, with tickets, priorities, and assignees in your issue tracking system.

Progress Metrics: Track metrics like total issue count, time to remediation, and regression rate to demonstrate improvement over time.

Choosing the Right Tools

Testing Tools Comparison

For Automated Scanning:

• axe DevTools: Comprehensive rule set, integrates with browsers and testing frameworks
• WAVE: Visual feedback on the page, helpful for quick manual reviews
• Lighthouse: Built into Chrome, provides accessibility score alongside performance metrics
• Pa11y: Command-line tool ideal for CI/CD integration

For Manual Testing:

• ANDI (Accessible Name & Description Inspector): Bookmarklet for inspecting accessible names
• Colour Contrast Analyser: Desktop tool for precise contrast checking
• HeadingsMap: Browser extension for visualizing heading structure

For Assistive Technology Testing:

• NVDA: Free screen reader for Windows
• VoiceOver: Built into macOS and iOS
• JAWS: Commercial screen reader with largest enterprise market share

Remediation Tools and Platforms

For Source Code Remediation: Platforms like TestParty focus on fixing actual source code rather than applying overlay patches. This approach achieves genuine compliance because fixes are permanent, work with all assistive technologies, and become part of your codebase. Zero TestParty customers have been sued while using the platform because source code fixes actually work.

For PDF Remediation:

• Adobe Acrobat Pro: Manual PDF accessibility remediation
• CommonLook PDF: Professional PDF remediation and verification
• axesPDF: Automated PDF accessibility checking and fixing

For Document Remediation:

• Microsoft Office Accessibility Checker: Built into Word, Excel, PowerPoint
• Grackle: Google Workspace accessibility checking

Frequently Asked Questions

Can we do remediation without testing first?

Technically yes, but this approach is inefficient. Without testing, you do not know what needs fixing, the severity of issues, or how to prioritize your efforts. Testing provides the roadmap that makes remediation systematic and effective.

How long should we wait between testing and remediation?

Ideally, remediation begins immediately after testing. The longer you wait, the more your website changes, potentially introducing new issues while old ones remain unfixed. Most organizations begin remediation within days of receiving audit results.

Do we need external auditors, or can we test internally?

Both approaches have value. Internal testing provides continuous coverage and builds organizational capability. External audits provide independent validation, fresh perspectives, and documentation that carries weight in legal situations. Most mature accessibility programs combine internal testing with periodic external audits.

What percentage of issues can automated testing find?

Research consistently shows automated testing catches 30-40% of WCAG violations. The remaining 60-70% require manual evaluation. This is why comprehensive accessibility programs never rely on automated testing alone.

How do we prioritize when there are hundreds of issues to fix?

Prioritize by user impact and legal risk. Focus first on issues that completely block access to core functionality, then on WCAG Level A violations, then on issues affecting high-traffic pages. Document your prioritization framework and communicate your remediation timeline.

Should testing and remediation be handled by the same team?

Separation provides accountability and catches more issues. When developers test their own work, they often miss problems. However, developers should have access to testing tools and perform initial accessibility checks. Independent testing then validates their work.

Related Resources

• Complete Accessibility Testing Guide for Web Developers
• Best Shopify Accessibility Tool 2025: A Complete Review

This article was crafted using a cyborg approach - human expertise enhanced by AI to deliver comprehensive, accurate, and actionable accessibility guidance.