Meeting minutes
Accessibility Compat Data
[[Lola shares screen]
Lola: Accessibility Compat Data. First time meeting most of you
Lola: Adrian Roselli opened a bunch of issues to the BCD related to mark, delete, insertion, and strike through
… VO in Safari didn't read the preceeding elements
… As a developer, I'd check CanIUse, which says all of these elements are supported, or I'd check the MDN table, where it says de delete element has been supported for a while
… O I may look at Baseline, with similar information
… So where would we submit these kinds of issues?
… He submitted against browser, but they closed them as out of scope
… He was able to file and issue with the WebKit team. However, if it was a different browser combo or developer had less experience, where would they go?
… This introduces ACD (Accessibility Compat Data)
Lola: Objective -- Define machine readable data sets to inform accessibility support.
… Different from ACT, which defines rules to test accessibility compliance
… ACD is about the specific web features
Lola: I'd like to integrate this information where they are already use to look for this info: MDN, Baseline, CanIUse, etc
… I'd like to make it easier to create accessible content
… I worked previously for Bocoup, specifically on ARIA-AT
Lola: Currently developers don't have an integrated way to tell if something that works on the browser would also work on AT
… When BCD shows something as supported, it's only looking at what's in the DOM tree, not even the accessibility tree
… Something can be OK DOM-wise but fail somewhere else down the pipeline (accessibility tree, AT rendering, etc)
… The current data sets for AT support are not integrated either
Lola: It's unclear how to let these tool vendors know when there are issues, and also some projects have different objectives
Lola: We want to write tests to track how features work across browsers and ATs
… And then present the data across developer-friendly tools to help spread the data
Lola: A recent survey shows that accessibility is the greatest gap developers want to cover.
… MDN has long received request from developers to help understand accessibility support
… There's also compliance presure, the EU has laws that came into place last year for web and mobile apps, the UK has a similar ecosystem
… The infrastructure is almost ready. We are trying to use resources that already exist, such as WPT
… They are actively maintained
… They contain a large test suite already
… Also add with Tetralogical and AT tests suites design to more specifically test screen reader support
Lola: ACD is neither a test tool nor an evaluation tool. It's here to identify accessibility gaps and help developers, as well as show these gaps to developer and AT vendors to hopefully close them
… We want to clearly indicate if screen reader supports an element and if there are gaps
… The browser speakas to the operating system, there you have accessibility APIs and then there's the AT, which speaks to the user
… We are experimenting with bringing this data from WPT and ARIA-AT
… The tool I created is automated for WPT and ARIA-AT is added manually at the moment
… We're looking to include this in MDN so that it's easier to use from IDEs
Lola: Web users who rely on ATs would benefit from this, as well as web developers and browser and AT vendors
Lola: WPT is missing a number of key tests, so we'll work towards including those
… As new web features become standardized we'll make sure they are covered
… We also need to improve the filtering so that data is more understandable and easier to present
… ACD will try to be an implementer for the autoomation that ARIA-AT has been working on
Lola: We need funds. We already have some funders but need more to continue the project
Wilco: If people are interested, how could they contribute?
Lola: We are in a transition phase at the moment. For now, if you can drop me an email that'll be the best way
<lola> lola@lolaslab.co
Lola: There's a slack channel
WCAG3 testing procedures review
[[Rachael introduces herself and shares screen]]
Rachael: WCAG3 -- we are working to get a draft out late Jan / early Feb
https://
Rachael: We have a set of requirements. A and AA, and then supplemental (linked to AAA)
… Assertions are not specifically related to ACT, requirements are.
… WCAG structure -- Guidelines, assertions, and requirements
… Aim is to write tecnology agnostic requirements for WCAG3
… Methods are where things would apply to a specific technology
… Some requirements are going to have to be devided up into several methods, others may do with just a generic method
… ACT-style tests would fall under methods
… We'd like to use the writing of ACT to drive and refine the requirements
[[Example of WCAG3 draft requirement]]
Rachael: We can pull pieces of existing test rules that would map to this specific requirement
Rachael: An example of a new rule may be in abbreviation
… Requirement format: top-level statement, applies when, and except when
Rachael: We'd love you for you to come to AG to provide training
… We have sub groups who will be doing the bulk of the rule writing
… We are aiming to get a draft for new rules of approximately 20 provisions a month
… Then we'd like for you to help the editors, work with them by reviewing the draft rules and providing feedback back to the subgroup
… Aim is to have at least one for each requirement by the end of 2026
Kathy: Perhaps ACT Rules are too technical for what you are looking to achieve here? Do we need to modify our rules for what we are looking for?
Rachael: I think these are appropriate for the HTML method
… I think we are going to have requirements that need to be more generic and may not be as technical. I wouldn't expect as technical of a rule for the abbreviation example.
… Do you think the rules can serve for this?
Jean-Yves: I think the ACT Rules Format can work for these less technical, but current expectation for us is to write heavily technical rules, maybe due to the background of most of our contributors
… We also have a lot of expertise in writing for HTML, we also may want rules for other technologies as well, and we have less expertise for these other ones
… Agressive timeline though, as you just said
Rachael: The expectation for the next few years is to focus on generic and HTML
… After those, then others may come
… The expertise portion is less of a concern.
… My hope is that this group gets a boost because most editors will be working on this
Helen: When I started with the manual test rules, I wanted it to be more agnostic but we struggled because we were advised to look for more of an HTML-centric approach
… Would like to aim for the less technical, but sometimes it can all get fuzzy when considering several scenarios at once
Wilco: Do you have an idea of a minimum time commitment for whoever wants to participate?
Rachael: I think it's a bit flexible. If you feel you have limited time, then I'd prefer for you to work with the editors to get them trained
… If you'd have a acouple hours, we'd be grateful because you could help them writing, guide them, etc
Wilco: Please think about what you may be able to provide
Wilco: Another thought. One of the most difficult parts is to be able to write the code examples. Do we have editors that could do this work?
Rachael: Yes, we have editors who could. If a rule was written, and all of the pieces except for the coding was done, would it be considered as a complete draft? We need to think about it? For the rules the coding is the informaitve part, we need that to be there for the rule to be finished
Jean-Yves: Agree, but I think when reviewing the rule, the examples are extremely important and can help under certain conditions
Rachael: What's example?
Jean-Yves: For me it's a bit the same
Jean-Yves: It will probably be just a matter of how we work
Wilco: We write a couple of rules a year at this point. When we were full-speed, we would be writing one rule a month
… We'd have to change how we do things, maybe by reducing the number of examples needed. Still we need some example and definitions
Rachael: We could use the maturity level for exmples and definitions. I don't want a loose sub groups exploring edge cases with fewer examples
Wilco: We could have examples without code, that's better than no examples at all
Rachael: It may be helpful to know what the levels are
… Because the sub groups are steeped in their expertise it may beome easier for them to write examples
Wilco: I wouldn't expect that
Kathy: It really scrutinizes sometimes the wording of the requirements. For example we've ended up having to create our own definitions
Rachael: This is exciting because it makes ACT work be included at the early stages and we don't have to it as an afterthought.