Improving Accessibility with ARIA-AT:
A Web Standards Case Study

• Lola's Lab
• W3C
• Aria APG
• Aria-AT Testing suite
• AT-Driver
• Bocoup
• Selenium
• Browser Tools & Testing working group

I'm not going to be talking about web security today.

I'm going to be talking about accessibility.

And I know we've had a few talks about accessibility already, but I'm hoping to bring another perspective to it.

Specifically, I want to talk to you about what can be produced inside of the web standards organization beyond just specifications.

And so I'm going to be using the REAT program as an example or a case study.

My name is Lola Delala, as has been previously mentioned.

I have been working in the tech industry for 10 years now.

July was my 10th year anniversary.

Yeah, thanks.

It's funny because I'm also planning my exit.

But we can talk about that in the pub.

And I came into I've done many different roles in tech.

I've been a software engineer.

I have been technical support.

And most recently, the next phase of my career was to do web advocacy.

And I started that at Samsung Internet, as Dave mentioned, under Dan Applequist, who is an amazing manager at the time and amazing friend now.

And my introduction to web standards was through privacy, which is why I was recommended to talk about security, which they're not the same thing, but they are closely related.

And so at Samsung, I really immersed myself into web standards and I really grew a passion for it.

And so since then, which was 2021, since 2020, maybe around then, COVID was still more and more happening.

It's still happening, but we were locked down at the time.

Since then, I have really, really developed a passion for web standards and it's how I intend to continue my career.

And so most recently, I worked for an organization called Boku and they are hired in collaboration with Metta and some groups, as we'll get into in the talk, to work on accessibility within web standards.

I am also the founder of Lola's Lab, which is a web standards and web education company.

You can speak to me about hiring me and giving me some money later.

And cheesecake is bad.

I just wanted to throw that in there.

I think we should ponder that.

I won't go further at this time, but again, we can talk about that in the pub.

Can I get a rough idea of how many people here have participated in web standards at all?

Okay.

Cool.

I wasn't sure what the turnout would be, so I just wanted to make sure everyone's on the same page about what the W3C is and what web standards are, so that we are all, like, aware.

So when people think about web standards, they really think about accessibility.

Which makes sense, but it's really not, despite my talk, it's not the only thing that happens in web standards.

So Katie earlier on did the web audio API.

That stuff happens in web standards as well.

Things like WebRTC also happens in web standards.

CSS.

Anyone a fan of CSS?

Yeah!

CSS.

That stuff gets discussed and decided upon in web standards too.

So just to give you a brief overview, we've seen this guy's face, like, 50 million times today.

But we're bringing him back, Tim Berners-Lee.

Tim Berners-Lee created the W3C, the World Wide Consortium, in October of 1994.

So today, not today, this year is the 30th year of the W3C.

And it was a space to standardize and build the web.

And just to be clear, when I talk about the web, I'm not talking about the internet.

The web is not the internet.

When I'm talking about the web, I'm talking about anything you can see and interact with in a web browser.

So that does not include mobile applications, smart devices, or IoT.

Literally, we're talking about Safari and Chrome and Microsoft Edge, things of that nature.

So now I want us to do an imagination exercise.

I want to create an API.

This is going to be a CSS API, maybe.

We don't know yet.

And the point of this API is to allow web developers to display paranormal activity on the web page.

Okay?

This is something that's going to change, revolutionize the web.

And the best way for me to do this as the person with the idea is probably to go into the W3C.

Now, the journey I would take to do that is to probably start with a community group.

In my community group, I would have a variety of different inputs.

I'm going to want this group to be as diverse as possible.

Right?

So in my group, I'm going to want ghosts, probably.

Maybe some spirits and demons.

I'm going to want people who can communicate with ghosts, whoever do that professionally or even as hobbies.

I'm also going to want CSS people.

People who code in CSS or people who build and work on CSS specifications.

I want this group to be diverse.

And I also want people who maybe have experienced paranormal activity for themselves.

