Speaker 1: Today, we discuss accessibility, the practice of making your websites usable by as many people as possible. When we hear accessible, we normally think about people with some disabilities, but you could also think wider than this. People with slow internet, people using small laptop screens, people who use cheap mobile devices, people who don't like using mouse. Probably one of them might be benefiting from the accessibility improvements that you are making. Okay, I still see that you are not convinced, so here's why you should care. First, is the law. It is illegal in many countries to discriminate, so if you have customers with disabilities in those countries, you might be sued and fined. Brand image. Caring about accessibility will demonstrate good ethics of your company and improve public perception of your brand. SEO. Using semantic HTML, like form, table, header, and other elements over generic divs or spans, as well as using special attributes, will make it easier for search robots to index your content, therefore improving rankings of your website. Four, it benefits everyone. Working on improving accessibility could improve usability for all customers. For example, optimizations in order to accommodate for slow internet users will improve user experience for everyone, even people on broadband. Now we understand what it is and why accessibility is important, so let's try to figure out how to measure it. First, I want to point that accessibility needs to be built-in. It is hard, expensive, and painful trying to add it at the end of the project, so when starting a new project, always ask, how are we going to measure accessibility? Unfortunately, you cannot do an accessibility test in a fully automatic way or at least do it well. Yes, certain things could be checked in an automated fashion, but you will require an experienced human to finish the evaluation. There are estimates that tools can do 30, 40, maybe 50% of all checks, and it's easy to get a false sense of security and we are done kind of thinking based on the tool evaluation result. Let's look at three methods of evaluating or testing accessibility. Method one. Google Chrome has a built-in Lighthouse plugin. If you want to learn more about DevTools, check out my other video, the link will appear here. Let's navigate to this page and open the DevTools and go into Lighthouse and you can see that we could click accessibility and generate a report. You can see that it gives us actually a pretty good score of 93 with just one concern that buttons don't have accessible names, but also it gives us an additional item to manually check that we could go and evaluate. Also don't forget that the Lighthouse is not the only extension that you could use. There are many more like Wave or Accessibility Insight or some others. Method number two is looking into Accessibility Tree. To enable it, you need to go into the elements tab and then go into the accessibility here and say enable full page Accessibility Tree. Then you need to reload the DevTools and this icon will appear allowing you to toggle between the normal DOM view and Accessibility Tree. So let's try it. How to understand it? To make it simple, you could think of it as information that the browser will give by Accessibility API to the screen readers. If you are as a human getting confused while looking at it, there is a high chance that the screen reader will not read it correctly and confuse the user. So let's look here. For example, we can see that there is a link to the Google, there is a combo box search, button clear, button search by voice. It's kind of readable and makes sense. So I can give a kind of high degree of confidence that the screen reader when reading this page will do a good job. Now let's look at another example that doesn't have a lot of built-in accessibility. No offense to the author, but it's a classic example of the 1990s website that used table as a layout. So the problem is that tables are not very accessible. So if I toggle the accessibility view, you could see that there's like nothing in here. And even if I dig into the table rows, it's just one big blob of text of everything. So I can give a high estimation prediction that most likely the screen reader will not be able to read properly. To confirm our suspicions that this website doesn't have a lot of accessibility, let's look at the Lighthouse report. It shows 63, which is, some people can say that this is a decent number and there's like not a lot of complaints, but we have just seen that the accessibility tree is very bad. So that is why you cannot, I repeat that, you cannot really, really trust the automatic tools and you need to perform manual evaluation of any website. This brings us to the method number three. The hardest one is actually learning and understanding WCAG spec. WCAG, some people might pronounce it as VCHG, is an acronym for Web Content Accessibility Guidelines. This spec might look a little bit overwhelming from the first try, so let me give you a high level overview and you can better navigate it. There are five major groups or principles which are here. So the content must be perceivable, meaning the content should not be invisible from human senses like vision or hearing. Operable, meaning that the content, the interface should be accessible by, let's say, keyboard and mouse. Accessible, meaning that the content shouldn't be hard to understand and the layout should be easy. Robust, meaning the content should be accessible for different user agents like browsers or assistive technologies and so on. And the conformance, which is just an explanation of how to achieve the conformance with this spec. So the important thing here is these three levels, A, AA, and AAA. These basically go from A, which is a minimal level of compliance with the spec, or AAA, meaning the amazing level, sometimes even non-achievable. So let's look at some of the examples. Maybe look at this one. You could see that it's a level A item, which means that it's easy to achieve or should be easy to achieve. But it means that if you're tabbing through the page and you reached, let's say, an input for maybe username, then when you tab again, your focus should leave this component and move on the next one. But if we look at, for example, this one, it's a AAA one, and it means that all functionality or the content of the website should be accessible via keyboard. This could be very, very hard to achieve, and sometimes you have to even write an alternative version of something to allow conformance with this success criterion. Now you know enough to get started doing some accessibility testing. Let me know in the comments if you want more videos about accessibility. Don't forget that like and subscribe buttons, and see you next time. Bye. Bye. Bye.