Blog

Automated Accessibility Testing: Tools, CI/CD Integration, and Business Benefits

by Rajesh K | May 24, 2025 | Accessibility Testing, Blog, Latest Post | 3 comments

Almost every site has accessibility problems. Recent large-scale scans of the world’s most-visited pages revealed that more than 94 percent failed at least one WCAG success criterion. At the same time, digital-accessibility lawsuits in the United States exceeded 4,600 last year, most aimed squarely at websites. With an estimated 1.3 billion people living with disabilities, accessibility is no longer optional; it is a core quality attribute that also improves SEO and overall user experience.This is where accessibility testing, especially automated accessibility testing enters the picture. Because it can be embedded directly into the development pipeline, issues are surfaced early, legal exposure is lowered, and development teams move faster with fewer surprises.

What Is Automated Accessibility Testing?

At its core, automated accessibility testing is performed by software that scans code, rendered pages, or entire sites for patterns that violate standards such as WCAG 2.1, Section 508, and ARIA authoring requirements. While manual testing relies on human judgment, automated testing excels at detecting objective failures like missing alternative text, incorrect heading order, or low colour contrast within seconds. The result is rapid feedback, consistent enforcement, and scalable coverage across thousands of pages.

Key Standards in Focus

To understand what these automated tools are looking for, it’s important to know the standards they’re built around:

WCAG 2.1

Published by the W3C, the Web Content Accessibility Guidelines define the success criteria most organisations target (levels A and AA). They cover four pillars: perceptibility, operability, understandability, and robustness.

Section 508

A U.S. federal requirement harmonised with WCAG in 2018. Any software or digital service procured by federal agencies must comply with this mandate.

ARIA

Accessible Rich Internet Applications (ARIA) attributes provide semantic clues when native HTML elements are unavailable. They’re powerful but if applied incorrectly, they can reduce accessibility making automated checks critical.

Tool Deep Dive: How Automated Scanners Work

Let’s explore how leading tools operate and what makes them effective in real-world CI/CD pipelines:

axe-core

During a scan, a JavaScript rules engine is injected into the page’s Document Object Model. Each element is evaluated against WCAG-based rules, and any violation is returned as a JSON object containing the selector path, rule ID, severity, and remediation guidance.

In CI/CD, the scan is triggered with a command such as npx axe-cli, executed inside GitHub Actions or Jenkins containers. Front-end teams can also embed the library in unit tests using jest-axe, so non-compliant components cause test failures before code is merged. A typical output lists issues such as colour-contrast failures or missing alternative text, enabling rapid fixes.

Pa11y and pa11y-ci

This open-source CLI tool launches headless Chromium, loads a specified URL, and runs the HTML-CS API ruleset. Results are printed in Markdown or JSON, and a configuration file allows error thresholds to be enforced—for example, failing the pipeline if more than five serious errors appear.

In practice, a job runs pa11y-ci immediately after the build step, crawling multiple pages in one execution and blocking releases when limits are exceeded.

Google Lighthouse

Lighthouse employs the Chrome DevTools Protocol to render the target page, apply network and CPU throttling to simulate real-world conditions, and then execute audits across performance, PWA, SEO, and accessibility.

The accessibility portion reuses an embedded version of axe-core. A command such as lighthouse https://example.com –accessibility –output html can be placed in Docker or Node scripts. The resulting HTML report assigns a 0–100 score and groups findings under headings like “Names & Labels,” “Contrast,” and “ARIA.”

WAVE (Web Accessibility Evaluation)

A browser extension that injects an overlay of icons directly onto the rendered page. The underlying engine parses HTML and styles, classifying errors, alerts, and structural information.

Although primarily manual, the WAVE Evaluation API can be scripted for nightly sweeps that generate JSON reports. Developers appreciate the immediate, visual feedback—every icon links to an explanation of the problem.

Tenon

A cloud-hosted service that exposes a REST endpoint accepting either raw HTML or a URL. Internally, Tenon runs its rule engine and returns a JSON array containing priority levels, code snippets, and mapped WCAG criteria.

Dashboards help visualise historical trends, while budgets (for example, “no more than ten new serious errors”) gate automated deployments. Build servers call the API with an authentication token, and webhooks post results to Slack or Teams.

ARC Toolkit

Injected into Chrome DevTools, ARC Toolkit executes multiple rule engines—axe among them—while displaying the DOM tree, ARIA relationships, and heading structure.

Interactive filters highlight keyboard tab order and contrast ratios. QA engineers use the extension during exploratory sessions, capture screenshots, and attach findings to defect tickets.

Accessibility Insights for Web

Two modes are provided. FastPass runs a lightweight axe-based check, whereas Assessment guides manual evaluation step by step.

The associated CLI can be scripted, so team pipelines in Azure DevOps often run FastPass automatically. Reports display pass/fail status and export issues to CSV for further triage.

jest-axe (unit-test library)

Component libraries rendered in JSDOM are scanned by axe right inside unit tests. When a violation is detected, the Jest runner fails and lists each rule ID and selector.

This approach stops accessibility regressions at the earliest stage—before the UI is even visible in a browser.

Under-the-Hood Sequence

So how do these tools actually work? Here’s a breakdown of the core workflow:

• DOM Construction – A real or headless browser renders the page so computed styles, ARIA attributes, and shadow DOM are available.
• Rule Engine Execution – Each node is compared against rule definitions, such as “images require non-empty alt text unless marked decorative.”
• Violation Aggregation – Failures are collected with metadata: selector path, severity, linked WCAG criterion, and suggested fix.
• Reporting – CLI tools print console tables, APIs return JSON, and extensions overlay icons; many also support SARIF for GitHub Security dashboards.
• Threshold Enforcement – In CI contexts, scripts compare violation counts to budgets, fail builds when a limit is breached, or block pull-request merges.

Integrating Accessibility into CI/CD

Automated scans are most effective when placed in the same pipeline as unit tests and linters. A well-integrated workflow typically includes:

