This is a neat situation. We will have, effectively, back-to-back A11y talks. I'm giving a talk on Accessibility after lunch, mainly on how to focus on Accessibility with the entire software development life cycle. My goal is to give new information and, even more critically, NOT repeat too much of what the other talk is all about, so to that effect, I am here to both learn and filter my own presentation ;).
Enough about me; the rest of this will be about Chad Hester, our presenter, and his talk about "Accessibility, Automated Testing and AI - a Reality Check".
There are many ways that we can say that we are "automating" accessibility testing. The nice thing about web accessibility especially is that there is a built-in vocabulary that expresses accessibility compliance. It's not always clear-cut or obvious, but some tags and attributes exist specifically in HTML to pinpoint and determine if accessibility features are being handled (or not). There's an entire framework for this (WCAG), and if you reference certain areas in the WCAG spec, you can determine if something is present. If it is, hey, compliant. If not, hey, we need to do something about that.
So to that effect, yes, Accessibility can be and is being automated. You can do it for free with the axe-core library (axe-core is created by Deque Systems). axe-core lets you call the library, read the web page elements, and based on what's there, it can tell you what is not compliant. It's a big hammer, but it can drive big nails. It can be finessed with extra code to get to individual items, too. I'm seeing something new this go around: BarrierBreak a11yInspect, so I want to see what that is.
When “0 issues found” doesn’t mean accessible
I really appreciate Chad bringing this up early in the talk. Another thing to realize is that you can have a 100% compliant application, but it's miserable to use for everyone. Yes, everyone can use it, but how it's implemented may be truly sub-optimal. Automation will not tell you that. Humans need to make that judgement call. Automation can help find non-compliance, yes, but it can't tell you if your compliance is actually good or helpful.
WCAG is Ever Evolving
Often we look at WCAG as being definitive (think of it as the IEEE for accessibility features), but it's always evolving. To be most effective, we need to be aware of what version we want to be focusing our efforts on. WCAG 2.2 is the latest and greatest published version (as of 2023), but WCAG 3.0 has been under development and consideration for 10 years. Lots of cool things in it, but it's not authoritative or definitive, and things can and do change. It's a fun playground, and you can check out a variety of things, but if you want to be seen as doing the latest and greatest that's production valid, stick with WCAG 2.1.
Is AI an A11y?
Chad shared some examples of where AI was able to add value and what aspects they excel at. The WCAG rules, that's a no-brainer. Feed it the WCAG standard, and it can tell you if your code is compliant or not. That's a neat value add, don't get me wrong, but axe-core can do that for you too, with zero AI. My favorite statement, including when it comes to automation and AI, is "Tools Help, People Decide". AI in Accessibility will help with the mechanics, but it is no closer to making a true judgment call than automation by itself is.
