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