• Pre-Commit Hooks – Tools like jest-axe or eslint-plugin-jsx-a11y stop obvious problems before code is pushed.
• Pull-Request Checks – Executions of axe-core or Pa11y run against preview URLs; GitHub Checks annotate diffs with issues.
• Nightly Crawls – A scheduled job in Jenkins or Azure DevOps uses Pa11y or Tenon to crawl the staging site and publish trend dashboards.
• Release Gates – Lighthouse scores or Tenon budgets decide whether deployment proceeds to production.
• Synthetic Monitoring – Post-release, periodic scans ensure regressions are detected automatically.

With this setup, accessibility regressions are surfaced in minutes instead of months—and fixes are applied before customers even notice.

Benefits of Automation

Here’s why automation pays off:

• Early Detection – Violations are identified as code is written.
• Scalability – Thousands of pages are tested in minutes.
• Consistency – Objective rules eliminate human variance.
• Continuous Compliance – Quality gates stop regressions automatically.
• Actionable Data – Reports pinpoint root causes and track trends.

What Automation Cannot Catch

Despite its strengths, automated testing can’t replace human judgment. It cannot evaluate:

• Correctness of alternative-text descriptions
• Logical keyboard focus order for complex widgets
• Meaningful error-message wording
• Visual clarity at 200 percent zoom or higher
• Cognitive load and overall user comprehension

That’s why a hybrid approach—combining automation with manual screen reader testing and usability sessions—is still essential.

Expert Tips for Maximising ROI

To make the most of your automated setup, consider these best practices:

• Budget Critical Violations – Fail builds only on errors that block non-visual usage; warn on minor alerts.
• Component-Level Testing – Run jest-axe inside Storybook or unit tests to stop issues early.
• Colour-Contrast Tokenisation – Codify design-system colour pairs; run contrast checks on tokens to prevent future failures.
• Use ARIA Sparingly – Prefer native HTML controls; use ARIA only when necessary.
• Educate the Team – Make passing accessibility checks part of the Definition of Done.

Quick Checklist Before Shipping

• Axe or Pa11y executed in CI on every commit
• Lighthouse accessibility score ≥ 90
• All images include accurate, concise alt text
• Interactive controls are keyboard-operable
• Colour contrast meets WCAG AA
• Manual screen-reader pass confirms flow and announcements

Conclusion

Accessibility isn’t just about checking a compliance box it’s about creating better digital experiences for everyone. Automated accessibility testing allows teams to deliver accessible software at scale, catch problems early, and ship confidently. But true inclusivity goes beyond what automation can catch. Pair your tools with manual evaluations to ensure your application works seamlessly for users with real-world needs. By embedding accessibility into every stage of your SDLC, you not only meet standards you exceed expectations.

Frequently Asked Questions

Accessibility Testing with Puppeteer

by Rajesh K | Apr 28, 2025 | Accessibility Testing, Blog, Latest Post | 0 comments

As digital products become essential to daily life, accessibility is more critical than ever. Accessibility testing ensures that websites and applications are usable by everyone, including people with vision, hearing, motor, or cognitive impairments. While manual accessibility reviews are important, relying solely on them is inefficient for modern development cycles. This is where automated accessibility testing comes in empowering teams to detect and fix accessibility issues early and consistently. In this blog, we’ll explore automated accessibility testing and how you can leverage Puppeteer a browser automation tool to perform smart, customized accessibility checks.

What is Automated Accessibility Testing?

Automated accessibility testing uses software tools to evaluate websites and applications against standards like WCAG 2.1/2.2, ADA Title III, and Section 508. These tools quickly identify missing alt texts, ARIA role issues, keyboard traps, and more, allowing teams to fix issues before they escalate.

Note: While automation catches many technical issues, real-world usability testing still requires human intervention.

Why Automated Accessibility Testing Matters

• Early Defect Detection: Catch issues during development.
• Compliance Assurance: Stay legally compliant.
• Faster Development: Avoid late-stage fixes.
• Cost Efficiency: Reduces remediation costs.
• Wider Audience Reach: Serve all users better.

Understanding Accessibility Testing Foundations

Accessibility testing analyzes the Accessibility Tree generated by the browser, which depends on:

• Semantic HTML elements
• ARIA roles and attributes
• Keyboard focus management
• Visibility of content (CSS/JavaScript)

Key Automated Accessibility Testing Tools

• axe-core: Leading open-source rules engine.
• Pa11y: CLI tool for automated scans.
• Google Lighthouse: Built into Chrome DevTools.
• Tenon, WAVE API: Online accessibility scanners.
• Screen Reader Simulation Tools: Simulate screen reader-like navigation.

Automated vs. Manual Screen Reader Testing

Automated Accessibility Testing with Puppeteer

Puppeteer is a Node.js library developed by the Chrome team. It provides a high-level API to control Chrome or Chromium through the DevTools Protocol, enabling you to script browser interactions with ease.

Puppeteer allows you to:

• Open web pages programmatically
• Perform actions like clicks, form submissions, scrolling
• Capture screenshots, PDFs
• Monitor network activities
• Emulate devices or user behaviors
• Perform accessibility audits

It supports both:

• Headless Mode (invisible browser, faster, ideal for CI/CD)
• Headful Mode (visible browser, great for debugging)

Because Puppeteer interacts with a real browser instance, it is highly suited for dynamic, JavaScript-heavy websites — making it perfect for accessibility automation.

Why Puppeteer + axe-core for Accessibility?

• Real Browser Context: Tests fully rendered pages.
• Customizable Audits: Configure scans and exclusions.
• Integration Friendly: Easy CI/CD integration.
• Enhanced Accuracy: Captures real-world behavior better than static analyzers.

Setting Up Puppeteer Accessibility Testing

Step 1: Initialize the Project

mkdir a11y-testing-puppeteer
cd a11y-testing-puppeteer
npm init -y

Step 2: Install Dependencies

npm install puppeteer axe-core
npm install --save-dev @types/puppeteer @types/node typescript

Step 3: Example package.json

