Scaling a11y

Hello and welcome at my talk about scaling accessibility. We will talk about how to achieve a sustainable digital accessibility. My name is Tim Dama. I'm a frontend developer and accessibility lead at the ABN AMRO, which is a bank in the Netherlands. And if you want more information about me, you can visit my website if you'd like.

Without further ado, let's start with an introduction to accessibility. And I like to start this introduction with real-life accessibility features like these tiles. You might find them in train stations or metro stations. Guiding people, sighted people along the way. Or elevators, of course, helping people in wheelchairs, for example, or people with a stroller, with little kids. Making life easy to go up and down in big buildings or metro stations, for example. And last example, traffic lights, where you have the colors indicating when to stop or when to go. But also the ticking sounds. You might recognize it when the light is green. Ticking sound goes faster. When it's red, it goes slower. And these are all examples of real-life accessibility features, which we have built together to make life easier for ourselves. But also for people with disabilities, these features are built with accessibility in mind. And I would argue we should do the same when building on the web. When building frontend applications, for example. And our lives as frontend developers, for example, is made a little bit easier because accessibility is built into the web already.

Yes, why do we say this? Because the creator of the web, Tim Berners-Lee, said a long time ago, said time, the power of the web is in its universality. Access by everyone, regardless of disability, is an essential aspect. So, the web was created with accessibility in mind. We just need to utilize it to create accessible web applications. And of course, over the time, the web evolved and developed further. More JavaScript and more complex CSS features came in, which made the web a little bit less accessible. But nonetheless, these same accessibility features still are available. We just need to use them. So, summarizing a little bit.

Digital accessibility is about creating applications that are accessible for everyone, regardless of disability. And talking about everyone, for example, these people, this big group of people using your app or website or web application, the group of people, which is 1.3 billion people included experience significant disabilities, according to the WHO. So, these are people using your app.

So, I'm talking to a lot of front-end developers, a lot of developers at JS Nation, which is why I like to share this graph with you of this organization, WebAIM. They do a lot of great things about surrounding accessibility. And what they do each year, they conduct this research, and they research a million different web homepages and they test on WCAG figures. And what they found is that 95.9% of all these homepages do not comply with the WCAG figures on them. So, they are not accessible. So, I would encourage everyone to, after this talk, look into the topic of accessibility and try to improve and try to create more accessible web features for our users.

Talking about WCAG, it's in the title right here. For the people who do not know yet, WCAG stands for Web Content Accessibility Guidelines. And WCAG are the internationally defined guidelines that provide a baseline for web accessibility. And 2.2 is the latest version of WCAG. And if you want, after this talk, you can go to this URL I shared and look up on the specifications, for example. There's lots of great information on the WCAG on this page, specifically about all of the requirements and meaning all of the success criteria within the WCAG. There are a lot of different guidelines, and a lot of different information for you to find out. And WCAG is also used in a lot of legislation around the world. For example, also in the EU Accessibility Act that's coming up next year.

And WCAG is also used in a lot of legislation around the world. For example, also in the EU Accessibility Act that's coming up next year. Die.

So we did a little bit of an introduction. We talked about WCAG. I showed you a nice graph of how bad we are doing. Let's now talk about some roles and responsibilities within an organization that you need before you while you're scaling up your accessibility.

So what you want to have is an organization-wide approach to start improving on web accessibility. And what is really nice is if you have if accessibility has management support, so senior management support, saying that there is a person who has final responsibility for accessibility who preferably is close to the CEO. Die. And accessibility is included in eventually all of the processes, needs to be included in all of the processes for all of the different roles. And it's really nice if you have permanent budget and capacity for that.

If that's not the case yet, don't worry. You can start advocating for it. For example, me and myself and a group of developers and designers also started advocating for it within the Admin Envelope two years ago. And now we have priority, we have capacity and we have budget to work on it. So you can start small and start scaling up. Die. Die.

Also within a medium size to large organizations, development teams are structured in this way. So we have a lot of different development teams working on their own applications. And these teams, most of the time, consist of a PO, designer, developers, testers, for example. And the PO has a really important role to play when it comes to prioritization, of course, of accessibility. Also, he has more of an overview of whether or not the accessibility level of the team is high enough to start creating accessible applications. And the designer, developer, and tester, they're each in their own role need to assess if they can test on accessibility, develop in an accessible way, or design in an accessible way. They need to be up to date with the latest standards and guidelines, for example, with Baycoff, and need to have checks in place to... Die. Knowledge in place to start working accessibly. Die.

So this organization, for example, team A might be working on the application called Manage Contacts.

Team B is working on requesting new products. Team C working on product settings, for example. And team D might be working on the navigation. Die. Each team encapsulated within their own team works on their applications. And, for example, one main one or one main one and a smaller one together. But eventually they need to come together and they need to work together, of course. They need to use the same colors. They need to use the same font, same image, same logo. And this, of course, you need to work together also as one organization.

Also, when it comes down to accessibility, which is a combined... Should be a combined effort. Die. All right. So we talked about some roles and responsibilities. Now, let's talk about the topic, of course. How to stop releasing inaccessible features. For example, these teams, they're working nowadays a lot in agile scrum ways. So they are going in two-week cycles from sprint to sprint. And on a day-to-day basis, new code gets published to production. And most of the time, like 95.9% of the time, this code is not accessible. So we are releasing inaccessible features. Well, how to stop that? Die. First thing that you want to start doing is building up a knowledge base within your organization. Building up knowledge is something good to do for everyone, for every role. I should get, for example, an accessibility training, an introduction training. But there are also specialized trainings for developers, designers, and testers. You can go for certifications, for example. And what's also really nice, if you start doing that, is internal researching and knowledge sharing sessions.

