Funding ACD

Accessibility Compatibility Dataset (ACD) The dataset which includes the accessibility interoperability support data for browser and assistive technology combinations. will turn browser and assistive technology test results into accessibility support data that developer tools can use. This proposal sets out what the first version needs, what it costs, and how your organisation can fund it.

Total cost
Get in touch
Deliverables seeking funding
3
Fund
One deliverable or the whole project
Status
In Progress
Fund this work

The problem

The aim of the ACD project is to produce web accessibility data for use in developer tooling, documentation and AI systems.

In 2025, a series of workshops proved the need for interoperable accessibility support data. We built a proof of concept for a tool that pulls in results from Web Platform Tests (WPT) The browser test suite which includes tests for every web feature. and an accessibility dataset source (provided by Tetralogical) and computes support data from the combined results.

The proof of concept showed what’s possible, and what needs work. We’ve spent 2026 working out what needs to improve. To integrate with developer tools, the test suites need to be robust and specific. That means complete browser and Assistive Technology (AT) Tools used to help disabled people navigate their devices and the web. tests, a support status computed from their results, and machine-readable output. The owners of Baseline Identifies the availability of web platform features across popular browsers, including APIs, CSS properties, and JavaScript syntax. This project is owned by multiple stakeholders including Microsoft and Google. and Browser Compatibility Data (BCD) The browser-compat-data project contains machine-readable browser (and JavaScript runtime) compatibility data for Web technologies, such as Web APIs, JavaScript features, CSS properties and more. BCD is used in web apps and software such as MDN Web Docs, CanIUse, Visual Studio Code, WebStorm and more. have confirmed this work is a crucial precursor to integrating with both.

Why it matters now

The owners of BCD and Baseline have put accessibility data on their 2026 roadmap, and Baseline’s governing group has said it is “hoping to fill that gap by collaborating with [ACD]” (Perfecting Baseline).

30% of web developers in our May 2026 MDN survey believe Baseline “Widely available” includes accessibility. It doesn’t.

[ACD is] the kind of data that could one day complement Baseline.

Source: Baseline: a feature adoption strategy for the web by Samsung Internet Developer Relations

Developers feel the gap too. Michael Fürstenberg wrote that it’s hard to tell whether an issue is a browser problem or an AT problem, and asked for “an up to date list of supported aria attributes per browser.”

[ACD is] a larger accessibility effort than Baseline offers.

Source: accessibility experts, Sara Soueidan and Adrian Roselli

Adrian Roselli’s widely read post, Baseline Does Not Really Cover Baseline Support, documents that Baseline excludes accessibility support entirely and encourages readers to support ACD. Interest reaches beyond English-speaking countries: Mitsue-Links, a Japanese consultancy, has publicly encouraged support for ACD. ACD is also listed in the W3C ARIA Working Group’s repository as a known web platform accessibility testing initiative, alongside ARIA-AT The assistive technology test suite which includes tests for patterns defined in the ARIA Authoring Practices Guide and some HTML web-features., WebDriver and Acacia.

Deliverables