{
  "name": "accessibility_puppeteer",
  "version": "1.0.0",
  "main": "index.js",
  "scripts": {
    "test": "node accessibility-checker.js"
  },
  "dependencies": {
    "axe-core": "^4.10.3",
    "puppeteer": "^24.7.2"
  },
  "devDependencies": {
    "@types/node": "^22.15.2",
    "@types/puppeteer": "^5.4.7",
    "typescript": "^5.8.3"
  }
}

Step 4: Create accessibility-checker.js

const axe = require('axe-core');
const puppeteer = require('puppeteer');

async function runAccessibilityCheckExcludeSpecificClass(url) {
  const browser = await puppeteer.launch({
    headless: false,
    args: ['--start-maximized']
  });

  console.log('Browser Open..');
  const page = await browser.newPage();
  await page.setViewport({ width: 1920, height: 1080 });

  try {
    await page.goto(url, { waitUntil: 'networkidle2' });
    console.log('Waiting 13 seconds...');
    await new Promise(resolve => setTimeout(resolve, 13000));

    await page.setBypassCSP(true);
    await page.evaluate(axe.source);

    const results = await page.evaluate(() => {
      const globalExclude = [
        '[class*="hide"]',
        '[class*="hidden"]',
        '.sc-4abb68ca-0.itgEAh.hide-when-no-script'
      ];

      const options = axe.getRules().reduce((config, rule) => {
        config.rules[rule.ruleId] = {
          enabled: true,
          exclude: globalExclude
        };
        return config;
      }, { rules: {} });

      options.runOnly = {
        type: 'rules',
        values: axe.getRules().map(rule => rule.ruleId)
      };

      return axe.run(options);
    });

    console.log('Accessibility Violations:', results.violations.length);
    results.violations.forEach(violation => {
      console.log(`Help: ${violation.help} - (${violation.id})`);
      console.log('Impact:', violation.impact);
      console.log('Help URL:', violation.helpUrl);
      console.log('Tags:', violation.tags);
      console.log('Affected Nodes:', violation.nodes.length);
      violation.nodes.forEach(node => {
        console.log('HTML Node:', node.html);
      });
    });

    return results;

  } finally {
    await browser.close();
  }
}

// Usage
runAccessibilityCheckExcludeSpecificClass('https://www.bbc.com')
  .catch(err => console.error('Error:', err));

Expected Output

When you run the above script, you’ll see a console output similar to this:

Browser Open..
Waiting 13 seconds...
Accessibility Violations: 4

Help: Landmarks should have a unique role or role/label/title (i.e. accessible name) combination (landmark-unique)
Impact: moderate
Help URL: https://dequeuniversity.com/rules/axe/4.10/landmark-unique?application-axeAPI
Tags: ['cat.semantics', 'best-practice']
Affected Nodes: 1
HTML Nodes: <nav data-testid-"level1-navigation-container" id="main-navigation-container" class="sc-2f092172-9 brnBHYZ">

Help: Elements must have sufficient color contrast (color-contrast)
Impact: serious
Help URL: https://dequeuniversity.com/rules/axe/4.1/color-contrast
Tags: [ 'wcag2aa', 'wcag143' ]
Affected Nodes: 2
HTML Node: <a href="/news" class="menu-link">News</a>

Help: Form elements must have labels (label)
Impact: serious
Help URL: https://dequeuniversity.com/rules/axe/4.1/label
Tags: [ 'wcag2a', 'wcag412' ]
Affected Nodes: 1
HTML Node: <input type="text" id="search" />

...

Browser closed.

Each violation includes:

• Rule description (with ID)
• Impact level (minor, moderate, serious, critical)
• Helpful links for remediation
• Affected HTML snippets

This actionable report helps prioritize fixes and maintain accessibility standards efficiently.

Best Practices for Puppeteer Accessibility Automation

• Use headful mode during development, headless mode for automation.
• Always wait for full page load (networkidle2).
• Exclude hidden elements globally to avoid noise.
• Capture and log outputs properly for CI integration.

Conclusion

Automated accessibility testing empowers developers to build more inclusive, legally compliant, and user-friendly websites and applications. Puppeteer combined with axe-core enables fast, scalable accessibility audits during development. Adopting accessibility automation early leads to better products, happier users, and fewer legal risks. Start today — make accessibility a core part of your development workflow!

Frequently Asked Questions

NVDA Guide: Essential Tips for Accessibility Success

by Anika Chakraborty | Mar 5, 2025 | Accessibility Testing, Blog, Latest Post | 2 comments

NVDA (NonVisual Desktop Access) is a powerful screen reader designed to assist individuals with visual impairments in navigating and interacting with digital content. It enables users to access Windows-based applications, websites, documents, and emails by converting on-screen text into speech and Braille output. With support for multiple languages and Braille displays, NVDA provides accessibility across various digital platforms. It also offers customizable keyboard shortcuts, speech synthesis options, and screen magnification features, allowing users to tailor their experience based on individual needs. In addition to its role in daily accessibility, NVDA is an essential tool for accessibility testing, helping organizations evaluate whether their digital products meet key accessibility standards such as WCAG, Section 508, ADA, and EN 301 549. By simulating how visually impaired users interact with websites and applications, testers can identify and fix accessibility barriers, ensuring an inclusive digital experience. This blog will guide you through how to use NVDA effectively, covering installation, basic navigation, and advanced features like web browsing, document reading, application accessibility, and accessibility testing. Whether you’re a beginner or an experienced user, this tutorial will help you maximize NVDA’s capabilities for seamless digital access.

Why Choose NVDA for Accessibility Testing?

NVDA is widely used by many visually impaired users due to its reliability, accessibility, and powerful features. As one of the most popular screen readers, it plays a crucial role in accessibility testing, ensuring that websites and applications are compatible with real-world usage.

As part of the testing process, NVDA is utilized to evaluate accessibility and verify compliance with WCAG and other accessibility standards. Its features make it an essential tool for testers in identifying and addressing accessibility barriers.