And what's also really nice, if you start doing that, is internal researching and knowledge sharing sessions. For example, at the ABN AMRA, we have an accessibility guild on which, together, we are researching the topic and sharing knowledge within the guild, but also with other teams. Die. Die.

So building knowledge and testing is really important. Automated, manual, user testing, all very important. Automated, of course, utilize it as much as possible. But don't expect to catch everything with automated tests. About 20% to 25% of the bake-off, you can catch with automated tests. Manual testing is the way to go here, is where you get a complete overview of your bake-off issues, for example. And user testing is also really important. You need to test which end user and also include people with disabilities in this group, of course. Die.

So we have knowledge building, testing, and monitoring. Monitoring is also really a nice one to add to this list. Start monitoring on the issues, accessibility issues found, for example, per team, per grid, per block, whatever you're using. So you can see how much issues are still around, which team is doing better, which grid is doing better. And this makes also the combined effort of fixing accessibility issues really nicer to track. Die. And then we also need to talk about accessibility auditing. Auditing, testing, checking of accessibility. And auditing most of the time is used within organizations to get a feeling of how good the company is doing in terms of accessibility, and also is used as the way to get insights and feedback on the level of accessibility within the company. And also this is then communicated, of course, with the development teams. But I agree with Carl Groves on this one, and that is that he said audits and automated tools don't fix accessibility issues. And I will get into it a little bit more, explaining why, for example, the methodology that's used to audit on accessibility, the WCAG-EM method, has some caveats where for larger organizations with a lot of different development teams who are working on their own applications, getting the right feedback to these specific teams. Two things that I want to highlight. That is the large sample size. The WCAG-EM evaluation method prescribes that the sample size that the audit is being conducted on needs to be large for large applications. It can consist of like 20 to 25 different pages. And the second one is that it is not mandatory to show all issues per WCAG requirements.

So there are a lot of WCAG requirements, and not all issues need to be shown for each and every one of the WCAG requirements. Actually, only one is required. This comes with some problems when trying to build up the knowledge within the teams about accessibility. One is that because of the large sample size, a lot of different teams can be involved into one audit. And there's a potential to miss a lot of issues because of the large sample size and because of the fact that it's not mandatory to list all issues per WCAG requirements. This makes an audit really broad. Actually too broad to be used for the teams that need to fix their accessibility problems.

Also, the timing of when an accessibility audit mainly is done is, you can see it as in a waterfall way of doing your development life cycle. It's really done at the most bottom part of the waterfall. So when the code is already on production for a time, then an auditor comes in and he checks and sees everything and reports on it. And this, of course, is not a really efficient way to go back all the way, start fixing things.

Now, what happens is that and then after some months go by or half a year or longer, then again, an audit is done all the way at the bottom of the cycle. And you get into a cycle of auditing, fixing these things found, auditing, fixing. And this is not something that works for many organizations, which are a little bit larger and have a lot of different development teams. Because these teams, what they are doing, they are running in agile development life cycles of about two weeks. And the perfect moment to check on accessibility is, of course, in every step of the way. So not only during testing, but also developing, everywhere in the perfect world needs to be checked on accessibility.

Of course, this is, if you do this, you have a really high level of accessibility already. But actually getting to this point, so building up the knowledge within each and every team to be able to do this, is the most important part. And that's where the accessibility feedback loop comes in. It's a lot on the screen right now, we will go over it together. Don't worry, we'll start all the way on the left with team A, development team A, they want to enter the loop. They want to enter the accessibility feedback loop. They want to make an accessible, their application accessible. So they need to comply with some of the prerequisites. These can be that you need to be using the latest versions of all the design system components, for example.

If they meet all the prerequisites, intake meeting is done with the accessibility team. And this team will do two things then. And there's two types of tests. So the wake up 2.2a test and an accessibility user test. And these two tests combined will say, all right, this application is accessible. Yes or no? Probably the first few times, or maybe a little bit more will be no. And then an audit improvement report is given to the team that is tested. And then in two or three sprints, they will need to have taken up all the issues and a re-audit after this time is done. So the accessibility team steps in again. Does the testing accessible? Yes or no? Well, first few times probably will be no. But after a certain amount of time in testing, it will be yes, of course, because this loop won't stop until we get there.

And then an accessibility certificate is given to the team. And then after a certain amount of time, they will need to go for recertification. So they will need to be aware of the knowledge that is then built up in the team, because they get feedback on their application and start the way they have developed their app and the way they have developed it in an accessible way. They now are shown on how to do it accessibly. So there's knowledge that's building up in the team.

There will also be recertificates on that. And a really nice way for teams to get this feedback. So per issue found on the application that they are building is for each issue in such a way is given. Starting at the top, we have a title, main menu doesn't work keyboard. And then in the description, the problem is described with rich text HTML, which, and this describes the problem in such a way that's understandable for the development team. And after that, a solution is also given, which could be the solution or just the direction the team might go in. At the bottom, you can see also some metadata pointing to the docs of the WCAG, for example, and also some other metadata like difficulty and severity, and the sample on which this issue was found.

All right. And to summarize now, we did an intro on accessibility. We talked about WCAG, roles and responsibilities within the organization, how to stop releasing inaccessible features, on which we covered accessibility audits, for example, and then we talked about the accessibility feedback loop. And I hope that you found these topics interesting and that you've learned something. I also would like to know about it. So if you contact me somewhere and tell me about it, I most definitely would like to know it and like to chat with you about it. Thank you so much for listening and taking the time. And I hope to see you next time.