Oh, sorry.

And so that felt a bit paranormal.

And so the point of this group is basically to decide how this standard should work, if it's going to become a thing.

How should this specification work?

What should it do?

There is no expectation to produce anything in this group.

It's really a discussion platform and it's free to participate.

Which means you don't have to be a member of the W3C to contribute to the work going on in this community group.

So one of two things or really one of three things can happen within the community group.

We can decide that actually we don't need paranormal activity on the web, so we're not going to move forward.

We can decide that we do need paranormal activity on the web, but maybe it shouldn't be a standard.

Maybe it should be some other kind of technical document.

Or we can decide it should be a standard and so we are going to write a draft specification for it.

If that's the case, we are then going to move into a working group.

And in this working group, the people participating gets a little bit more niche.

Really and truly because you have to pay to participate, it's really going to be member organisations of the W3C.

So you're going to see quite a few browser vendors in there.

People, representatives maybe from Safari or Chrome or Edge or Vivaldi.

You're going to see people maybe invited experts from the paranormal world.

And there is an expectation to produce some kind of document, usually a standard, a specification that has been agreed upon that this is exactly how Detect API should work technically on a very low level.

Sometimes though, it can be a guide, some kind of educational document and I am going to give a real example of that later today.

So I want to talk about the ARIA AT programme.

This programme comprises of three projects.

Some people think of it as two, but I like to think of it as three due to some recent developments, positive developments.

The goal of the programme is for assistive technology vendors to be more interoperable for developers to more easily create and test accessible web experiences.

Can I see a show of hands of people who use assistive technologies?

Things like JAWS, things like NVDA, voice over.

A small minority of you.

Can I see a list of show of hands of people who test their websites for the use of, oh more, oh that's so lovely.

The thing is I can't actually check so you could all just be lying, but that's fine.

So I'm going to go through each of these projects and explain in detail what they are.

First up we have the ARIA Author and Practices Guide aka the APG and I will be referring it as the APG from now on.

The APG is educational material and it is produced in a subgroup of the ARIA working group, which means that most of the participants in this group are member organisations of the W3C.

So it's not free to participate.

However, the guide themselves are open source, which means that technically anyone can contribute to the guide.

You can contribute on GitHub and we regularly do take external contributions.

The point of the ARIA Author and Practices Guide is that it's a set of commonly used accessible HTML patterns.

So an example of that is alert.

This is what alert looks like.

As you can see, it's comprised of a number of different elements to create one entire element kind of a pattern for alert.

This might seem similar to web components.

This isn't a web component because as Dave mentioned, a web component is not just the group of elements but also the stuff with the DOM and all of these other complicated things which Dave nicely explained and I forgot.

Web developers benefit from these guides the most and these pages get typically hundreds of thousands of views.

But more importantly, assistive technology users know that their devices can properly speak the page when we use accessible patterns.

As I mentioned, this work happens in the subgroup of the ARIA working group and it is unique that we do accept input from non members of the W3C.

And the next project is the ARIA testing suite.

This is available at aria-at.w3.org, I believe.

And who uses MDN regularly?

Great.

And so at the bottom of MDN pages for web features, you'll usually see the browser compact data, BCD, and it will show you which browser this feature is available.

This is very, very similar.

This testing suite produces similar data.

But what we are testing here is do these patterns speak similarly enough across assistive technologies?

So JAWS in Chrome, NVDA in Firefox, and VoiceOver in Safari, given this alert pattern, should read it similarly.

Because imagine how frustrating for those of you who don't use assistive technologies and I'm sure those of you who do use assistive technologies, how frustrating it is to go from your iPhone, which uses VoiceOver and Safari, and as we know, every browser on iPhone is Safari, on a specific page and have it read one way, and then go to your Windows computer and use Microsoft Edge and visit that same page and have it read a different way.

That can be disorienting, it can be confusing, and it's not a good user experience.

So this project displays interoperability data across assistive technologies and browsers specifically for the patterns in the APG.