• Free & Open-Source – Available at no cost, making it accessible to everyone.
• Multi-Language Support – Supports various languages and voice options for diverse users.
• Braille Compatibility – Works with external braille displays, expanding accessibility.
• Keyboard Navigation – Enables seamless interaction using hotkeys, crucial for users relying on keyboard controls.
• Website & App Testing – Helps validate accessibility compliance and usability.
• Continuous Updates – Regular improvements enhance performance and functionality.
• Lightweight & Fast – Runs efficiently on low-end devices, making it widely accessible.

Since many disabled users depend on NVDA, it should be included in accessibility testing, along with other screen readers like JAWS, VoiceOver, and Narrator. Its use ensures that digital products are accessible, user-friendly, and inclusive for all.

How to Install NVDA (Step-by-Step):

1. Download NVDA

• Go to the official NVDA website: NVDA Website.
• Click on the Download Link.
• Scroll down and click on Download button.

2. Open the Installer: Locate the downloaded .exe file in your downloads folder.

3. Confirm Installation: Click “Yes” in the pop-up dialog box that appears.

4. Choose Installation Options: Select your preferred installation options (such as installing for all users or just for yourself).

5. Start Installation: Click Install to begin the process.

6. Complete Installation: Once the installation is complete, click Finish.You may be given an option to launch NVDA immediately.

7. Restart : your computer if prompted to ensure smooth functionality.

How to Perform NVDA Testing

1. Check the Navigation

• Check if all interactive elements (buttons, links, forms) receive focus.
• Ensure the focus moves in a logical order and does not jump randomly.

2. Verify Headings Structure

• Ensure headings are labeled correctly (H1, H2, H3, etc.).
• Use the H key to navigate through headings efficiently.

3. Test Readability & Content Order

• Use the Down Arrow key to check if content is read in a logical sequence.
• Navigate backward using the Up Arrow key to ensure text flows naturally.

4. Check Alt Text for Images

• Ensure all images have meaningful alt text that describes their content.
• NVDA should correctly announce the image descriptions.

5. Validate Forms

• Ensure form fields have appropriate labels.
• Check that NVDA reads out each form element correctly.
• Test checkboxes, radio buttons, and combo boxes for accessibility.

6. Verify Links & Buttons

• Replace generic text like “Click Here” with descriptive links (e.g., “Download Guide”).
• Ensure buttons are labeled clearly and announced properly by NVDA.

7. Test Multimedia Accessibility

• Ensure videos include captions or transcripts for better accessibility.
• Avoid auto-playing videos without user control.
• Provide alternative text for non-text content such as charts or infographics.

Basic NVDA Commands:

Navigation Commands:

Table Navigation:

Text Reading:

Form Navigation:

Avoid Visual Reliance with NVDA

• Bold or color changes should not be the only way to highlight important text. Use HTML tags like ‘strong’ or ’em’.
• CAPTCHAs should have audio alternatives for visually impaired users.
• Ensure hover effects or animations are accessible and not essential for navigation.

Troubleshooting Common NVDA Issues

When using NVDA for accessibility testing or daily tasks, some common issues may arise. Below are frequent problems and their solutions:

NVDA is not starting

• Restart the system and check for conflicting applications.
• If the issue persists, reinstall NVDA.

No speech output

• Ensure the volume is turned up.
• Check NVDA settings and select the correct speech synthesizer.

Text is being read incorrectly

• Verify that the website or application has proper ARIA labels and semantic HTML.
• Test with another screen reader to confirm the issue.

Keyboard shortcuts are not working

• Ensure NVDA is not in sleep mode.
• Restart NVDA and check shortcut settings.

Dynamic content is not being read

• Enable “Live Regions” in NVDA settings.
• Refresh the page manually if necessary.

Performance is slow or laggy

• Close unnecessary background applications.
• Adjust NVDA settings for better performance and restart the system.

By troubleshooting these issues effectively, NVDA can be used efficiently in accessibility testing, ensuring a seamless experience for users who rely on screen readers.

Conclusion

NVDA (NonVisual Desktop Access) is a highly effective screen reader that empowers visually impaired users to navigate and interact with digital content effortlessly. With its text-to-speech conversion, Braille display support, and customizable keyboard shortcuts, NVDA enhances accessibility across various applications, including web browsing, document editing, and software operations. Its continuous updates and broad compatibility make it a reliable solution for both individuals and organizations seeking to create inclusive digital experiences. At Codoid, we recognize the importance of accessibility in modern software development. Our accessibility testing services ensure that digital platforms comply with accessibility standards such as WCAG and Section 508, making them user-friendly for individuals with disabilities. By leveraging tools like NVDA, we help businesses enhance their software’s usability, ensuring equal access for all users.

Frequently Asked Questions

ANDI Accessibility Testing Tool Tutorial

by Chris Adams | Feb 27, 2025 | Accessibility Testing, Blog, Latest Post | 0 comments

Web accessibility testing tools help developers and testers identify and fix barriers that prevent people with disabilities from accessing online content. One such powerful yet simple tool is ANDI (Accessible Name & Description Inspector).Developed by the Social Security Administration (SSA), ANDI Accessibility testing Tool is a free and lightweight browser extension designed to help web developers improve accessibility. It provides real-time insights into common accessibility issues, assisting developers to ensure compliance with WCAG (Web Content Accessibility Guidelines) and Section 508 standards.Suppose you are new to accessibility testing or looking for an efficient way to improve your website’s compliance. In that case, this guide will walk you through everything from ANDI’s history and installation to performing detailed accessibility checks.

History of ANDI and Its Inventor

ANDI was developed by the Social Security Administration (SSA), a U.S. government agency responsible for social security programs. Recognizing the importance of digital accessibility, SSA created ANDI to help developers and testers easily identify and correct accessibility issues without requiring advanced expertise. Unlike many commercial accessibility tools, ANDI was designed to be free, easy to use, and lightweight. Since its launch, it has become a widely adopted tool among government agencies, developers, and accessibility testers who need a quick and reliable way to check for compliance with WCAG and Section 508 guidelines.

TEXT

Key Features of ANDI Accessibility Testing Tool:

• Identifies missing or incorrect ARIA attributes
• Analyzes focusable elements for screen reader compatibility
• Checks HTML structure and semantic elements
• Detects issues with links, buttons, and form fields
• Highlights contrast issues for better readability
• Ensures compliance with WCAG and Section 508

