Hi, I'm Taslan Graham and welcome to my talk on automated web accessibility testing using playwrightjs and Ox core. First, a little bit about myself. I am a full stack software engineer from Jamaica. I primarily develop web applications and I am mostly interested and focused on node and JavaScript technologies. What's on the agenda for this presentation? First, we will look at what is accessibility? Why is accessibility important? We will also look at the web content accessibility guidelines WCAG. We will also look at the WCAG principles of accessibility. We will look at common accessibility issues. We will take a look at what is accessibility testing? And then we will finally look at automating accessibility testing. So what is accessibility? Software? Accessibility refers to the design and development practices that make digital applications, website and software interfaces usable and navigable by individuals with diverse abilities and disabilities. It involves ensuring that all users, including those with visual, auditory, motor or cognitive impairments, can interact with software comfortably and effectively, thus providing equal access to information and functionality. Accessibility also deals with how websites are structured. Are they using proper semantic HTML? Are they easily navigable with assistive technologies? Now, why is accessibility important? First, inclusivity and equal opportunity. So when you design with accessibility in mind, you are able to create a software or an application that is more inclusive to a wider range of users, regardless of any challenges that they may have. Accessibility is also good because it makes it easier for assistive technologies to be used to navigate your website or your application. When you design with accessibility in mind, you also expand your user base because now your software or your website, your application, it is now accessible to a wider audience of users. Also, it improves user experience. So many of the features of accessibility is beneficial to all users and not only users with some form of disabilities such as for example, if you were to add alternative text to images that is both beneficial to normal users and users who may have visual impairment. Accessibility also helps with search engine optimization. When you develop with accessibility in mind and you follow certain accessibility practices such as ensuring that all HTML pages have a title and other practices such as ensuring that images have can alternative text, you usually get better search engine optimization and then search engines will actually rank your websites higher. Finally, accessibility is a legal requirement. Accessibility is a legal requirement in some countries. The web content accessibility guidelines so the Web content accessibility guidelines WCAG are technical standards on web accessibility. Developed by the Worldwide Web Consortium, the guidelines aim to make websites, apps, electronic documents, and other digital assets accessible to people with a broad range of disabilities, including sensory, intellectual, learning, and physical disabilities. The WCAG has a set of principles, a set of accessibility principles which we should follow when we are implementing accessibility into our applications and the principles of accessibilities are one perceivable. This means that you should make it simple for users to see and hear the content in your application. You should present text alternative for nontext content. You should provide captions and alternatives for multimedia content. You should create content that can be presented without losing meaning when using assistive technologies such as screen readers. Another principle is operable. This means that you should make all functionality accessible straight from the keyboard. You should give users sufficient time to read and use the content that is being displayed. You should avoid using content that might trigger seizures. You should also facilitate users to navigate and find content easily on their web application. Understandable. This means that you should build text that is understandable and readable for users. You should create content that appear and operates in a predictable manner. You should also develop your application in a way that helps users to avoid and correct errors. Your application should also be robust. This means you should maximize the compatibility of your application with present and future tools. Also, elements in your web application should have a start and end tags and they should be nested according to their specifications. You should also aim to provide a name, role and value for nonstandard user interface components. Now, what are some common accessibility issues? A common accessibility issue is missing alternative text on images. Missing alternative text for images is one of the most common accessibility issues in web design. According to web Aim, 31.3% of homepage banners actually miss actually does not have an alternative text on their images. Another accessibility issue is poor color contrast. This is one of the most common accessibility issues noticed on many websites. Poor contrast makes it difficult to read content on your website. Poor HTML heading structure improper use of HTML headings, that's h one to h six, can make reading your website content unorganized and very confusing to navigate. Additionally, assistive technologies such as screen readers uses headers to navigate websites. Therefore, if you have improper header header structure on your website or improper header hierarchy, this will make navigating website using assistive technology much more difficult for persons who rely on such technology. Missing area attributes area attributes are a set of attributes that can be added to HTML elements to enhance the accessibility of web content. These attributes provide additional information to assistive technologies such as screen readers in understanding and interacting with web content. Area attributes help to make dynamic and interactive web applications much more accessible. Missing form labels is another common accessibility issue and when form fields form input fields don't have a label, it makes it difficult for users to understand what exactly they are supposed to enter what information this form field is trying to capture, and for users who rely on assistive technologies such as screen readers, it becomes even more difficult as the screen reader is unable to determine and inform the user of the type of information that they are supposed to enter into a particular form field. Keyboard inaccessibility is also another common accessibility issue and this is where websites or applications are not navigable via keyboard input. Also, not having a mobile responsive design is a form of accessibility issue and this will make it an unpleasant experience for persons who are using mobile devices as they will not be able to properly access and use your website. So now we move on to understanding a bit about accessibility testing and the first question we have to answer is what is accessibility testing? Accessibility testing deals with testing the features of a web application in a ay that ensures that all users, irrespective of most disabilities, will be able to interact with the software to its full potential. This includes allowing disabled users to perform all key actions without external assistance and making the application inclusive for all users. So, with the general understanding of what is accessibility testing, the next question to answer is what is automated accessibility testing? Automated accessibility testing can a website's underlying code and existing content and flag errors based on the web content accessibility guideline? It is important, though, to note that automated accessibility testing is not a replacement for manual test, but it should be used in conjunction with manual testing for a more holistic testing experience. And this will allow you to capture unique accessibility issues that an automated test cannot capture. And also the automated test will allow you to easily capture some common accessibility issues that might be a bit more tedious to capture in a manual process. Some of the common issues that accessibility test that automated accessibility testing can capture is missing area attributes, missing alternative text and images, poor color contrast, missing landmark labels, missing page titles, and these are to name a few of the things that can be captured. So now we move into some of the tools that we will be using to perform automated accessibility testing on a web application and the first tool to look at is ax alley engine. So Axe or Axecore is an accessibility testing engine for web applications. It enforces a number of rules and best practices to help you easily catch and fix accessibility issues. It's fast, secure, lightweight and was built to seamlessly integrate with any existing test environment so you can automate accessibility testing alongside your regular functional testing and with this ability to easily integrate it within an existing test environment, makes it easy for you to introduce accessibility to testing to an existing project. The second tool we will be using is playwright. And playwright is a framework for web test and automation, and we can integrate playwright with Axecore to perform automated accessibility testing. All right, so now we will take a look at how we can set up automated accessibility testing in a project, and then we will demonstrate how we can use that automated accessibility testing to capture some accessibility issues. And then we will look at how we can introduce that accessibility testing as a part of our CI CD pipeline in GitHub. Okay, so we have this very simple website here, and it actually has a number of accessibility issues. And what we are going to do is we are going to implement the automated accessibility testing as a part of our test suite in the application so that we can identify some of these issues. Now, as mentioned in the presentation, the tools we will be using is Axecore and playwright JS. So let's just take a quick look at those. So I'm on the GitHub page for oxcore, and as it says here, axecore is an accessibility testing engine for websites and other HTML based interfaces. Also makes mention of the rules that axecore checks, and it has different types of rules. WCAG 2.02.12. .2 it also has a link to the individual rules. Each rule has an id, a description. It gives the impact of that particular accessibility issue. So it has three impact levels, moderate, serious, and critical. It also provides a link to a page where you can learn more about the particular issue. You can see examples of cases where it would pass, and also example of cases where that particular issue would pop up. So let's head back there. The other tool we will be using is playwright, and specifically we will be using playwright test alongside Axecore playwright. And Axecore playwright is a package that actually makes the axecore engine available or accessible within the playwright testing framework. So let's head over to our code editor to get that set up. So the first thing I'm going to install is Axecore playwright, and then I'll install the playwright package. So to do that, we actually say NPM init playwright. At latest, it will ask a series of questions. Which language am I using? I say Javascript. Where do you want to put my end to end test? I go with the default. I won't add a GitHub action. Do I want to install the browsers? No, I won't install the browsers. I'll include that step as a part of the actual execution of the test. I'll choose no. After we set up playwright, we'll notice a couple of things being added to our code base. So first we have a folder test for end to end test as some simple test case. There's also a test examples folder which has more functional test in there. And it has a playwright config JS file. And this is where we actually configure the behavior of playwright. So we tell it the test directory should it execute in parallel. The reporter here this is telling playwright how do we want to have it actually report any accessibility issues to us? And there's a number of options we have list line junit Json HTML I'll actually stick with the HTML. I'll remove this section. And the projects section is actually where playwright configures the different browsers that the tests will actually get executed on. So we have a configuration for Chrome, one for Firefox, and one for Safari. All right, so first thing I'll do is I'll make an update to this file. I'm actually using ESM. So I need to update this import statement and update the export. I'm also going to delete the functional test. I'll rename the existing test. So I'll call this home page since we will be testing the home page of the website. And I'll just replace this with the actual test code. So let me walk through this. So what we have here, we import the test and expect from playwright. And we went ahead and configured our test. We then navigate to the particular page of the website. It's actually the home page. So we navigate to that page and then we actually set up an instance of the axe builder. And the axe builder is actually a class that you use to configure the behavior of the accessibility testing. And the most simplest form is actually what we have here, which is just new Aux builder. We pass the page information. So that's the page that playwright is currently on. And then we call the analyze method. And the analyze method will actually check this page against the different accessibility rules. We store the results in a variable accessibility scan results. And then we have a simple expect statement where we're expecting that the accessibility scan results should be an empty array. Now let's execute this test by running NPX playwright test. All right, so when we run the test, it actually prints out, it prints out the issues that it found. It prints it out to the terminal. However, because we had indicated that we wanted the reporter to be can HTML, it also opens a web page where we can see more information about the particular issues. Let me zoom in a bit. So for each issue that our accessibility test discovers, to typically follow this pattern where it has a description so looking at this first issue, the description is ensures the contrast within foreground and background colors meets WCag two wa minimum contrast ratio. If we scroll down, we see that it has an id. And this id actually makes it very easy for us to go back to the axecore documentation and find more information about that particular accessibility issue. So if we head over here and go to the list of rules, we can actually find it by the id and there's a link to further documentation explaining more about this particular issue. Also, there's a help URL property in the results, the test results, and it provides a link. And that link actually takes you to a web page where you can learn more about that particular issue. It gives more information. So it gives information on the background color that's being used. Also gives information on the foreground color that's been used. And it mentions the contrast ratio. So the expected contrast ratio for accessibility is 4.5 to one. We can see here that the actual contrast ratio of the website falls short. And if we scroll down some more, it also provides the HTML line of code that was checked when this particular accessibility issue was discovered. So this line of code here, where I have a link with teams as the label for that anchor, that's the line of code where we actually discovered that contrast issue. Now, if we scroll down, there's a lot of contrast issues. It's another issue. So this one is opensource. Each HTML documents document contains a non empty title element. And this is indicating that our website page of our web page actually does not have a title element. Once again, it provides a URL to our web page where we can learn more about this particular accessibility issue. Provides an id that we can use to easily find this accessibility issue. If we are looking at the axecore list of rules, it shows the impact. So the impact. There are three levels of impact, serious, moderate and critical. So for a missing HTML tag, a missing title tag, it's actually an impact level of serious. So that's pretty much a breakdown of how playwright and axecore reports accessibility issues that's discovered in your application. So I'm going to head back over to my code editor and I'm going to open a pr with what we have here, which is we have simply added the automated accessibility testing. I'm going to open a pr, and then after opening a pr, I'll also go ahead and add this test as a part of a CD pipeline. All right, so if we head over to a browser and go to the git repository to create the pr. All right, so at this point, as you can see, there's nothing happening here in terms of accessibility testing. So what we're going to do next is actually add a GitHub workflow that will make the accessibility testing a part of our CI CD pipeline process. So first add a GitHub folder. We have a workflow file here called CI and we're configuring it to run on pull request. So whenever you open a pull request and whenever you make subsequent commits to that pull request, this particular GitHub action will get executed. We're running it on an Ubuntu platform. We set up node 18, go ahead and install our dependencies. We will then start the server, and then afterwards we will run the test. So that's the general flow of how this particular GitHub workflow will operate. We'll set up node 18, install our dependencies, and then start the server, then execute our accessibility test. So one more thing is we need to have a test script npm run test, just double checking that's actually there. With this workflow now added to our code, I'm going to commit this. And what will happen is that this will result in the accessibility test being executed on our pr as a part of our CI CD process. So know if I head back over to my browser and go to repository, we now notice that on the pull request we're actually seeing the test being executed. So let me click on that's and at this point it's installed in the different browsers. So we can see here that the workflow got executed and the accessibility test got executed as well. And it discovered the different accessibility issues that we have. And once again it gives sufficient explanation about each issue that's discovered. It provides the impact level. It also provides the HTML code that's causing this violation. It also provides the URL, the help URL, which gives you more information about that particular accessibility issue. So we can see here that our accessibility test got executed as a GitHub action, and what we could actually do is upon resolving all the accessibility issues, we could eventually configure our repository to require that these tests to require that this accessibility test successfully passes before we're able to actually merge in a pull request. However, I am not going to demonstrate that as a part of this demo. So this actually concludes my demo. So thanks for joining me as I discuss automated web accessibility testing using playwright, JS and Axcore. If you'd like to get in touch with me, these are my social media handles on Instagram. It's at taslang on Twitter. It's at taslanagraham on LinkedIn. It's Taslan Graham, and my email is taslan@taslanagraham.com. Thank you for joining and I hope you enjoyed this presentation.