DOCSEARCHbyAlgolia
Submit Docs

IBM Equal Access Toolkit

repository·main-4.x·Indexed 19 days ago

https://github.com/ibma/equal-access

A set of automated accessibility testing tools and guidance for creating inclusive digital experiences. It includes the ibm-equal-access-toolkit (v3.0.0), featuring the accessibility-checker-engine for Browser and Node.js environments, a browser extension for manual and visual checking, and NPM packages for CI/CD pipeline integration. The toolkit supports ARIA 1.1 roles and attributes, and provides programmatic access via ace.Checker.check() and aChecker.getCompliance().

Tokens
283.2K
Snippets
544
Records
1.1K
Agent score
72%

What's inside IBM Equal Access Toolkit

  1. Use vitest-accessibility-checker for automated accessibility testing

    main-4.x

    The vitest-accessibility-checker is an automated accessibility testing plugin for Vitest that integrates the IBM Equal Access Accessibility Checker.

    Key Features

    • Vitest Integration: Works with Vitest's browser mode and can test React components directly using vitest-browser-react.
    • Real Browser Testing: Runs tests in real browsers via Playwright.
    • Custom Matchers: Provides custom Vitest matchers for clean, readable test syntax.
    • Flexible Reporting: Outputs scan results in JSON, CSV, HTML, or XLSX formats.
    • Baseline Support: Allows you to validate test results against captured baselines.
    • Configurable Scanning: Set target rule archives, configure policies (rule sets), and define violation levels that trigger test failures or are simply reported.

  2. Project structure of the WebdriverIO boilerplate

    main-4.x

    The boilerplate is organized as follows:

    • test/specs/: Contains WebdriverIO and Mocha test specification files.
    • test/pageobjects/: Contains Page Object classes for organized test interaction.
    • achecker.js: The configuration file for the accessibility checker.
    • wdio.conf.ts: WebdriverIO configuration file.
    • tsconfig.json: TypeScript configuration.
    • package.json: Project dependencies and execution scripts.

  3. Available Java Accessibility Checker Boilerplates

    main-4.x

    The java-accessibility-checker/boilerplates directory provides starter projects for integrating the Java Accessibility Checker into automated testing workflows. There are two primary boilerplates available:

    1. JUnit with Selenium WebDriver (junit-selenium/): Best for testing web applications across different browsers using Selenium's automation capabilities.
    2. JUnit with Playwright (junit-playwright/): A modern approach using Playwright for browser automation, offering robust cross-browser support.

    Both boilerplates use JUnit for test organization and assertions.

  4. Core Architecture Principles of Equal Access

    main-4.x

    The Equal Access toolkit is built on several key architectural principles:

    • Core Engine Foundation: accessibility-checker-engine is the single source of truth for rules and evaluation logic, built in TypeScript/JavaScript for cross-platform use.
    • Modular Tool Design: Each tool (Node, Cypress, Karma, Vitest, Java, Extension) is a specialized integration of the core engine.
    • Shared Common Components: Functionality like configuration management (ACConfigManager), report generation, and baseline comparison (BaselineManager) is centralized in common/module.
    • Flexible Rule Distribution: Rules are bundled locally within Browser Extensions, but Node.js tools can fetch the latest rules from a remote rule-server.
    • Comprehensive Reporting: All tools leverage report-react (via common/module) to provide consistent HTML reports across different environments.

  5. Project structure of the Mocha/Selenium boilerplate

    main-4.x

    The boilerplate is organized into the following directories and files:

    • test/: Contains the Mocha test files and Selenium WebDriver scripts.
    • sample/: Contains a sample web application used for demonstration purposes.
    • util/: Contains helper functions for initializing WebDriver and executing accessibility scans.
    • achecker.js: The central configuration file for the accessibility checker (defines rule archives, policies, violation thresholds, and report locations).
    • package.json: Defines project dependencies and npm scripts.

  6. Automate accessibility testing with cucumber-selenium

    main-4.x
    The cucumber-selenium boilerplate provides a way to use the Cucumber-Selenium WebDriver to automate accessibility testing within a CI/CD pipeline. This approach allows for scanning sets of test cases in a repeatable fashion, which is more advanced than static URL scanning or manual DevTools scans. It enables interacting with pages and saving scan results as part of an automated test suite.

  7. Compare accessibility scans using Baselines

    main-4.x
    To prevent new accessibility issues from being introduced, you can use a 'baseline' to compare scans over time. This allows you to establish a known good state and ensure that subsequent automated tests do not regress. For detailed instructions on setting up and using baselines, refer to the Baseline basics documentation in the project Wiki.

  8. Understand the WCAG20_Form_TargetAndText rule

    main-4.x

    The WCAG20_Form_TargetAndText rule ensures that interacting with form elements (like entering data or selecting controls) does not cause an unexpected change of context without prior user notification.

    Impacted Users

    • Blind users using screen readers
    • People with cognitive limitations
    • Older adults

    Why it matters

    Unpredictable behavior where a form interaction triggers a context change (like a page reload, a new window opening, or a significant change in the UI) can cause frustration or confusion if the user is not prepared for it.

  9. Understand the WCAG20_Blink_AlwaysTrigger rule

    main-4.x

    The WCAG20_Blink_AlwaysTrigger rule identifies content that blinks persistently. Persistent blinking can cause significant issues for users with attention deficit disorders, reading disabilities, intellectual disabilities, or low vision, as it may be impossible to interrupt or disable. The use of the HTML <blink> element is deprecated.

    This rule is based on:

    • IBM 2.2.2 Pause, Stop, Hide guideline
    • WCAG 2.1 failure technique F47

    Remediation: What to do

    If your content requires blinking, you must implement one of the following:

    1. Use a technology that stops blinking in 5 seconds or less.
    2. Provide a user option to turn off blinking.
    3. Provide a link to an alternative page that does not contain the blinking content.

  11. Understand the RPT_Header_HasContent rule

    main-4.x

    The RPT_Header_HasContent rule identifies heading elements that lack descriptive text.

    Impact

    This issue affects:

    • Blind people using screen readers.
    • People who physically cannot use a pointing device.

    Importance

    Heading elements with clear descriptive content allow assistive technology users to understand page sections and navigate quickly to specific areas of interest.

    Compliance Standards

  12. Understand the Karma (Basic) project structure

    main-4.x

    The boilerplate follows this directory structure:

    • test/: Contains Jasmine test files.
    • test/baselines/: Contains baseline files used for comparing scan results.
    • src/: Contains the source HTML files targeted for accessibility testing.
    • achecker.js: The main configuration file for the accessibility checker.
    • karma.conf.js: The Karma test runner configuration.
    • package.json: Project dependencies and scripts.