By using ANDI, developers and testers can quickly pinpoint accessibility issues and make necessary improvements without modifying the original webpage.

Compatible Browsers for ANDI Accessibility Testing Tool

ANDI is designed to work without installation as a simple bookmarklet. It is compatible with the following browsers:

• Google Chrome
• Microsoft Edge (Chromium-based)
• Mozilla Firefox
• Internet Explorer (limited support)

Note: Safari does not natively support JavaScript bookmarklets, so manual setup is required.

How to Install ANDI Accessibility Testing Tool

ANDI is a browser-based accessibility testing tool that runs as a bookmarklet—meaning it does not require a separate software installation. Instead, it is activated by adding a JavaScript snippet to your browser’s bookmarks bar.

Installation Instructions for Different Browsers

For Google Chrome & Microsoft Edge (Chromium-based browsers):

1.Enable the Bookmarks Bar

• Press Ctrl + Shift + B to make the bookmarks bar visible.

2. Drag and drop the ANDI tool

3. Activate ANDI

• Whenever you need to test a webpage, click on the ANDI bookmarklet from your bookmarks bar.

For Mozilla Firefox:

1. Enable the Bookmarks Toolbar

• Press Alt + V, go to Toolbars and enable Bookmarks Toolbar.

2. Add ANDI as a Bookmark

• Right-click on this ANDI Tool Link and select “Bookmark This Link.”
• Name the bookmark ANDI and ensure it is saved in the Bookmarks Toolbar.

3. Activate ANDI

• Click the ANDI bookmark whenever you want to run the accessibility test.

For Internet Explorer:

1. Enable the Favorites Bar

• Press Alt + V, go to Toolbars, and enable Favorites Bar.

2. Add ANDI as a Favorite

• Right-click on this ANDI Tool Link and select “Add to Favorites Bar.”

3. Activate ANDI

• Click the ANDI bookmark whenever you need to analyze a webpage.

For Safari (Manual Setup Required):

• Safari does not fully support JavaScript bookmarklets in the same way as other browsers.
• You may need to manually add and run the ANDI script from the browser’s developer console.
• Manual Steps:

1. Open the Developer Console in Safari

• Press Cmd + Option + I (Mac) or Ctrl + Shift + I (Windows) to open the Developer Tools in Safari.
• Alternatively, you can right-click anywhere on the webpage and select Inspect Element to open the Developer Tools.

2. Go to the “Console” Tab

• In the Developer Tools window, click on the Console tab where you can execute JavaScript.

3. Add the ANDI Script Manually

• First, go to the ANDI website or locate the script source. You need to copy the JavaScript code that runs the ANDI tool.
• Here’s a basic script you can use to run ANDI on a webpage:

(function() {
    var script = document.createElement('script');
    script.src = 'https://www.andiapp.com/andi.js';
    script.onload = function() {
        ANDI.launch(); // Launch the ANDI tool once the script is loaded
    };
    document.head.appendChild(script);
})();

4. Paste and Execute the Script

• Copy the code above and paste it into the Console tab in Developer Tools.
• Press Enter to run the script.

5. Access the ANDI Tool

• After executing the script, the ANDI tool should automatically load on the page, and you can start inspecting accessibility issues.
• If the script is successfully loaded, you should see the ANDI interface on the page.

How to Use ANDI Accessibility Testing Tool

Once installed, ANDI can quickly scan a webpage and provide insights on accessibility issues. Here’s a step-by-step guide on how to use it:

Step 1: Activate ANDI on a Webpage

1. Open the webpage you want to test.

2. Click on the ANDI bookmarklet from your browser’s bookmarks bar.

3. ANDI will scan the page and overlay accessibility information, highlighting potential issues.

Step 2: Analyze Accessibility Elements

Use the preview buttons “<" (backward element) or ">” (Forward element) to analyze the accessibility elements.

ANDI categorizes issues into different sections:

Headings & Structure

• Ensures proper heading hierarchy (h1 → h6) to help screen readers.
• Example Issue: Missing h1 on a webpage.
• Fix: Add h1 Main Heading /h1 to define the page structure properly.

Links & Buttons

• Check if links and buttons have clear, accessible labels.
• Example Issue: An empty without a label.
• Fix: Add a Link or descriptive text:

<a href="www.apple.com">Buy</a>

Images & Alternative Text

• Ensures that all images have meaningful alt text for screen readers.
• Example Issue:img src=”iphone16promax.png” – (No alt attribute is provided.)
• Fix: Add an alt attribute: img src=”iphone16promax.png” alt=”iPhone 16 Pro Max, all four finishes, Black Titanium, White Titanium, Natural Titanium and Desert Titanium.

Color Contrast & Readability

• Ensures text has a minimum contrast ratio of 3:1 for readability.
• Example Issue: Light grey text on a white background.
• Fix: Adjust the text color or background to improve contrast.

Keyboard Navigation & Focus Order

• Ensures interactive elements are accessible using the Tab key.
• Example Issue: A ‘div’ styled as a button that is not keyboard-accessible.
• Fix: Use a ‘button’ element or add tabindex=”0″ to make it focusable.

Step 3: Review ANDI’s Recommendations

• Click on highlighted elements for detailed accessibility reports.
• Modify your HTML, CSS, or ARIA attributes based on ANDI’s suggestions.
• Re-run ANDI to verify fixes and improvements.

Example Scenarios & How ANDI Helps

Why Use ANDI for Accessibility Testing?

ANDI is a preferred tool for accessibility testing due to its simplicity and effectiveness. Here are some reasons why developers and testers rely on it:

• Free & Easy to Use – No complex setup or licensing required.
• Works in the Browser – No separate software installation needed; runs directly in Chrome, Edge, and Firefox.
• Detailed Insights – Provides in-depth accessibility reports and suggestions.
• Non-Disruptive Testing – Runs without altering the webpage’s original code.
• Lightweight & Fast – Does not slow down the webpage or require heavy system resources.

