 Hello everyone and welcome back to the State of the Web. The theme for today's episode is really important because you may have a fast website with the best content, but it's all for nothing if people can't actually use it. My guest is Nektarios Paisios. He's a software engineer on the Chrome Accessibility Team and we're talking about the state of accessibility. Let's get started. [♪ Music Plays.♪ So how would you describe your role on the Chrome Accessibility Team? I'm a software engineer. This means that I'm a programmer. I write code all day, which is something that I enjoy a lot. I implement accessibility features in Chrome and I also fix accessibility bugs. I mostly work on Windows and Mac accessibility, but my team has lots of other people who work on many different platforms and for lots of features that we release as part of Chrome OS. So how would you explain accessibility to someone who may be new to web development? Well, accessibility is a very important feature. We should see it as a feature of our website and it's part of usability. The more accessible your website is, the more usable it would be to everyone. So it doesn't only affect people with disabilities. If we want to talk about the people with disabilities, they are, according to the World Health Organization, 15% of the population. So even for a business reason, you could say that you're getting more customers if your website is more accessible. But aside from that, your website will be more usable if you abide by all the accessibility standards. If you follow all the best practices, your website will be both accessible and provide better experience for the rest of your customers. So it's a good business practice. It's the right thing to do, but also it creates the best experience for everybody. And what are the various ways that people with disabilities interact with the web? Depending on the disability that somebody has, they use different sorts of assistive software. One of this piece of software is called Screen Reader. So if you're blind, for example, you might be using the web through a piece of software that reads to you using synthetic speech. It reads to you the contents of the screen. That's why it's called a Screen Reader. If you're partially sighted, you might be using a magnifier. So you might be enlarging the size of the font, the size of the text, the size of the whole page, the size of the images, even the size of video. So there's different software that helps depending on the disability that you have. If you're hearing impaired, you might be using some captions or some software that can listen to what has been said and transcribe that into text. If you have another disability, like a motor disability, you could use a switch access, which is a device that allows you to move through the interface by flipping a switch or you could use eye tracking devices that track the movement of your eyes. If you cannot move your hands, you might be able to move your eyes. So by moving your eyes, you can move a cursor around the screen. So there are lots of different accommodations depending on the particular need. So what are some things that you wish even the more experienced web developers would know about accessibility? Clearly the web has offered a big opportunity for companies and organizations to show off their branding. Different websites have different layouts. They use different font sizes. They use different colors. They have different ways of interacting with them, different menu systems, different ways of navigating through them. Different workflows as a whole. This is very good for branding. Every organization wants their website or their web app to differ from other organizations. We don't want to have a monoculture. We want to have a platform that is full of life and diverse as possible. However, if you're a person with some accessibility challenges, it takes much longer for you to get accustomed to the different workflows that are presented by different websites. Let me give you an example. Let's say you're blind and you're using a screen reader. What do you have to do? Most likely is you need to read the web page that you're interacting with serially from top to bottom. And if, to get familiar with it, to familiarize yourself with it, it takes you time to, if the conventions are different from side to side, it takes you time to go through all the content just to be able to do, let's say you might want to sign up for a newsletter or you might want to order or buy something from that particular company's website. If the workflow for purchasing an item is different for each website, which for each website, which most likely it is, then it was gonna take you much longer to learn that workflow because you don't have the visual cues that a sighted person might have. The placement of icons, the placement of the different elements of the different buttons, you don't have a clue, you don't get those hidden clues. You have to go and discover them by reading the contents of most of the website. The same goes if you have a model disability, for example, you might need to use a hardware device like Switch Access to go through the contents of the site and if you have developed muscle memory that you know, for example, that if you press your Switch a specific number of times, you get to a particular feature on most websites, let's say the top navigation menu, but now you discover that for each website, the navigation menu on the top is not the same location. So you cannot really develop muscle memory with your assistive device. And you can imagine the similar issues with other groups of disabilities. So what I would suggest is try to follow existing conventions and this brings me up to my second point, not everybody uses the computer using a mouse or a phone using touch. They might be using some commands that come with their assistive software or hardware and those commands require that your site is accessible using the keyboard. And if your site is not accessible using the keyboard and it's a pointing device, then it might be hard for this assistive software or hardware to work with your website. Another point is there are lots of accessibility standards and the web content accessibility guidelines is one of the most prominent standards. And it's better if you go through those standards and try to follow as much as possible the guidelines that are out there. So that's one of the ways your website will be consistent with established patterns. The same goes for the keyboard navigation I described before. Another thing that you should bear in mind is if you don't actually test with assistive software, you're not gonna know the bottlenecks. You're not gonna know what issues your users are running into. So you could try some of the assistive software very easily. For example, if you have a Chromebook, you could easily turn on a screen reader that comes built into every Chromebook. You could turn that on and every command that the screen reader exposes is in a menu. So you can easily get to all the commands. It's not a very steep learning curve. The same goes for every other assistive feature on that platform. You can turn on magnification, color filtering. On Android, you can turn on a feature whereby you could use the volume buttons of your phone to simulate a switch access device. So somebody with a motor impairment that uses a hardware switch device, you could simulate that using the volume buttons of your phone. So these are some of the tips that you could rely on when developing. What would you say to developers who may be well-intentioned and try to be overly descriptive with, for example, their ARIA labels on elements and they might just say too much about an element? It's a bit funny, but there is this notion that if you have a disability, it means that you don't have the intellectual ability to understand what everybody else can understand. And that's actually not true. We don't need to go over the top when describing a UI element. For example, we don't need, if there is a button that, let's say, minimizes a video player, we don't need to say things like, collapses and reduces to a small size the video player and places it at the bottom left side of the screen. You don't need to say that. Just say minimize. And people will understand from the context that it minimizes a video player. Of course, we have to bear in mind that we have a group of disability users that are with intellectual disabilities or developmental disabilities. So we have to cater to those users by using language that could be understood by a ninth grade level. We shouldn't use complex and not very well-known words. But other than that, we don't need to go over and above and try to overcompensate. The other thing, though, that you should bear in mind is what I was saying before with the keyboard. If you want to test your keyboard navigation, you should not only use the tab key because tab is not the only key on the keyboard. So coming back to your previous question, what I wish to have developers knew is tab is not the only key on the keyboard. And if you look through, for example, ARIA, the rich internet applications practices for keyboard users, there are lots of shortcut keys that are listed in those practices and tab is just one of them. And that goes to the importance of using semantic elements on the web so that the screen reader can understand what type of content is on the page. Instead of using a div or a span element that doesn't convey any semantic information, it's better to rely on the existing HTML5 rich controls if possible. So let's say you want the user to enter an email field. Use the email input box. There is such a text field because an assistive software might provide autocomplete suggestions to a user, for example, if they detect that they're trying to enter an email. But if you don't use the correct control, the assistive software might not know that and offer no suggestions. The other problem is, let's say you want to enter a date. There is a date control. You're going to use a list. There is a list box control in HTML. Try and use those controls unless you really have specific reasons why not to. Most people have issues with the styling. I don't understand that. But if you are comfortable using the building controls, use them. And take your time to read through the new controls that came out in the last few years. There is an array of rich form controls. They said, number control. There's a telephone input. Do not ignore those controls. They might look the same as a text field, but under the hood, they are very useful to somebody who's using an assistive software. Right. So as the web capabilities have evolved over the years, people have started using the web in different ways. So what effects have trends like these had on the ways that users actually use the web? The development of the web has given people with disabilities a workaround. For many of us, including myself, I'm blind myself, including myself, we have been liberated in a way by the proliferation of web applications. Because if, let's say, you wanna go and visit a bank and make some transaction, you usually go to a bank and you have to complete some paperwork. And that paperwork, if you're blind, for example, you will need some assistance to help you do that. If you're deaf, the person who is at the bank, most likely doesn't know any sign language, you might have difficulty explaining to them what needs to be done. If you have a moderate disability, it might be, there might be no ramp, it's hard to get into the bank, and then you can go in there. So there are all sorts of issues when it comes to physical work, that they completely disappear when you use a website. A website also, and that's another great point to remember, doesn't have a bias. If you visit a place and you have a disability and people there, they don't wanna accommodate you, you might have a hard time convincing them that you have the right to be offered services. But a website doesn't know that you have a disability. And this has also opened up the employment market to people with disabilities who can, through their computers, they could perform the tasks that before they needed, for example, a secretary or an assistant to help them perform their work duties. Another thing is reading books. Let's say you have learning disability, for example, or blindness, it would have been hard for you to read a book. Now with their software that can read the book to you over the web, and also for people with dyslexia, for example, there are tools that help them break up syllables or read the book using text-to-speech, or have a dictionary that is on demand, and easily accessible on the computer or on your phone. So it's really easy to get accommodated through the web. And you can also feel very independent in that way because you're using the same websites and the same web apps as everybody else. So this is a very nice feeling. You feel that you are treated the same as every other customer of that particular business. However, on the negative side, the more complicated the web has become, the more important is for web developers to take care of accessibility challenges. Because on the flip side, if you do visit, let's say a supermarket and you're on a wheelchair and you have trouble going through the aisle or the supermarket, an employee might help you by fetching an item from the shop. However, if the website is inaccessible and you're a person with moderate disability that is relying on eye tracking device to use the website, and the website doesn't have very good, let's say keyboard navigation or some kind of navigation that the functionality that would allow that assistive software to interact with it, then this person is stuck. They can't really negotiate with the machine because the machine is inflexible. So yes, the web has removed a lot of the accessibility challenges. However, if we don't pay attention to the accessibility of our websites, we're gonna erect much higher barriers that are inflexible and cannot be removed by talking to a human being. Right, and one of the solutions to that is standardization. And the W3C's web accessibility initiative is to define strategies, standards, and resources to make the web accessible to people with disabilities. So what kinds of things have been done from the standardization side of things to make the web more accessible to people? There have been a lot of efforts and actually I have been involved in the Chrome accessibility team for a few years now and we have a esteemed colleague on the team that has been a part of the standards for many years now. And what they have been telling me is that at the beginning there was nothing and then they worked really hard for a few important standards to be put in place. The accessible rich internet application standard, ARIA for short, it's very extensive and it defines specific attributes that you can add to your HTML that enable HTML elements that do not have any semantic information attached to them. It's what I was describing before, the use of divs and spans with visually with visual information that conveys to the user what they do, for example, it might be a div that represents a button or a checkbox, but it doesn't convey that to the assistive software, it's only conveyed visually. However, if you use the ARIA standard, there are some attributes, for example, roll and you can say roll equals checkbox and suddenly all the assistive software knows that this is a checkbox and then there is another attribute, it's called ARIA.checked and then you can say, okay, that's true and that means that the checkbox is now checked. So what is visually represented with a checkmark is now also conveyed in the HTML and the assistive software can get to that information. Another standard that has been evolving is the HTML standard itself. So as I said before, in HTML5, there are new form controls, rich form controls that you can use and those controls are accessible by default because they're implemented by the browser. So there's slider, there's a time range, there is email input, telephone input, et cetera. There are lots of controls. Another standard is the web component standard and that's an evolving standard and that one enables you to create components, a widgets that could be packaged as a unit and used in other web apps. This is very helpful because once somebody creates an accessible widget, let's say we're gonna create an accessible calendar widget. We can create that, publish it on the web and then people can easily include it in their web apps. Before this web component standard, it has been hard to include components from other sites because when you paste in HTML and CSS, there might be conflicts with your own CSS, with your own HTML, with your own JavaScript, but this web component standard enables those widgets to isolate themselves from the rest of your web app. So I think that would help accessibility by enabling people to create accessible components once and distribute them to be used everywhere. And what is the accessibility object model? It is a standard that would enable web applications to expose some of the accessibility information and perform some of the accessibility actions that were only available to desktop applications in the past. Not only desktop, but also, I should say, that were only available to native applications in the past. I'm talking about things like if a user performs a gesture, a specific gesture or uses a specific command with their assistive software, this command could be communicated to the web app itself and the web app could take action based on that command that came from the assistive software. Native apps could do that before, web apps couldn't. We're trying to create a standard to solve that. Another thing that this standard is trying to solve is the ability for the web app itself to create accessibility information that would only be visible to users of assistive software. In the past, you couldn't easily do that. Now you can. If you have a complicated app that presents things using, let's say, Canvas or some other kind of graphical technology, but you wanna create some equivalent, semantically rich representation of what is visually conveyed to users of assistive software with this new standard, the accessibility object model standard, you can create your own accessibility objects, put the information you want in them and expose them directly to assistive software. So in effect, you can tell the assistive software what exactly what you wanted to see. So what types of tools are available for developers to understand how accessible their website is? Chrome actually has a lot of built-in tools. We have the Chrome developer tools and inside the Chrome developer tools, if you go to the main panel, the panel where you can see the DOM tree, there is also a tab in there that allows you to see the accessibility tree. The accessibility tree is not the same as the DOM tree. The accessibility tree is the tree that is presented to assistive software and it is created based on the DOM tree and the layout tree. So your HTML, your CSS, your JavaScript, all of that is used to create the accessibility tree which conveys the information about the page to assistive software and that's the tree you can manipulate with directly using the accessibility object model standard that I have mentioned before. And also that's the tree where in which all the ARIA attributes you might have added to your website, that's where those attributes would appear. So as you can see, this tree is created from many different sources but ultimately that is the information that assistive software sees. And you can see it as well. If you go to the developer tools, there is a tab there that shows the accessibility tree and you can use that to see, let's say if you have a screen reader user, what are they gonna experience if you visit your website? How are they gonna, what information are they gonna see when they try to read the site using the screen reader? There is also another panel in the Chrome developer tools. It's the audits panel and as part of the audits we have Lighthouse. Lighthouse can perform audits on your website and give you a list of errors or recommendations for you to improve. So it's very easy. You could go and click and run an audit, accessibility audit on your website. I have to point out that it doesn't catch all the errors. You ultimately do need to test with some assistive software or rely on user feedback, but it does help. Right. A score of 100% doesn't mean your website is fully accessible. Yeah. So the HGTP archive tracks Lighthouse accessibility scores on over a million websites. The median Lighthouse accessibility score is 62%. And another interesting stat, 42% of pages correctly use alt attributes on images and only 12% of pages correctly label form elements. So the state of accessibility right now shows a lot of room for improvement. Unfortunately, we do need to redouble our efforts and perhaps we need to provide more automated solutions for making web apps accessible. We do need to pay attention to the web content accessibility guidelines. And there are three axes in those guidelines that I think everybody can understand. The website should be perceivable. So you should be able, as a person with disability, you should be able to perceive content that your disability prevents you from perceiving. So let's say you have an image, it doesn't have a description or you have a video that has only audio, it doesn't have captions where people were deaf. If you're a person with some developmental disability and there is language there that is not as too advanced and too complicated, or you have very long and long-winded text and you're unable to read long pieces of text and you're gonna have difficulties there. So, or you're a person who doesn't tolerate rabid animations. So it's not hard for somebody who is developing a website to understand if they try and put themselves in the shoes of a person with disabilities for a few minutes. It's not hard for them to understand what it means when we say that your website needs to be perceivable. It just takes some time to put yourself in the shoes of this other person and then realize, oh, wait a moment, this might create some trouble for people. Another thing in the Web Content Accessibility Guidelines is your website needs to be robust. So the HTML needs to validate, you need to be using the correct attributes and form labels is actually part of that. You need your forms to have labels, your form fields to have labels to indicate errors in a clear manner and to suggest corrections if possible. So I don't think it's hard for somebody to follow those standards if they try and getting the shoes of the user that is trying to use the website. I do realize that some of the standards are vague and too technical. They use complicated language but I think if you're a developer that wants to learn how different people with accessibility needs to use your website, you could try and find videos on how different people use assistive software and then try and imagine yourself being in the shoes of those users. So as web capabilities continue to evolve, we have technologies like AR and VR around the corner. How do we make sure that we're not leaving people with disabilities behind? A lot of the changes happen organically. They grow from past experience and slowly, slowly solutions get developed. For example, assistive software has been developing for 25 or 30 years and it has been a gradual process. However, if there is a technology shift like the move to a touchscreen, mobile phone, for example, or the use of VR and AR, virtual reality, it would be very difficult for somebody to wait for this progress to happen gradually because then you would expect a big gap in the amount of time that you have to wait if you're a person with disabilities to get your hands on this new technology. So here is where we need the new research and the innovation. That's why I do encourage people who are interested in the field of accessibility to pursue a career in this field and to also get a degree on accessibility. There is a notion that accessibility is easy, that you just add some labels and some alt text and some keyboard navigation. However, your question about virtual reality points the finger to the big changes that could happen in the lives of people with disabilities if an innovation takes place. And we're not going to get an innovation if people are not going to work hard and try to be creative with the accessibility, with providing solutions to those accessibility challenges. Finally, what resources would you recommend for web developers who want to make the web more accessible? My program manager, Laura, has produced a few videos that you can watch. We have a Udacity course that some of my coworkers have created that you can watch and it explains to you how you could add accessibility to your website. Also, the web content accessibility guidelines from the W3C and the ARIA standard, the Accessible Reach Internet Application Standard. The authoring guide for the ARIA standard and the examples that are provided. So, Nektarios, thank you again for being here. My pleasure. You can find links to everything we talked about in the description and also share your perspective on the state of accessibility in the comments below. Thanks for watching and we'll see you next time.