Meeting minutes
lola: Thank you for attending, this is an overview session about Accessibility Compat Data
… I'm leading this endeavor, with the help of many
… I'm also co-chair of the TAG, and the W3C Docs CG
… I'm also an artist, I hate cheesecake, and I think you should too
[general shock]
… This is an issue that Adrian Roselli opened in BCD
… the <mark>, <del>, <ins> and other elements were not properly vocalized
… [example] VoiceOver would only communicate part of a sentence
… only n issue in Safari
… If I was a software dev, I might use CanIUse, and that would tell me these elements were well support
… and if I went to BCD, it would tell me it's supported
… baseline too
… available, supported, nothing wrong
… where would we submit this issue?
… BCD, Adrian opened them there, and it was decided it was out of scope because it was screenreaders
… because the issue wasn't in other browsers, it was determined to be the screenreader
… it wasn't known right away though
… Adrian was able to file the bug with the WebKit team, who determined it was a VO issue
… if it was a different combination, how would it have gone?
… If teams can't communicate, and Adrian knows these areas well, but how would a random developer approach this
… this is where something like accessibility compat data comes into play
… goals, define machine readable datasets for this data, get it into MDN, we want to make it searchable
… support developers to build accessible experiences, and support web users of AT
… hopefully it's obvious why it matters
… currently developers have no way to check if a feature works in a browser, there's no way to know what working means
… tools show browser support via BCD or Baseline, but accessibility information is not included
… Baseline gets info from BCD, BCD doesn't check the a11y tree
… other projects are out there, like a11ysupport, [other name]
… some of these are closed source, some aren't usable for devs, some have different focus
… ARIA-AT was focused on APG, not other sources
… ACD addresses these issues by identifying web features as they are developed, get into review at the right time
… immediately start planning what tests are needed in WPT or ARIA-AT
… I'm using my position on TAG to keep on top of what is happening
… Matt Atkinson, member of TAG and co-chair of APA, but that is not sustainable if I'm not on TAG
… we need a strucutured process with the horizontal review group
… want to make our tests part of WPT, the infrastructure is there
… it makes sense to contribute to what exists and take what we need
… we want to present the support data in places developers go
… hopefully this will help teams
… why now, I don't know how many have seen the MDN HTML 2025 survey
… under the education and learning banner, a11y was listed as a main pain point for develoeprs
… they need to understand a11y support
… when I was at Bocoup, doing a11y work and trying to figure out how to bring things to developers
… it's been a discussion for a long time
… a11y is a pain point for develoeprs and they are communicating that
… there is compliance pressure, it's not the main reason but it communicates priority
… we have EAA, other governments expecting accessibility
… WPT have a large test suite with tests that already cover soem things
… we have data out there
… we can bring it all together
… the ARIA-AT project, I worked on that at Bocoup, there was little interest in SR tests for WPT, but now there is interest where there wasn't
… how do we keep that conversation going
… the infrastructure needing to be build is minimal
… just to be clear, ACD is not an auditing tool, develoeprs can't use it to audit their websites
… there is a WebDX meeting later this week into considering ACD or other a11y data set into baseline
… we don't want ACD to be a baseline, we don't want people to assume they meet the criteria and its accessible
… its so you know what to use to build accessible experiences
… ACD [diagram], we pull from WPT and ARIA-AT to build compat data and send it to developers
… ACD feeds into MDN, IDEs, CanIUse
… who benefits?
… web users using AT will have more accessible experiences, room for improvement still
… web devs will have access to information on support features and problem areas in their codebases
… browswrs and AT vendors will see how their products perform
… browsers will see how their platform interacts with SRs and any gaps
… browsers are here, AT vendors are not, but there is no standard for them, standards bodies
… most ATs are OS-based, which is part of the complexity, we're web focused, but SRs consider the entire operating system
… what we need
… I've made a rough draft of a scraper that scrapes WPTs, insight into what is missing
… especially for older web features
… WPT is missing support for features and we need to make sure they are tests
… we're focusing on HTML AAM mappings
… many missing tests
… when I did the rough scrape, it looks like only 8 HTML AAM features have tests
… we need to write tests to fill in the gaps
… we also need better filtering options
… the way I am filtering is shaky, it cannot produce consistent results
… I'm pulling down WPTs, a test file can have multiple sub-tests, and how they categorize tests is not how we need
… we care about the subtests
… in one example, there is one computed name test, with subtests for elements, we would care about each element, then build out the further tests
… WPT doesn't have a way to filter on a subtest level
… I'm doing string pattern matching, it's flaky, they have a lot of contributors and no set naming conventions
… some tests have el-element-, and some don't, it's convoluted and unnecessary
… good news, Google and Bocoup are working on annotations to work on this
… better categorizing tests and cross testing
… thats a work in progress
… we also need SR tests, ARIA-AT is now looking to do SR tests for ARIA features
… we can reap the benefits of their work
… we also need funding
… we have had some funders
… a11yproject, open web docs, microsoft, mozilla, tetralogical
… Cynthia Shelly, we have support
<Zakim> dom, you wanted to compare WPT scraping to bcd-collector
dom: I'm curious about the approach to rely on the WPT data for browser support, I know it was explored for BCD, the conclusion was it was too granular
… for what BCD needs, which led to the collector which does more targeted testing
… has that been explored as an alternative
… if you look at all the ways tests are failing for supported feature, the definition of interoperable vs how people actually view it
… will you hit the same?
lola: ACD is significantly more complex, we may hit this
… BCD is only looking at the DOM tree, don't need the granularity
… with ACD, we need to test the a11y tree, do certain things happen, do properties change.
… if we add aria-label to an element, does the computed name chage?
… we can't do the checks like BCD does, with WPT we can pick and choose tests
… we can use the tests that make sense for us
… we'd end up replicating WPT if we didn't use it
dom: florian
lola: Maybe we'll have something ready
do you think WPT + annotations will make it possible to make that filtering robust?: Filtering, with ACD we're looking for info that is in WPT already
kadirtopal: WPT-related, with WPT are in the browser, what else is needed to complete this work
<tzviya> s/???:/ florian
kadirtopal: are WPT tests mostly testing things in the a11y tree?
lola: So both, there is an interop focus area and just deals with a11y
… they are focused on WPTs focused on accessibility, we'd combine those tests with the general tests
… the existing tests, aside or address, they just test that it works
… the a11y tests look at computed name and so on
… what else is needed? ARIA-AT
… some kind of screen reader testing section
… WPT's automated testing, SR testing is not there yet
lola: ATDriver is a new spec for automating AT testing
… I'm hoping screen reader testing can be automated because its expensive otherwise
<dom> AT Driver
lola: in this case specifically SRs, if we can put energy behind this work
… on Dom's point on the granularity, ARIA-AT is also very granular and we don't need it all
… part of AT Driver is looking at intents and more than what is vocalized
… JAWS, VO, NVDA, ACD doesn't care about how, only does it happen
florian: another thing that is needed is filtering the AT driver work, ACD format making choices for what do we test, create results
lola: Exactly, Florian has opened a PR on the repo, what the JSON could look like, allows for facilitation and integration into the tests
… we want to use the same shape and testing formats
florian: make it easier to adopt
cyns: There's also the acacia work Valerie is doing, there are layers, helps pinpoint issues, the other thing we need is writing bunch of tests
wendyreid: my team at ebay was looking at taking over allysupport
… I'm wondering if these tests that are valuable and good could be ported into ACD
florian: I've been looking into porting some of that data
… likewise for the data from Tetralogical
Daniel: Several things, according to what MAtt shared in ARIA WG, we're closer to better automation
… there's work in NVDA, in JAWS, Applescript
Daniel: there is a public in nvidia able to run the automated tests, work to include it in jaws
… and work with applescript for voiceover
… all of that is already happening
… re high-level approach, we should be careful in not missing key details
… e.G. moving from one heading to the next without moving scrolling will have an impact on what gets rendered
florian: when designing the ACD data format we were exploring what to express exactly
… not just a binary supported, but a list of potential issues (without expressing "it works")
lola: a lot of the data that exists on screen reader has "supported", "unsupported", "partially supported" because there are nuances
… some depend on user settings
… some are screen reader dependent based on product decision
florian: it's also that exposing differences might help convergence among screen readers
daniel: my worry is throwing away useful data towards that "high level" approach
cyns: it's also about writing good test cases - e.g. on headings, make sure it reflects the scrolling situation
lola: part of the challenge is keeping this interpretable by developers who already struggle with the level of complexity in the much simpler BCD
<Zakim> dom, you wanted to ask about assistive technology support beyond screen reader
dom: You partially addressed this, you talked a lot about SRs
… not the only AT
… I wonder how you manage extending to other ATs
… or manage the more political aspects of focusing on one
lola: Follow on ARIA-AT's approach, it feels like a place to start, SRs communicate to other ATs like braille readers, we may get some benefits along the way, with the goal of expansion
florian: Start small, then we can grow the dataset
lola: See the shape of the data
cyns: With the AT Driver spec, it helps there
vadim: in the beginning, you mentioned the bug, there are also unsupported features and ones deliberately not supported
… browsers are opinionated, have reasons
… SRs are much more opinionated, and much different
… there are already three levlels of not supported, and maybe a fourth, the user intervention of disabling or modifying features
… how you you plan to suport
lola: Great questions
cyns: SR testing are done with defaults
lola: Even ARIA-AT keeps to defaults, and modes
… how we manage the three levels, that is where communication comes into play
… to understand the decisions behind the data, we need to build relationships with the affected parties
… we have relationships with the browser
… if we can find out that something is intentional
… we can document it
vadim: WebEngines Hackfest, session on automated SR testing, they have minutes and slides
lola: There's acacia, funded to work on it, it'll have a big impact
… the a11y tree lives in the browser, it communicates with 4 different platform APIs, unique to each OS, which goes to the AT, to the user
… acacia is looking at the relationship between the a11y API and platform API
… funding right now is only linux
keithamus: Had related thoughts, this diagram is helpful, it's true, browsers consist of different adapted libraries to different messages to different services
… Acacia's aim is to test those things
… on windows you do foo and macos does bar, and the SR does what it does
… what the SR picks up
… I'm curious wirth combos like browser + OS + At
… depending on the granularity of data exposure, we can go as detailed as specific combinations, it can be false on multiple factors
… it's only green when all the factors are true
… currently ARIA doesn't specify mappings for Android
… plus plus plus
lola: we haven't even started talking about mobile
florian: we've had a hard time figuring out the gaps in data, and where in the traffic light things fit in
lola: The knowledge of the ecosystem isn't even a guarantee of understanding
cyns: Some of the value of the work, same WPT test, if you have all these areas testing the different points, if all pass awesome, if one fails, finding where it fails, great
… right now it happens in slack or over beers at TPAC
keithamus: To conclude, if we have Acacia testing platform, and AT Driver testing the inputs to the AT, maybe we can connect the dots, we need that
… there's two tests if we know the two cases, if one fails or is wrong, you can find the differences, more tests in one layer
Daniel: Just to say, if there are relevant links to share, put them in IRC please
<Zakim> Daniel, you wanted to ask if links to the relevant materials have been posted to IRC
<jgraham> RRSAgent: make minutes
lola: Thanks everyone, this has been an amazing discussion
… please keep up with what we're doing!
<lola> aria-at: https://
<lola> acd: lolaslab/