Unlike many automated tools that simply provide a compliance score, ANDI visually highlights accessibility issues and offers specific recommendations, making it an essential tool for developers.

Conclusion

ANDI is a free, easy-to-use tool for accessibility testing. It provides real-time feedback on headings, forms, images, keyboard navigation, and color contrast, helping developers fix issues directly on the webpage. Unlike other tools that generate reports, ANDI offers interactive insights for quick improvements. Integrating ANDI into your workflow ensures your website is accessible, WCAG and Section 508 compliant, and user-friendly. It also boosts SEO and usability. For professional testing, Codoid offers expert support. Start using ANDI today to build a more inclusive web!

Frequently Asked Questions

Screen Reader Accessibility Testing Tools

by Charlotte Johnson | Feb 26, 2025 | Accessibility Testing, Blog, Latest Post | 0 comments

Millions of people with disabilities rely on assistive technologies to navigate websites, applications, and digital content. Among these technologies, screen readers play a vital role in making digital platforms usable for individuals with visual impairments, cognitive disabilities, and other accessibility needs. Despite advancements in web development and design, many digital platforms still fail to accommodate users who depend on screen readers. Without proper accessibility testing, visually impaired users encounter significant barriers that prevent them from accessing information, completing transactions, or even performing basic online interactions. In this blog, we will explore the critical role of screen reader accessibility testing, the consequences of inadequate screen reader support, and the legal mandates that ensure digital inclusivity for all.

What Happens Without a Screen Reader?

For individuals who are blind or visually impaired, accessing digital content without a screen reader can be nearly impossible. Screen readers convert on-screen text, buttons, images, and other elements into speech or braille output, allowing users to navigate and interact with websites and applications. Without this assistive technology:

• Navigation Becomes Impossible: Users cannot “see” menus, buttons, or links, making it difficult to move through a website.
• Critical Information is Lost: Important content, such as descriptions of images, form labels, and error messages, is inaccessible.
• Online Interactions Become Challenging: Tasks like shopping, filling out forms, and accessing services require proper accessibility support.

Without screen reader support, digital exclusion becomes a reality, limiting independence and access to essential services.

How Testers Evaluate Websites Using Screen Readers

Testers play a crucial role in ensuring websites are accessible to individuals with disabilities by using the same screen reader tools that visually impaired users rely on. By testing digital platforms from an accessibility perspective, they identify barriers and ensure compliance with accessibility standards like WCAG, ADA, and Section 508.

Here’s how testers evaluate a website using screen readers:

• Text-to-Speech Verification: Testers use screen readers like NVDA, JAWS, and VoiceOver to check if all on-screen text is correctly converted into speech and read in a logical order.
• Keyboard Navigation Testing: Since many users rely on keyboard shortcuts instead of a mouse, testers verify that all interactive elements (menus, buttons, links) can be accessed and navigated using keyboard commands.
• Form Accessibility Checks: Testers confirm that screen readers correctly read out form labels, input fields, and error messages, allowing users to complete online transactions without confusion.
• Image & Alt Text Validation: Using screen readers, testers ensure that images have proper alt text and that decorative images do not interfere with navigation.

By incorporating screen reader testing into their accessibility audits, testers help developers create an inclusive experience where visually impaired users can navigate, interact, and access content effortlessly.

A sample video explains how to perform testing using screen readers.

(In the shared video, we identified a bug related to the list items on the page. There is a single list item enclosed within ‘ul’ and ‘li’ tags, which is unnecessary for the content. This should be changed to a ‘p’ or ‘span’ tag to better suit the structure and purpose of the content.)

List of Screen Reader Tools for Accessibility Testing

Different devices have built-in or third-party screen readers, each designed for their platform. Testers use these tools to check how well websites and apps work for visually impaired users. By testing navigation with keyboard shortcuts, touch gestures, and braille displays, they identify accessibility issues and ensure a smooth, inclusive experience across all platforms.

1. NVDA (NonVisual Desktop Access)

NVDA is one of the most popular free and open-source screen readers available for Windows. It is widely used by individuals, developers, and testers to ensure digital accessibility. NVDA supports multiple languages and braille devices, making it a versatile option for users worldwide. The software is also highly customizable with add-ons that enhance functionality. NVDA is compatible with popular browsers like Chrome, Firefox, and Edge, allowing seamless web navigation.

Need to know more? Click here

Few Basics Key Shortcuts:

• Ctrl + Alt + N: Open NVDA menu.
• Insert + Q: Exit NVDA.
• Insert + Space: Toggle between browse and focus modes.
• H: Navigate to the next heading.
• K: Navigate to the next link.
• D: Navigate to the next landmark.

2. JAWS (Job Access With Speech)

JAWS is a powerful commercial screen reader designed for Windows users. It provides advanced braille support, multiple language compatibility, and a highly responsive interface, making it ideal for professional and educational use. JAWS is widely adopted in workplaces and institutions due to its robust functionality and seamless integration with Microsoft Office and web browsers. It offers a free trial for 40 minutes, allowing users to test its capabilities before purchasing a license.

Need to know more? Click here

Few Basics Key Shortcuts:

• Insert + F1: Open the JAWS help menu.
• Insert + Down Arrow: Read the current line.
• Insert + T: Read the title of the current window.
• H: Navigate to the next heading.
• B: Navigate to the next button.
• Ctrl: Stop speech.

3. VoiceOver

VoiceOver is Apple’s built-in screen reader, available on MacBooks, iPhones, and iPads. It is fully integrated into Apple’s ecosystem, ensuring smooth navigation across macOS and iOS devices. VoiceOver supports gesture-based navigation on iPhones and iPads, making it easy for users to interact with apps using touch gestures. On macOS, VoiceOver works with keyboard shortcuts and braille displays, providing a comprehensive accessibility experience.

Need to know more? Click here

Few Basics Key Shortcuts:

• Cmd + F5: Turn VoiceOver on/off.
• Ctrl + Option + Arrow Keys: Navigate through elements.
• Ctrl + Option + Space: Activate the selected item.
• Ctrl + Option + H: Navigate to the next heading.

4. TalkBack

