Hello, welcome to my talk. Sustainable Web. Accessibility. What and how I would like to start with the definition of a web accessibility given by a worldwide Web Consortium. Websites, tools and technologies are designed and developed so that people with disabilities can use them.

More specifically, people should be able to perceive, understand, navigate and interact with the web and as well contribute to the web. You might ask yourself, what is it about sustainability in the topic? Well, in my talk talk, I'm not gonna uh focus on the sustainability as taking care of the environment, but more about um on the ability to uh to maintain accessibility standards at a certain rate or level, hopefully greater than zero. Uh Because I think that accessibility is more like playing chess, it doesn't make sense to memorize all the steps. It's more uh moves, it's more about learning and understanding strategies to win because accessibility should be an inherent part of your development process before we're gonna go to the tooling and methods, how to um do this. I'm gonna, I, I'd like to set the stage for, for this talk and talk a little bit about the um framework or this current situation in in many it projects, um accessibility often is added on top maybe just before the release like a penetration test. And that's why it is considered to be a hustle to be costly, which does not have to be if you and if you integrate it just at the very beginning, many teams don't have um a dedicated budget for accessibility and um many teams don't have the necessary skills in this area.

That's why in my talk today, I'm gonna focus on the low hanging fruits, what tools are there already and what tools can uh built in tools or some free tools that we can use. Now, um Another aspect that I want you to bear in mind is that accessibility is not zero or 100%. It is a continuum from less accessibility to more accessibility. Um And at that point, I'd like to quote Christopher Patno, head of accessibility and inclusion at Google. Was that something which is not good as a whole is better than nothing that is perfect. So please make the first step towards more accessibility and this is already valuable because only once you've started, you can get better before I dig deeper. I'd like to briefly introduce myself.

My name is Maria Corva. I am a human being. I have a phd in linguistics. I'm a Google developer expert in Angular. Um Currently, I'm freelancing as a front end technology lead and giving courses in angular and my accessibility course is in proper. So stay tuned for uh later updates. Let's start when I was researching for this talk, I discovered a lot of tools and a lot of different tool groups and names principles, et cetera. So it was a chaos. I didn't know how to structure it. So for this talk, I I decided to come up with a metaphor to help understand what's out there in the market and how we can use it. Let's embark on the journey towards more accessibility and talk about accessibility as a car. So I, what I discovered is that the tools themselves are just a technical implementation. What is at the heart of the tooling is the knowledge about accessibility and the accessibility requirements. So the heart of the car is the engine and the heart of accessibility tooling are the testing engines which provide the rule sets or checks for accessibility requirements. X score is one of those testing engines. This is the most well known, I guess. However, there are of course others as well. So I have also discovered accessibility checker engine wave tenant A RC or ALPHA accessibility checker. Those are all the rule sets. They know where to look once we have that.

Once we have an engine in our car, we can move on to the browse extensions, which is the first group of tools. Um browser extensions in in my metaphor are something like measuring the oil level because you know, you have a problem only when you measure it, only if you look into it, if you don't do it, everything is fine. So uh one of the tools which is already built in in our uh chrome browser is lighthouse and you might already know it uh from different aspects of web development. And once I tested light lighthouse, I discovered that they actually link to the rules uh from the export rule set and lighthouse covers just 10 to 12 20% of all the rules that export has. So in here, if you are, if you want to dig deeper into browse extensions, you might install one of those. And here is a quick example um for the browse extension um X core, I have just a simple website here that I've developed. And if I run the diagnostics, which is that you can uh once you install the plug in, you can find it here and you can see that I have seven issues I have, I can see here the level that I'm testing for.

And here I see also some information on those tests. Besides a score. Of course, all those rule engines that I've already mentioned have um their browser extension too. You can check wave sigh and proof, accessibility, checker, accessibility inside stand and many many more. And you can also check um for which browser stores are available. Moving on the next part. Let's talk about testing tests are the lightning system in my metaphor because you have low beam, which is something like unit test. So you see something just in the close proximity and you have high beam. So you can see something uh remote and which could be the end to end test in, in in the web development world. So uh with the rules rule engines that I've mentioned, we have several plugins in uh for the existing frameworks. For example, we have a plug in for just but also some specific plugins for Amber React view. And for end to end testing, we have some extra plugins for Cypress, Selenium, lame R uh web drivers, et cetera. However, there are also some tests that are not based on those rule sets testing library, for example, is a general pur purpose library. However, they embrace the accessibility in in their core so that they provide the getters or the selectors which are not based on the idea of the element but rather on its accessibility role, area roles, area stands for accessible rich internet applications or by um a attributes, et cetera.

