About this talk
In this talk, Rowdy, a Google Developer Expert in web technologies, discusses the importance of accessibility in web design and development. He emphasizes that accessibility is a universal right affecting approximately 1.3 billion people worldwide who have disabilities. The speaker highlights various forms of disabilities, from visual impairments to cognitive disabilities, stressing that good design benefits everyone. He introduces the European Accessibility Act and covers the Web Content Accessibility Guidelines (WCAG), which include key principles and success criteria for accessible web content. The session also showcases the Playwright end-to-end testing tool, demonstrating how to automate accessibility testing with Axe for better compliance with these guidelines. By illustrating common accessibility issues and their fixes, Rowdy advocates for early incorporation of accessibility in the development process.
Full transcript
All right, welcome. Hi, my name is Rowdy. Uh I'm a Google developer expert in web technologies. And in my day-to-day job, I'm a front-end focused senior developer engineer uh with special focus to uh usability and accessibility. And I'm doing that at NN, Nationale Nederlanden, one of the sponsors here. And if you look at this number, these are 12,288 days. 33 years, 7 months, and 23 days. Who
is younger than 33 years and 7 months, 23 days? Thank you for making me feel very, very old. Because 12,288 days is the number of days I'm employed by Nationale Nederlanden. So, that means it's quite a good company, right? Otherwise, I would have moved on. And it might be a good company for you as well. We are hiring. Come talk to us. Do a nice little word
game with us and win some great prizes. All right, let's talk about Accessibility, in my opinion, is a universal right uh because it also gives you access to other rights, like voting, employment, health care, and education. And if you can't enter a building or can't access a website, you're essentially being denied your citizenship, your accessibility to anything. One out of six people in the world are uh
have some kind of disability. That is 1.3 billion people on this globe. That's not a little number. And if you look at real in real life how we deal with accessibility, well, not so great sometimes. Because you can see uh well, we can see, but if you can't see and you need to use these tiles to walk around the city, you get a headache if you if
you walk here. And you can also see that it seems like to be an afterthought accessibility because the pavement probably was already there and they uh made a little road to to have those tiles in there as well. Another way of bad accessibility in real life. Go to this sightseeing point, right? Good luck getting up, that's one, but getting down? Not great. And if we look at
digital accessibility, I created this website for uh an insurance company called Developers Insurance. Um it might look nice, it might looks great, but I know it has eight uh eight problems, eight accessibility problems. We'll come back to that later. If we think about digital accessibility, we often think about making our products accessible to people that are blind. And to be uh to be fair, a lot of
things that you do, we do for blind people because they are using either screen readers or braille uh devices to be able to visit your website or application. But there are way more uh forms of uh disabilities. What if you have a permanent disability by missing limb, so you only have one arm for instance? It would be very nice if you can use the website with one
arm, so only using the keyboard and don't have to switch to a mouse for instance. So there you have a permanent disability, but you can also have a situational disability. If you are carrying a baby on your arm for instance, you only have one arm available as well. In my case, I would would be wearing uh I'll carrying a cat on my arm, but you get the
idea, right? Or maybe you have an eye infection and your sight is a little bit blurry. You want to be able to read well, you need good color contrast on the website. But And also means that people that are sitting outside with a laptop or their mobile device uh and with sun on the screen also need a lot of uh good contrast. So, here you see two
things combined. What about if you're deaf? You want to have subtitles or captions on your videos, otherwise you have no idea what's what's going on. But for me as a native Dutch speaker, if I watch something in a different language, I'm I'm not uh acquainted with, I like captions or subtitles as well. Uh so, it also benefits me in this case, while I'm not deaf. And also
my girlfriend really enjoys that if I'm doing it 6:00 in the morning in bed on a Saturday morning, not having the volume on, but just watching the subtitles. And another example is cognitive uh disabilities. You might have dyslexia. And you want to have things that are clear for you, buttons that need to be easy to find with nice text on it, easy uh text to read as
well. Well, if you're tired, you will benefit from that as well. All these things combined is called the curb cut effect. This is the only AI thing in my talk, a horribly rendered image uh because you know, the cur- the cut curb is in the middle and the the the the proper way to walk is on the side. But, okay. this curb cut is made for the
woman in the wheelchair to make it easy to get on the curb. But, it also benefits the woman with the stroller, for instance, or the guy with the packages, or maybe even the dog that might be old and has problems walking over a curb. And also the biker that shouldn't be on the curb, but hey. So, doing one thing for a particular group will mean or might
mean that you do something for other groups as well. Since June last year, we have the European Accessibility Act. That means that you need to be accessible. Your digital products need Especially if you're a B2C company. If you live deliver products to customers like a web shop or like we do with our uh our products, you need to be If you're B2B, if you're only dealing with
businesses, you're not uh it's it's not mandatory to be accessible, unfortunately. Because that means you can ship to businesses. you know, those businesses also have people working with a disability. So, why make a difference? So, please always make sure that your products are All right. Talking about accessib- accessibility, that means we have some guidelines. And those guidelines are in the WCHG or WCAG as we usually call
it, the Web Content Accessibility Guidelines. Those guidelines have four principles: perceivable, operable, understandable, and robust. Those four principles together have 87 success criteria. So, there's a lot of things that you need to or might need to adhere to. The success criteria are divided in different levels. So, A is the bare minimum. AA is like more or less the middle that everybody needs to comply with. And then
you have AAA, triple A, that means you're really going a long way for accessibility, which means for instance, having sign language videos on your website, for instance. Usually, most companies, AA is enough. the W3C organization has an overview of uh guidelines. And if we go there, it says a quick reference, but there's a lot of information there. And it's not really easy to use. It doesn't look
very pleasant as well. So, my go-to is WCAG in plain English by uh Art Spark. That really makes it more uh easy for you to find things. It's categorized it guidelines, but also at levels. And for instance, who is affected. And if you scroll through, you can see what levels it is, what which WCAG version. And the benefit the most uh proba- the most wonderful thing is
if you click it open, you get more explanation. Like, what is it? Who benefits? Why does it matter? And also get some extra uh information on how to uh implement stuff. But, we want to automate things, right? That's what we do nowadays. For that, we can use a tool called Playwright. Playwright is an end-to-end testing tool by Microsoft. And you might have heard of Cypress or Selenium
as well. Uh they do more or less the same thing, but Playwright is is the the is the lead currently. They have the best tools for this. To be able to use Playwright in your product, you run this on a command command line. PMMK Playwright. And let me say on the end, I have a QR code and a link with all these slides and also link to
GitHub, so you can see it all there. If you run this command, you get four questions. Do you want to have TypeScript or JavaScript? Well, to choose choose TypeScript nowadays, of course. The test folder name. And if you are running CI in GitLab, uh GitHub, sorry, GitHub, it can already create a GitHub action for you. And whether you want to install the browsers or not. Always do
that. And what you get is two new files, a test configuration, which you can alter later if you want to, and you get an example test to see how things work. Those example file has two tests in it. And of course your package JSON and your lock file will be changed as well. If you run this by MPX Playwright test you see that you have six tests
running in six workers and six pass. But the demo file you get from Playwright only has two tests inside of it. So, why is it running six tests on six workers? Well, by default it's running on three different browser engines. So, it's running on Chromium, which is the engine behind Chrome, Google Chrome, and Microsoft Edge. It's using Firefox, and it's using WebKit, the engine of Safari. So,
it will run those two tests on all the browsers, so it's six tests. And also they run in parallel, so it's quite fast. If everything succeeds, you only see six pass, that's it. Um but you can still ask a report on how uh your tests were doing, and you can get some more information. I'll show an example later on. To do accessibility testing in Playwright, we can
make use of Axe. And Axe Core is the package that's created by DQ, and DQ is a company that does a lot for accessibility, and Axe Core is also open source. You might have seen this, Lighthouse in Chrome DevTools. And everybody goes for the three uh four times 100%, right? Yeah, we have an great performance, great best practice, and great uh search engine optimization. And we are
100% accessible. That's a damn lie. I'm sorry. Because Axe core can only test about 30% of those 87 success criteria automatically. And maybe even not 100% of that test, maybe only partial test. So 100% score in Lighthouse for accessibility doesn't mean that your whole page is accessible. Please keep that in mind. But it will find the best it will find the most common errors in pages. So
we want to add X core to our Playwright test and then we can do that by adding it to our dev dependencies like like this. X core at Playwright at X core / Playwright. And then we can start writing our first accessibility test. And this is a very basic one. We we get we get further on with some more extra information. So I'm importing test and expect
from Playwright test like you do at any test you do with Playwright. But I'm also using the X builder from the X core package. I'm creating a test and I get the the page object to interact with later. And I say well, this page should be I go to in this case a local page that I'm running. You can see async await. Every test in Playwright is
async await. Keep that in mind as well if you're writing test. So I'm going to this local page. This local page you've seen it before is my lovely home page for this is insurance Next up, I can say to the X builder, you know, this is my page. Please analyze it for accessibility. And I get the the results back. In those results are the violations if And
what I'm saying here, well, please check whether the violations are equal to an empty array. So I don't want to have any violations. Running that is again with NPX player I test, but I'm now specifying the test itself as well, my basic test. And I'm using dash dash project chromium to say, well, only test it on the chromium engine. Don't run it on all three engines because
for accessibility it's fine to only use one engine, but because it's not about rendering stuff, it's it's about what's in the document object model of your page. And as I said, the report part here is a report that I create that I got from my And it should be accessible, but you can see there's a red cross in front of it, meaning something went wrong. And if
I look into that, you can see I have 457 lines, more or less. This is a great or a big JSON object. Not really helpful, right? It's It's hard to read. It's red, so it's in your face already. And also if you look at the test steps, you can see a lot of evaluating weights. And that's X core running those tests against your page. So this is
also cluttering a lot. We can improve on that. What we can do, for instance, this is still the same. What we can do is add something called test.step. That means we aggregating everything that's happening in between in one step in the report. That makes it a little bit better to read as well. Again, I'm saying analyze this page, please for me. But now I also enter I'm
also using test info and test info is what's in the report available for you to add stuff. So what I'm doing here is I'm attaching the the JSON that we just saw in red, I'm adding it as a attachment to my Makes it a better to read already. because I'm adding that to as a report, I don't need to see all errors on top as well. I
just want to know, do I have errors or not? So, what I can do now is going to say, x x results.violations.length, I expect it to be zero. No problems. No violations. I'm running this with a the different file but with the same command. And now you can see my report here. It said I expected zero uh issues, but I got eight. And if you scroll further,
you can see here in the test steps, I now have an accre um a combined thing of run accessibility scan. You can still open it if you want to, but it's is more cleaner. But more importantly, if you go to the attachments, I now have axe results as an attachment. I have still have that JSON object with that might be overwhelming. But I also have the help
URLs now I can click on to go to the DQ website to see what's going on there. But we can still improve on this. Because there's something called the axe HTML reporter. Great open source project as well to make it a little bit more readable for us humans, let's say. So, I'm adding this as a dev dependency This is still the same as I had before. I'm
attaching still attaching the axe uh the the JSON object. But I'm adding something in between. I'm using create HTML report from the axe And I can ask them ask it to create a HTML report out of those axe results that I got from the test. I give it some extra options here, the project key, that's more or less the title of the of the report. And you
can also add if you want to, you can also add for instance the uh the file name on the folder structure if you want to. And again, just like the uh the raw let's say the raw output of the JSON object, we can attach this to the test info report. And I I'm attaching it as an HTML file um with all the information Again, I'm running this
same but just a different test file. Still not accessible because I didn't change anything, right? But if you look here, okay, this is still the same the errors. Steps are still the same, but you can now see I also have HTML file. And if I click on that, now I get something I can read and I can work with. Right? You can see I have eight issues.
That's already what we saw earlier, but now we know exactly what it is. One of them is a best practice and the rest are violations of WCAG rules, WCAG And you can scroll through it and you get some more information as well. By default, Axe runs in a certain way, but with adding the with tags to the command, we specify which rules we want to use. So,
by default it's WCAG 2.0 from 2008, 2.1, 2.2, level A and AA, and also DQ's best practices. But there are more options. You can also use the AAA if you really want to go far, and there are some experimental rules by DQ which might up which might end up later on into the best practices. Our team test on everything except the AAA. you can choose why you
want to test on and why you need to adhere to. If you look at the European Accessibility Act, 2.1 is enough, but 2.2 is there as well, so why not test on it and make sure that it's accessible. So, the way to limit more or less say limit or extend the way you you want to test on, you can use dot with tags and uh have the
tags in an array. You can also exclude stuff. For instance, we develop in view and view has nice dev tools nice dev tools. this panel is totally not accessible. So, if I'm running the test locally with the dev tools running the dev tools there as I will get violations. So, what we do is we exclude this particular panel on the class name. We can't fix it. Uh
we don't ship it to our customers as well, so we can exclude it. If you have a part of your website or your application that you know of is not access accessible, but you don't have the time or the resources at this point to fix it, you can also exclude a particular ID for instance or a class as well. But, please take the time to fix it
So, here is my report again. Let's look a little bit on how we can fix stuff. The website again. So, the first one is heading level should only increase by one. This is a best practice. This is not a way CAC uh guideline, but it's it's a great way to make sure that people that use a screen readers more or less have a table of contents and
have a natural flow of things because it's just chapters essentially. So, we're going from H1 to H3 here. Just make sure that the second one is a H2 instead of an H3. Uh headings should be used for semantic reasons, not for styling reasons. If if you need to have let's say the uh the way an H3 looks like, use CSS for that, please. The next one is
that the HTML element didn't have a language attribute. It's easy to add lang is English in this in this case. And this means that screen readers know which voice and which language the they need to use to pronounce it to the user. Also, if you have in-browser translations, it's nice that the browser knows, "Oh, this page is in English." And it doesn't have to guess for you.
This also is one that's happens quite a lot, that images don't have an alternative text. You saw that image on the side. Um if I don't set an alt attribute, a screen reader will hear the full file name. That doesn't say anything, and it's rubbish. So, make sure you have a good alternative text. Uh about maximum about 100 to 150 characters. And this is the second time
I'm I'm mentioning AI. You can use AI to interpret the image and write uh hopefully a good alternative text for The fourth one, that's also one that's pretty common that's that's that's done wrong, is that if you you have inputs, but you don't have labels for those inputs. And that means if a screen reader will read out that input, it will only say type whatever. That's it.
Input. But you don't know you if you're if blind, you can't see, you don't know what you have to input. Is it the name? Is it the banking account? Whatever. to be able to hear, "Enter your policy number," you should connect the lay make a label and connect it to the input with for an ID. That's the best way to do it. And now it's you have
an easier way to style uh enter your policy number as well with CSS. The fifth one is links should not be the single must be the single without relying on color. You will see it later on but the text is black and the link is blue. It's really hard to distinguish and that's because in my CSS I had said text decoration is none so don't have an
underline there. Well, please in your body text always underline your links. Because that's what people come into. It's easier to distinguish. It's okay as I've done here in the navbar in your navigation to not have them underlined because people understand that if something is in a menu that looks like a menu, it's clickable. The sixth one is that list should have list items. The the top example
is I'm using this and using this means semantically totally nothing. So, if you have a list like an unordered list or an ordered list, use list items. This also means that screen reader users can get an overview of that list and otherwise is list and nothing is in there. Again, a language attribute but this time I gave it a another valid value. I have a quote on
my page and I said that language is French. Well, the language is FR to do it correctly and why do you do this? Because then a screen reader can also switch to a French voice and pronouncing the quote in French. benefit of this you will see later that I'm using open and close quotes on my quote. Specifying this as a French quote will change the quotes as
well. That's that's an extra you get. And of course, everybody knows French knows that this means works on my machine, right? Always works on my machine. And the last one is zooming and scaling should not be disabled. Uh in my header in my head I had a meta name view port and with maximum scales uh 1.0 and use cable no, I made it impossible for users on
mobile devices to pinch and zoom. And it's really annoying if your eyesight is not that great, right? So, never add that. On the good part is iOS since version 10 or 11, I think, completely ignores this. It will always allow the user to zoom. I'm not sure about Android. But yeah, just don't add that. So, if I run the test again, now I have zero violation. This
is what we want to see, right? This is the page that has it was. Look at the small differences you get when I made made those changes. Like the you know, the headings are a little bit bigger. If you don't like that, change it with CSS. Um and also look at the quotes. You know, these are just quotes as we have in Dutch and in English. But
these are the French quotes. Get that for free. So, here are the little example and also of course, yeah, the here click here is now underlined. And please, this is not tested by um Axe for instance, but please make sure that you don't use click here, read more because it doesn't say anything to a user if you are here that. One small thing about automating accessibility audits,
keep in mind that it's still 30%, right? Not everything, but it takes a lot of things uh already. No matter what CI pipeline you're using, is it Jenkins, Azure, GitHub, GitLab, Bitbucket, whatever, there are three rules I like to use. Run it on Chromium only. Make sure that failures do not block deployments on test. We've had that and that's annoying because you just want to test something
quickly. You don't want to uh have that block, but make sure that failures should always block merging to main. And I want to finish with this. Um keep in mind that if you bake chocolate uh chip cookies, you can't put uh chocolate chips in in it when it's baked already. It's very hard, right? You can maybe melt it and have it on top. That's nice as well,
but you can't put it in. The same goes for accessibility. It's very hard to make accessibility changes if your product's already finished. Start early. Please do that. And with that I also want to say that core um capabilities of developers, front-end developers, should be HTML, CSS, and accessibility. If you do HTML well, it's accessible by default. And then think about JavaScript and your frameworks, et cetera, et
cetera. Please. With that, I want to say thanks. You can meet me at the booth later. Come join us. Have a little game. Um at this link or this QR code, you can find the slides and the and the link to the GitHub repository with all the examples in And I'm 30 seconds over time. I'm very sorry that for that, but thank you for joining me and
enjoy the rest of the day.