TalkBack is Android’s built-in screen reader, designed to help users with visual impairments navigate their devices through gesture-based controls. It provides audio feedback and spoken descriptions for on-screen elements, making it easier for users to interact with apps and perform tasks independently. TalkBack is compatible with third-party braille displays, expanding its accessibility features for visually impaired users who rely on tactile reading.

Need to know more? Click here

Gestures:

• Swipe Right/Left: Move to the next/previous element.
• Double Tap: Activate the selected item.
• Two-Finger Swipe Down: Read all content on the screen.
• Swipe Down then Right: Open the TalkBack menu.

https://assistivlabs.com/assistive-tech/screen-readers/narrator

5. Narrator

Narrator is Microsoft’s built-in screen reader, available on all Windows devices. It provides basic screen reading functionality for users who need an immediate accessibility solution. While it lacks the advanced features of NVDA and JAWS, Narrator is easy to use and integrates seamlessly with Windows applications and web browsing. It also supports braille displays, making it a useful tool for users who prefer tactile feedback.

Need to know more? Click here

• Few Basics Key Shortcuts:
• Caps Lock + Space: Activate the selected item.
• Caps Lock + Arrow Keys: Navigate through elements.
• Caps Lock + H: Navigate to the next heading.
• Caps Lock + M: Start reading from the cursor position.

6. Orca

Orca is an open-source screen reader designed for Linux users. It is highly customizable, allowing users to modify speech, braille, and keyboard interactions according to their needs. Orca is widely used in the Linux community, especially by developers and users who prefer an open-source accessibility solution. It supports braille displays and works well with major Linux applications and browsers.

Need to know more? Click here

• Few Basics Key Shortcuts:
• Insert + H: Navigate to the next heading.
• Insert + Space: Toggle between browse and focus modes.
• Insert + S: Read the current sentence.
• Insert + Q: Exit Orca.

7. ChromeVox

ChromeVox is a lightweight screen reader developed specifically for Chromebooks and the Chrome browser. It is designed to provide a smooth web browsing experience for visually impaired users. ChromeVox is easy to enable with a simple keyboard shortcut and is optimized for Google services and web-based applications.

Need to know more? Click here

• Few Basics Key Shortcuts:
• Search + A: Read from the current location.
• Search + Left/Right Arrow: Navigate to the previous/next element.
• Search + Space: Activate the selected item.
• Search + H: Navigate to the next heading.

Laws That Mandate Screen Reader Accessibility

Several global laws and regulations require digital accessibility, ensuring that people with disabilities can access online content without barriers. Some key legal frameworks include:

• Americans with Disabilities Act (ADA) – USA mandates that businesses and organizations make their digital content accessible, ensuring equal access to websites, applications, and digital services.
• Section 508 of the Rehabilitation Act – USA requires federal agencies to ensure that their electronic and information technology is accessible to individuals with disabilities.
• European Accessibility Act (EAA) – European Union mandates that digital services, including websites and mobile applications, be accessible to people with disabilities.
• UK Equality Act 2010 – United Kingdom ensures digital platforms are accessible, preventing discrimination against individuals with disabilities in accessing online content and services.

Many of these laws follow the Web Content Accessibility Guidelines (WCAG), a globally recognized standard that provides best practices for making digital content accessible. WCAG ensures websites and applications support screen readers, keyboard navigation, and proper color contrast, helping businesses create an inclusive online experience. Failure to comply with these laws and standards can lead to legal action, financial penalties, and reputational damage.

Conclusion

Each screen reader tool has its own unique capabilities, shortcuts, and strengths. Digital accessibility goes beyond just legal compliance—it is about fostering an inclusive and user-friendly experience for all. Screen readers are essential in empowering visually impaired users to navigate websites, interact with applications, and access digital content independently. By incorporating screen reader testing into the development process, businesses can enhance usability, expand their audience, and showcase their dedication to inclusivity.

Codoid, a leading software testing company, specializes in accessibility testing, ensuring that digital platforms are fully accessible. They help businesses optimize their websites and applications for screen readers such as NVDA, JAWS, VoiceOver, and TalkBack. With expertise in WCAG compliance testing, keyboard navigation testing, and a blend of manual and automated accessibility testing, Codoid ensures seamless digital experiences for all users

Frequently Asked Questions

ADA vs Section 508 vs WCAG: Key Differences Explained

by Mollie Brown | Feb 20, 2025 | Accessibility Testing, Blog, Latest Post | 0 comments

Accessibility is crucial in web and app development. As we rely more on digital platforms for communication, shopping, healthcare, and entertainment, it’s important to make sure everyone, including people with disabilities, can easily access and use online content. Accessibility testing helps identify and fix issues, ensuring websites and apps work well for all users, regardless of their abilities. It’s not just about following rules, but about making sure all users have a positive experience. People with disabilities, such as those with vision, hearing, mobility, or cognitive challenges, should be able to navigate websites, find information, make transactions, and enjoy digital content easily. This can include features like text descriptions for images, keyboard shortcuts, video captions, and compatibility with screen readers and assistive devices. Understanding the ADA vs. Section 508 vs. WCAG guidelines helps create accessible experiences for all.

Three key accessibility standards define how digital content should be made accessible:

• ADA(Americans with Disabilities Act) is a U.S. civil rights law that applies to private businesses, public places, and online services. It ensures equal access to goods, services, and information for people with disabilities.
• Section 508 is specific to U.S. federal government agencies and organizations receiving federal funding. It mandates that all electronic and information technology used by these entities is accessible to individuals with disabilities.
• WCAG(Web Content Accessibility Guidelines) is a globally recognized set of standards for digital accessibility. While not a law, it is frequently used as a benchmark for ADA and Section 508 compliance.

Many people find it challenging to distinguish between the Americans with Disabilities Act (ADA) and Section 508 because they are both U.S. laws designed to ensure accessibility for people with disabilities. However, they apply to different entities and serve distinct purposes. The ADA is a civil rights law that applies to private businesses, public places, and online services, ensuring equal access to goods, services, and information for people with disabilities. For instance, an e-commerce website must be accessible to users who rely on screen readers or other assistive technologies.