This work happens in a community group, so anybody can participate in this.

The tests are written by test developers at Prime Access Consulting.

Tests are run by volunteers, and this benefits web developers because they can see the extent that patterns they use are spoken as expected.

And so this is an example of the interoperability data as it is in the testing suite.

The alert example is the second one, and as we can see, JAWS in Chrome, it supported 100%, NVDA in Chrome, it supported 100%, and VoiceOver for Mac OS and Safari, it supported 100%.

And then this is what it then looks like in the APG.

This data is the same data we just saw, and this exists on the web page for alert within the APG.

And so there's a kind of bidirectional communication happening there where we are creating these accessible patterns, writing tests for them, and then displaying the test data back on the pattern page.

So we've spoken about the APG as a set of accessible patterns that web developers can use in their code.

And the ARIA AT testing suite as interoperability tests for those patterns.

And now we're going to get slightly more technical by speaking about AT driver.

So the other two outputs, shall we say, one was an educational resource, one was a testing suite, and this is a specification.

It's not yet standardized.

We are going through the process of standardization at the moment.

The AT driver specification is an automation system that allows the user to collect AT responses from assistive technology.

If anyone is familiar with Selenium in their testing suite, it's a similar thing for assistive technologies.

So the specification details how you can possibly open and engage with a JAWS or an NVDA or a voiceover.

There is still work being done.

It's not standardized.

There's still arguments being had.

There's still a lot of drama.

But we're working through it.

We're working out.

And so this work is being done.

This work came about actually in the community group.

While we were writing the tests and building the testing suite, it became clear that having an automated way to engage with assistive technology would be really beneficial, actually.

And so Mike, who is my colleague at Boku, a very, very talented and great engineer, and Howard as well, are both leading the charge in that regard, building that and obviously the other talented engineers at Boku, just in case anyone from Boku is watching, I love you all.

But Mike is actually one of the editors of the AT driver specification.

And if anyone is familiar with WebDriver Bidi, no?

It's kind of what Selenium is, the specification that underpins Selenium.

So AT driver is the hopefully assistive version of WebDriver Bidi.

And so this technology, as I said, came about in the community group.

But because we want this to be standardized, we want this to be a technical documentation that underpins anything that any new technologies that are built to engage with the assistive technology, we have to move this into a I'm looking for answers.

Working group.

Thank you.

Yeah.

Well done.

So when it was decided we want this to be standardized, we had to look for the best working group to do this working.

You would think that might be the ARIA working group, since this was happening in the ARIA community group.

However, there's another group within the W3C that specifically looks at tools and testing for the web.

And it's actually the group that authored the WebDriver Bidi group, which as I said, underpins Selenium.

And it's called the browser tools and testing working group.

And so it was my job actually to kind of lobby a bit the group to be like, you should care about this thing.

This is a good thing to have.

This is an ideal thing.

This is the next step.

And it involved lots of conversations.

It involved giving workshops and detailing what the standard does.

It involved answering questions, myself and my colleague Mike.

And so the group eventually decided to add it to its charter.

And it's now on the well, it's kind of on the standards track now.

Yeah.

And so the benefit of being in the browser tools and testing group is that you have a variety of people in the group who are niche specialized, who have niche specialized knowledge.

You are working with people who have built other tools such as WebDriver Bidi.

You are working with people who have implemented ATDriver in some way or some form or who are interested in implementing it.

And you are working with people who are very intimately familiar with testing on the web.

And so you can kind of hopefully see how each of these projects are related.

APG and the ARIA AT testing suite have a bidirectional relationship.

And then ATDriver is used within the ARIA AT testing suite to automate the running of assistive technology tests.

And so that has been my talk.

I am Lola Odellala.

These are all the places you can find me.

I'm @lolladella everywhere.

I do run my own organization, as I mentioned.

You can talk about hiring me or funding projects.

I do have a few projects I'd like to run.

And yeah, thank you very much.

[APPLAUSE] [END]