So that you um and you, you deal with your applications as the users would do. The next group of test frameworks are focused around screen readers. Um back a couple of years ago, it was not possible to uh test it automatically. However, now you can already write assertions for your screen readers using guide pub JSON back testing library. For MVD I or assisted web driver. However, for this test, for those tests, you have to bring a bit more understanding on how screen readers work to be able to write correct assertions. Next one, Linters, linters are the brakes. So if something happens, we're able to stop, to throw an error and uh to warn about some, some problems in our code because linters provide static code analysis. And here again, based on the testing engines that I've described previously, we have several plugins. Elin is the most well known and a common widespread lin. So for um Elin who has several plugins, for example, for GSX for viewing, for lips, for coffee script. Um but also there are also some plugins which are not based on the rule engines, for example, angular provides its own a set of rules and they all um their own requirements. And here just a quick demonstration. I have the project, an Angular project which I've just demonstrated.

It doesn't matter um what components that we have there. But if I run with several linting rules that I've added in my configuration here, I see that my L complaints about the image um elements that don't have the uh alternative description, I have some warnings. So um in here, I have an automatic check for some accessibility issues. There are also some lenders for specific parts of the application, for example, HTML lenders or ST of all plug in which checks your CS S files and not necessarily a lender, but with the same functionality, we have an add on uh for storybook which um adds an extra tab with accessibility information for our web components so that we see straight away if there are some problems.

Till now, our car was static parking in some standing in some parking lot, but we would like to move on. We'd like to go on the journey and for that, we need some tires and wheels and that's the metaphor for continuous integration, continuous delivery. Um We would like to um improve our website to develop new features, et cetera. For this. There are two groups of tools that um I was able to discover. The first group is um all the tools that checkers for our pull requests. Excellent or excellent for github actions, check every single pull request and you are only able to merge it. If there are no violations, there are further tools such as lighthouse CIA interaction, accessibility inside scan and Poly, which you can integrate in your C I CD. Um And which will additionally check for for the requirements. And of course, all the tests and all the linters that I mentioned before can be also integrated in the pipeline so that if there are some issues, there will be no deployment next step, autonomous driving A I is booming. And um in here, I'd like just to um well to think about the future and how A I could support our users in the future and our development process as well.

So first of all A I could be integrated into the web design design stage and analyzing some potential issues like low contrast et cetera. A I could also enhance our screen readers and uh add some useful information even for the for the websites which are not optimized for screen readers. Um With that, yeah, I could also tailor interfaces for us if someone prefers to increases the uh phone size every single time I could do that for us automatically improving the overall user experience um captures uh live captures are already there for several um conference tools like teams or for some videos on youtube.

And I could provide even more captures for just videos or audience integrating the websites or even some summaries for tables for graphics, for any other non textual information on our website. And with that, we can maybe even go uh further and uh provide voice interaction for our website so that the user don't have to interact with the screen reader or tap through the whole application, but could immediately say where he or she wants to go. It comes at a price. First of all, we should mind the privacy and we should not spy on the assistive technology, we should not spy on some specific usage. However, we should also mind the bias because all the information uh about all the um requirements and all the um possible disabilities should be present in different data sets sets because only then if we train our A I systems, they could be truly inclusive. At the end of the metaphor, we need the fuel. So what is the fuel, the fuel and our for our car is the mindset, the motivation and the skills, the mindset for accessibility for the accessibility means that we are willing to stop our release if there are some accessibility issues.

But even if we are not still, we have to, we should do more stuff, we should be willing to improve ourselves with every single interaction, motivation as well and the skills. So, and there are plenty of courses on web accessibility which are provided free of charge. So with those three, your card is really ready to go and remember that I, what I've said in the beginning, it's not about 100% or zero. It's the improvement with every single step. Just only once you've started, you can get better. And with that, please please start. Thank you for your attention. And if you have any questions, feel free to, to approach me on Twitter, on linkedin or maybe here. Thank you very much.