In contrast, Section 508 targets U.S. federal government agencies and organizations receiving federal funding. Its primary aim is to ensure that all electronic and information technology used by these entities, such as websites and digital documents, is accessible to individuals with disabilities. For example, a government website providing public services must be fully compatible with assistive technologies to ensure accessibility for all users.

Although these standards overlap in their objectives, they differ in their applications, enforcement, and compliance. WCAG (Web Content Accessibility Guidelines) also plays a crucial role as a globally recognized set of standards that guide digital accessibility practices. This guide will delve into these standards at length, providing details of their background, main principles, legal considerations, and best practices in compliance.

ADA: The Legal Backbone of Digital Accessibility in the U.S.

The Americans with Disabilities Act (ADA) is a federal civil rights statute passed in 1990 to ban discrimination against people with disabilities. Although initially aimed at physical locations, courts have come to apply Title III of the ADA to websites, mobile applications, and online services.

Key Titles of the ADA

• Title I: Employment discrimination.
• Title II: Accessibility for government services and public entities.
• Title III: Covers businesses and public accommodations

Legal Precedents & Enforcement

• Domino’s Pizza v. Guillermo Robles (2019) – A blind user sued Domino’s because its website was inaccessible via screen readers. The court ruled in favor of accessibility.
• Target (2008) – Target paid $6 million after being sued for website inaccessibility.
• Beyoncé’s Website Lawsuit (2019) – The singer’s official website faced legal action due to a lack of screen reader compatibility.

Compliance Requirements

The Department of Justice (DOJ) has not specified a technical standard for ADA compliance, but courts frequently reference WCAG 2.1 AA as the benchmark.

Who Must Comply with ADA?

Private businesses offering goods/services to the public.

Example: E-commerce platforms, healthcare providers, financial services, and educational institutions.

Consequences of Non-Compliance

• Lawsuits & Legal Fines – Organizations may face costly legal battles.
• Reputational Damage – Public backlash and loss of consumer trust.
• Forced Compliance Orders – Companies may be required to implement accessibility changes under legal scrutiny.

Section 508: Accessibility for Government Agencies

Section 508 is part of the Rehabilitation Act of 1973, requiring U.S. federal agencies and organizations receiving federal funding to make their digital content accessible.

508 Refresh (2017)

The 2017 update aligned Section 508 requirements with WCAG 2.0 AA, making it easier for organizations to follow global best practices.

Who Must Comply?

• Federal agencies (e.g., IRS, NASA, Department of Education).
• Government contractors and federally funded institutions.
• Universities and organizations receiving government grants.

Understanding WCAG: The Global Standard for Web Accessibility

Web Content Accessibility Guidelines (WCAG) are a collection of technical standards established by the World Wide Web Consortium (W3C) as part of the Web Accessibility Initiative (WAI). As opposed to ADA and Section 508, WCAG is not legislation but rather a de facto standard for web accessibility that has gained universal recognition across the globe.

History of WCAG

• WCAG 1.0 (1999): The first version of accessibility guidelines.
• WCAG 2.0 (2008): Introduced the POUR principles (Perceivable, Operable, Understandable, Robust).
• WCAG 2.1 (2018): Added guidelines for mobile accessibility and low-vision users.
• WCAG 2.2 (2023): Introduced additional criteria for cognitive and learning disabilities.

WCAG Principles: POUR Framework

WCAG is built around four core principles, ensuring that digital content is:

• Perceivable – Information must be available to all users, including those using screen readers or magnification tools.
• Operable – Users must be able to navigate and interact with the site using a keyboard or assistive technologies.
• Understandable – Content should be readable and predictable.
• Robust – Content must work well across different devices and assistive technologies.

WCAG Compliance Levels

WCAG has three levels of conformance:

• Level A – Basic accessibility requirements.
• Level AA – Standard compliance level (required by most laws, including ADA and Section 508).
• Level AAA – The highest level, ideal for specialized accessibility needs.

Comparing ADA, Section 508 and WCAG

Best Practices for Ensuring Compliance

1.Conduct an Accessibility Audit – Utilize tools such as Axe, ARC Toolkit, WAVE, or Color Contrast Analyzer.

2.Test with Assistive Technologies – Test for compatibility with NVDA, JAWS, and VoiceOver screen readers.

3. Ensure Keyboard Navigation – Users must be able to access all content without using a mouse.

4. Provide Alternative Text (Alt Text) – Include alt text for images and semantic labels for form fields.

5. Improve Color Contrast – Provide a minimum contrast ratio of 4.5:1 between text and background.

6. Use Semantic HTML – Correctly structure headers, buttons, and links so they are simple to navigate through.

7. Ensure Captioning & Transcripts – Caption videos and make transcripts available for audio content.

8. Perform Regular Testing – Accessibility never ends; periodically test and keep up to date.

9. Ensure table readability – Provide a proper table header, table caption, and summary of the complex table.

10. Ensure Heading Level – Provide a correct heading hierarchy for every page, and every page should have an H1 tag.

11. Resize & Reflow – Ensure content adapts properly when resized for Resize up to 200% without changing any resolution and Reflow up to 400% change with resolution into vertical scrolling content (320 CSS pixels) and horizontal scrolling content (256 CSS pixels) without loss of functionality or readability.

12. Text Spacing – Allow users to adjust letter spacing, line height, and paragraph spacing without breaking layout or hiding content.

13. Use of Color – Do not rely on color alone to convey meaning; provide text labels, patterns, or icons as alternatives.

Conclusion

Ensuring digital accessibility is not just about meeting legal requirements—it’s about inclusivity and equal access for all users. By adhering to accessibility standards like WCAG, ADA, and Section 508, organizations can provide a seamless digital experience for everyone, regardless of their abilities. At Codoid, our team of skilled engineers specializes in accessibility testing using a range of advanced tools and techniques. From automated audits to manual testing with assistive technologies, we ensure that your digital platforms are accessible, compliant, and user-friendly. Trust Codoid to help you achieve accessibility excellence.

Frequently Asked Questions