Deliverables are worked in priority order, as funding allows. Each has a fixed price and is complete once all its acceptance criteria are met.

  1. D1

    HTML web-features WPT tests that can be consumed by ACD

    Seeking funding

    Fill in test gaps in WPT.

    Acceptance criteria
    • AC1.1 All tests identified for HTML web-features as requiring modification have been updated accordingly.
    • AC1.2 New tests have been written for as many of the identified gaps as feasible within project scope, with any unfilled gaps documented and justified by the ACD team.
    • AC1.3 All new and modified tests have been merged into WPT upstream.
    • AC1.4 The set of new and modified tests is reviewed and approved by the ACD team.
  2. D2

    HTML web-features ARIA-AT tests

    Funded by the Sovereign Tech Fund · In Progress

    Fill in test gaps in ARIA-AT. We will expand the ARIA-AT test suite to include tests for HTML web-features.

  3. D3

    Create API for ARIA-AT to receive test results

    Seeking funding

    Pull in test results from ARIA-AT support data.

    Acceptance criteria
    • AC3.1 The ARIA-AT app doesn’t have technical debt blocking the implementation of the API.
    • AC3.2 The ARIA-AT team and ACD team have jointly agreed on and documented the data format that the API will expose, including all fields required by the Accessibility Compatibility Dataset Collector (ACDC) The application that collects data from Web Platform Tests and ARIA-AT to produce the final dataset (ACD)..
    • AC3.3 The API is publicly accessible and does not require authentication to retrieve test results.
    • AC3.4 The API returns test results in the agreed data format for all ARIA-AT tests relevant to HTML web-features.
    • AC3.5 The API has been implemented in the ARIA-AT codebase and merged upstream with approval from the ARIA-AT team.
    • AC3.6 The ACDC can successfully retrieve and process results from the API.
    • AC3.7 The API and its documentation have been reviewed and approved by both the ARIA-AT team and the ACD team.
    • AC3.8 Documentation is published, including a technical spec for API implementation and developer docs for API usage.
  4. D4

    ACD Collector

    Seeking funding

    Build the collector in JavaScript which will publish the support information as machine-readable data for downstream consumers.

    Acceptance criteria

    M4.1: Decision framework for WPT

    • AC4.1.1 The framework defines explicit mapping rules for all WPT results supported by the ACD Collector at the time of implementation, mapping each to one of the four ACD support status values: Supported, Partial Support, Not Supported and Unknown.
    • AC4.1.2 The framework specifies how to handle missing or absent test data, and maps that condition to an explicit support status value.
    • AC4.1.3 The framework accounts for browser-specific results, such that support status can be determined independently per browser.
    • AC4.1.4 The framework is documented in a human-readable document that stakeholders can review.
    • AC4.1.5 The framework is implemented as a JavaScript algorithm that the ACD Collector can execute directly to produce a support status value from incoming WPT data.
    • AC4.1.6 The written document and algorithm are consistent with each other.
    • AC4.1.7 The framework has been reviewed and approved by the ACD team.

    M4.2: Decision framework for ARIA-AT

    • AC4.2.1 The framework defines explicit mapping rules for all ARIA-AT data inputs supported by the ACD Collector at the time of implementation, mapping each to one of the four ACD support status values: Supported, Partial Support, Not Supported and Unknown.
    • AC4.2.2 The framework specifies how to handle missing or absent test data, and maps that condition to an explicit support status value.
    • AC4.2.3 The framework accounts for AT-specific results, such that support status can be determined independently per AT.
    • AC4.2.4 The framework is documented in a human-readable document that stakeholders can review.
    • AC4.2.5 The framework is implemented as a JavaScript algorithm that the ACD Collector can execute directly to produce a support status value from incoming ARIA-AT data.
    • AC4.2.6 The written document and algorithm are consistent with each other.
    • AC4.2.7 The framework has been reviewed and approved by the ACD team.

    M4.3: Machine-readable data

    • AC4.3.1 The JSON output includes a support status value for each HTML web-feature web-features is an effort to build a shared catalog of features of the web platform. By creating a common list of features and their definitions, web-features aims to improve understanding of what web developers get and want from the web..
    • AC4.3.2 The JSON output includes support status broken down per browser and assistive technology combination.
    • AC4.3.3 The JSON output is versioned.
    • AC4.3.4 The JSON output is publicly accessible.
    • AC4.3.5 The JSON output is structured so that it can be consumed by MDN, CanIUse and Baseline.
    • AC4.3.6 The JSON output has been validated against the agreed ACD schema.

Team

This work is led by Lola Odelola and Cynthia Shelly.

  • Lola Odelola

    Founder, Lola’s Lab · W3C TAG co-chair

    ACD began at Lola’s Lab. She’s a W3C ARIA Working Group invited expert and previously led the Web Platform Program at Bocoup, including its work on ARIA-AT, WebDriver BiDi and BCD. She now contributes to the Servo browser and the Core-AAM and WebDriver specifications.

  • Cynthia Shelly

    Co-Founder, Scaled A11y · Editor, Core-AAM

    Cynthia co-founded of Scaled A11y accessibility consultancy after 25 years in web accessibility, including 20 as Microsoft’s and Google’s representative to W3C accessibility standards groups. She was a major driver of the HTML Accessibility API Mappings (HTML-AAM) HTML Accessibility API Mappings defines how user agents map HTML elements and attributes to platform accessibility application programming interfaces. and Core-AAM specifications this work tests against, and continues to serve as Editor for the Core-AAM.

Previous and current funders