Web Accessibility for Ninjas: A Practical Approach for Creating Accessible Web Applications

Rate this content

In this hands-on workshop, we’ll equip you with the tools and techniques you need to create accessible web applications. We’ll explore the principles of inclusive design and learn how to test our websites using assistive technology to ensure that they work for everyone.

We’ll cover topics such as semantic markup, ARIA roles, accessible forms, and navigation, and then dive into coding exercises where you’ll get to apply what you’ve learned. We’ll use automated testing tools to validate our work and ensure that we meet accessibility standards.

By the end of this workshop, you’ll be equipped with the knowledge and skills to create accessible websites that work for everyone, and you’ll have hands-on experience using the latest techniques and tools for inclusive design and testing. Join us for this awesome coding workshop and become a ninja in web accessibility and inclusive design!

109 min
20 Jun, 2023

AI Generated Video Summary

This workshop focuses on web accessibility and the importance of making digital products accessible. It covers topics such as testing tools, identifying focus in web development, fixing focus indication issues, and making buttons accessible. The workshop also explores zoom and accessibility, using Lighthouse for accessibility testing, and fixing accessibility issues with screen readers. It emphasizes the importance of incorporating accessibility into the development process and the benefits of team diversity in improving accessibility.

1. Introduction to Web Accessibility

Short description:

Let's jump right in and find out how we can help. In this workshop, we'll discuss web accessibility and provide a hands-on experience. Accessibility is crucial for users with disabilities, such as vision or physical impairments. Tools like screen readers and keyboards can assist them in navigating websites. However, developers must ensure that websites are properly designed and accessible. Failure to do so can result in legal issues, as seen with a well-known pizza company. Globally, 16% of the population has a substantial disability, emphasizing the importance of accessible digital products. Israel shares similar statistics.

So let's jump right in and find out how we can help. So we're going to talk about web accessibility, and this is like a very hands-on workshop. And I put here, when I talk, you can, you can clone the project that is right here in the presentation. I'll send it, or Eitan would be so kind to send it in the group chat. My multitasking is good. So if you want to do it together with us, you can just clone it. Run npm install, npm run start, and you'll see the project.

So I'll start again. You're welcome to open your cameras and to feel free to ask questions in the chat. I'll hope we'll get to all of them, and if not, maybe after we can. Okay. So at first I want to talk about something else. I want to talk about something I love and care. And so I want to talk about something I love and care. I want to talk about pizza. Do you like pizza? You can raise your hand if you don't. If not, you can turn your screen off if you don't like pizza. So most of you here. Sorry. Bad joke! Okay. So I love pizza. And when I want to order pizza, I use the pizza application. I choose my shape and size, which is the largest. I choose the quantity, which is sadly, maybe, like, two. One for me. One for my kids. Maybe three if I'm in a good mood. I choose the toppings that my kids love, which is sadly not mushrooms. And I hit the cart and order the pizza. It's fast, it's fun, it's hot, it's pizza. It comes very fast. And it's amazing.

Now I have a friend. Let's call him Joe. Joe, he has a vision disability. He cannot see very well. When Joe opens the application to order a pizza, he also loves mushrooms. When he opens the application, this is what he sees. Because he cannot see very good. Fortunately for us, there are tools that can help Joe use the application, although he cannot see. He can narrate or make him hear the website. The things I can see with my eyes, he can hear with his ears. This is amazing. So he can use the technology, this tool is reading out loud the content of the website. It says this is the button. Here you can choose the number of slices or here you can choose the toppings and he can order a pizza. Amazing.

Now, me and Joe have another friend, let's call her Beverly, but she has a different disability. Her disability is physical. She has some kind of disability that prevents her from moving her hands in a very good way. So she has a limited motion range. So she cannot use the mouse. And also, she's having trouble using the phone. So she can use the website of the pizza. And as I said, because she has a limited range, she cannot use the mouse. So she can use the keyboard, because she can click on buttons. Luckily for us, you can use the magic technology which is a keyboard to navigate through websites. So you don't have to go over all the options and choose your pizza and fill in your credit card details and make the pizza delivery guy come to your door, which is amazing. Well, there's a small catch here. So all the technology is here, but in order to make it to work, the company or the developer that builds the website or the application needs to make sure that the website is accessible, needs to make sure that the tools that are reading out loud the content or the tools that are helping them navigate through the website with keyboard can do it. It means, for example, that we need to order the elements on the screen so that when you hit the tab key, it will go in the correct order. Okay? So, and you need to make sure that all the buttons are accessible by keyboard, a true story, a very large pizza company had an issue with accessibility that their entire application was accessible, but the final button, which was like submit your order, was not accessible by keyboard. So, they got a very big lawsuit and I won't say the name here because I don't want to get the lawsuit, but you can Google it. So, it's a real problem. So let's take it one step further. If we are talking about the entire world, so the World Health Organization, the WHO, they committed a survey in 2019 and they saw that 16% of the world population has what they call a substantial disability, a meaningful disability, that prevents them from doing things or that requires some kind of assistive technology. It could be a physical technology, like ramps or wheelchair or the little elevators. Sorry, I don't know the names of the things, but, and a big portion of them need assistive technology for the digital products. For example, they use screen readers or use the keyboard instead of mouse or there are many different technologies which are amazing. And if I talk about Israel, which is the place that me and Eitan are coming from, we're speaking about similar numbers.

2. Introduction to Accessibility Testing Tools

Short description:

We're speaking about 1.5 million people in different ages. It could be old people or not old, old ages and old genders. And so it's about the same. We saw that this is not only a problem of Joe and a problem of Beverly, but it's not only pizza. It's pizza and it's a donut, if you're from the States or baguette if you're from France. If you can order a baguette, I don't know. And it's a problem if you want to enter your bank account or if you want to buy tickets for this conference. If you think about it, there was no way to do it without a computer. I mean you just can't do things today without a computer. So when we are not making our services accessible, we're not only losing money because people can't use it, it prevents people from equal opportunities because everything is digital, everything. The first phase for making things accessible is to test them for accessibility. We will go into testing and fixing today. We'll discuss tools used in the industry for testing accessibility, both manual and automated. We'll also have a live accessibility testing session where we'll walk you through testing an application, finding and fixing bugs. Finally, we'll talk about maintaining accessibility on an ongoing project and best practices for ensuring your applications stay accessible as they gain more functionality and updates. Let's start with the tools we use for accessibility testing, including the keyboard, screen readers, and browser extensions.

We're speaking about 1.5 million people in different ages. It could be old people or not old, old ages and old genders. And so it's about the same. So if I were to talk about every place, the statistics are very similar. Also in the U.S. it's very similar.

OK, so we saw that this is not only a problem of Joe and a problem of Beverly, but it's not only pizza. It's pizza and it's a donut, if you're from the States or baguette if you're from France. If you can order a baguette, I don't know. And it's a problem if you want to enter your bank account or if you want to buy tickets for this conference. If you think about it, there was no way to do it without a computer. I mean you just can't do things today without a computer. So when we are not making our services accessible, we're not only losing money because people can't use it, it prevents people from equal opportunities because everything is digital, everything.

So what's the first phase for making things accessible? So if you want to make things accessible, the first thing is that we need to test, to test them for accessibility. And this is something which is, we will go into today and also fixing. And we're going to do a lot of things related to accessibility. And again, I encourage you to ask questions freely. As one of my teachers once said, there are no stupid questions. There are only stupid mentors or something like that. I don't remember the, I mean, feel free. Okay. And, um, it would be very interesting. I hope. So before we start, uh, I'll introduce myself. So I'm a stuff I'm the one, um, with the tongue out, and this is my daughter's star. I have a three kids, sorry. Time of day I married to Netta. I've been to in the industry for more than 12 years in various roles in the uh, uh, I have a blog program on.net. You're welcome to, uh, to enter and to read about things that I find the interesting, I hope they interest you too. Uh, it can be my friends on LinkedIn. And in the, uh, in the past three plus years, I'm the front end tech lead at Aviv where, uh, I'm at eight. And we together. And, um, I don't know, the city is yours. Thank you. So I'm a time. Um, I've been working in software development for over 15 years now. Um, I worked for, um, Several companies, um, sizes from a few dozens to many thousands, uh, mostly on the front end. And for the past year and a half, I've been working with, uh, stuff in advanced, um, which is a very cool company. If I might say so myself that, uh, deals with, uh, developing software for accessibility testing, which is, uh, why we are all here today. And today we're going to talk about. About, um, several interesting things. Um, first we're going to discuss a few of the tools used in the industry for testing accessibility, um, manual testing and automated testing. Um, so we'll discuss a few of those. Uh, then we'll get to a live accessibility testing session where we'll see, um, like a demo app prepared and I'll walk you through, uh, how we go about testing accessibility on that application, find some bugs, fix them, and improve the world just by a tiny little bit. Um, and finally, we'll talk about, um, like the bigger picture, how you maintain accessibility, um, on an ongoing project. Um, best practices we currently use, uh, for making sure your applications stay accessible once you've fixed all your problems, um, as the application gains more functionality and updates. Okay, so, let's start with the tools. Um, first thing is one we are all familiar with. Uh, we've been using it for decades now. Uh, at least I have, uh, it's the keyboard. Um, now the keyboard is again, we're all familiar with it, but it has a special meaning when it comes to accessibility testing. Um, because first thing, um, not all our users or quite a lot of them might not be able to use a common mouse or even just feel less comfortable with it, because of various known disabilities and keyboard is an excellent alternative, but not a common one that's found in very affordable. It's found in every household. And, uh, when you make sure once you make sure that your application is accessible by keyboard, um, you're also in a very good place to make sure it's accessible by other assistive technology, uh, such as the one next on the list, um, screen reader. Um, screen readers. So there are quite a few of those. Um, Some more prominent than others and some work better on some kinds of operating systems, uh, more than others or, uh, like, uh, different kinds of browsers. Uh, we'll take a look later at one example, which is a, uh, problem using which is a Apple's voiceover. And. Uh, finally, after screen reader, we'll talk about, uh, several extensions that we use for testing accessibility. So, um, extensions such as a browser extensions or extensions to your, uh, development environment, your ideas, uh, and it's on. Um, so with that out of the way, um, let's move to some coding.

3. Exploring Website Functionality

Short description:

In this workshop, we'll discuss web accessibility and provide a hands-on experience. We'll focus on making a fruit and vegetable buying website accessible. We'll explore its functionality, such as searching for products, adding them to the cart, and paying the shipping fee. Our goal is to ensure keyboard accessibility and provide similar functionality for all users. Let's navigate through the website using the keyboard and understand the importance of accessibility.

Okay. So, uh, as I said earlier, uh, if you didn't do it, I mean, you don't have to do it. Uh, just if you want to. So this is the link there. It's also on the group chat. And, uh, we need you, maybe this is not the perfect image, but, uh, it's, uh, I mean, we invite you again to share your own links to share your own websites and, uh, we can help you analyze it and have the group to learn together. Um, So, okay. So what do we want to, to speak about today? I mean, what, what is this website though? This is the website. This is the website of something maybe you're all familiar with, which is fruit and vegetables. Okay. So we are, the thing today is food. Okay. We spoke about pizza now. Like maybe we'll get to desert if we'll be lucky enough. Um, so this website is actually, uh, a place that you can buy fruit. So let's take a look. This is, this is a place that you can buy fruit. Uh, look at some of its functionality. So you can go to the website. You can search for, uh, let's say tomato and, oop. Okay. And, and you can edit two cards, maybe three tomatoes, three kilo tomatoes. And then you can go to the shopping cart and to continue or to like to, to, to buy, to buy it, you need to pay the shipping fee, which is, uh, It's okay if you purchase fruit with more than $100,000 it's free, no problem. Um, we counted one user per day and we're all good. Um, okay, let's, uh, uh, look at the south, the other functionality, so we can filter on the vegetables on fruit, on nuts, on the beans. Um, if I don't remember which fruit I, I love, I love broccoli, so hey, I love it and then if I come a day later and I don't remember which, which vegetable I like, I can have a look at the favorite, ah, I love broccoli. Okay. So now I can add some, like, uh, I really love broccoli, 10 kilos of broccoli. Okay. So this is the website. I hope you can relate. If you don't, if you're not a vegetable person, maybe this is not the talk for no. And, uh, and it also has like other parts, but we'll get to them. So our goal now is to make this website accessible. And the first thing we're going to do is to use our keyboard and to make sure that everything is on the screen is accessible to keyboard I'm going to use. Um, So for now, I mean, this is my mouth, but I'm going to throw it away. Okay. Not really, because it will break and I need it for the presentation, but, uh, mentally thrown away. And now I'm going to navigate. Everything you see is me clicking the key. Okay. This must keep Turkey. And okay. So let's see if I can do, I mean, the definition of accessibility is that, um, We need to provide the same. I mean, it, it doesn't have to be the similar experience, but you need to provide the similar functionality. For all people. Okay. So maybe if I'm using the keyword, I will have less animations, but I can, I could order the same things. I would get the same discount. I can perform the same functionality. Okay. It's okay to have a little bit of different. I mean, if someone, uh, who cannot see, he won't see the, uh, the colorful video, uh, at the beginning of the website, which is fine. I mean, we don't, maybe it's not that important, but if it's important, we need to provide an alternative. Okay. So that's, that's the, the idea behind it. So let's try to, to go and navigate. So first I'm visiting I'm now focused on the home screen on the home button. Now I'm in the search bar. Okay. Now I'm on the shopping cart. Do I need to zoom in by the way? It's okay. Okay, great. Thanks. Okay. Now I'm on the favorites list and now. I'm hitting, do you hear the clicks loud enough or should it click harder? Okay. No, it's the clicks. Ah, okay. So, okay.

4. Identifying Focus in Web Development

Short description:

Let me teach you a small trick to help you identify the focus on your website. In the dev tools, there is an 'I' in Chrome that allows you to give it an expression and print it all the time. By hitting tab, you can see the active elements. However, in this demo, it doesn't seem to work. Let's move on and find out why these buttons are not in focus.

So now I'm clicking, but there are like several clicks here that doesn't, don't do anything, so now I'm focused on this part and this one, and now on this one. And now I, I'm doing one, two, three, four, five, and now I have the focus here. So it means that there's something going on. I don't know what, but I cannot see it. Okay. So the part here is if you're a front end developer, which I guess like most of you are, or you're familiar with it. So it means that, there is a focus somewhere on the screen, but the user me, I cannot see where it is. So I'm going to teach you a small trick that can help you. If you have similar issue in your website, okay, if we're going to the dev tools, which I zoomed for 1000 or something, there is a small thing here, which is the I in Chrome. And it means that you can give it an expression and it will print it all the time. So if I hit a window dot active element, OK. Element. Uh, whoops. Maybe documents are talking about active. Okay. Sorry. Uh, I told you there will be mistakes. It's part of the show. Okay. So, um, now there is an active element. Now, when I'm hitting tab, you can see that the, uh, the active elements here. Oops, oops, oops, oops. Uh, so, uh, the demo, I think it doesn't work, but nevermind. Okay. Let's leave it. And, uh, I see what, why did the fork afterwards. Okay. So what I'm seeing here, that's gonna go back here where we need to make to find out why these buttons that not the focus. Okay. These are the buttons. So, I mean, it means that if I cannot use them out, I cannot hit the fit. So if we expect them. And, uh, by the way, this, um, this simulation that we're doing is it's kind of like a real real life scenario because I did not write this code. I mean, I, uh, I ask for permission to write and Mohammed guy, the guy allowed us to use it, but I'm not familiar with this code, though. I am going to debate and we're going to find out together. What we need to do. Okay.

5. Fixing Focus Indication on Buttons

Short description:

Here, we encountered an issue with focus indication on buttons. By removing the border and outline styles, we were able to see the focus indication when using the keyboard. However, the focus indication was still missing when using the mouse. We fixed this issue by adding a red border to the focused button. Additionally, we discovered that the focus was lost when the button was clicked and removed. This caused accessibility issues for keyboard users. We inspected the code and found that the button was being removed, resulting in the focus being dropped. We will further investigate this issue.

So. Okay. So here are the buttons. These are the buttons and I can see here that the border is none always. And the outline is not always, it means that even when the button is in focus, it doesn't have any indication. So if I remove this, suddenly we'll see something. Okay. It means that now we can see that, uh, actually we, we do have focus on this button and we can click enter and we are filtering or weighing back. It will go back with shift and tab. I can go cutting the other way.

Okay. So now let's go to the code base and fix it like properly. So I will do what I would do in a normal project. When I'm not familiar, I will use the control F and find the element. Oh, where is the project? Okay. So, um, so if I'm looking for the button here, so this is the button, the filter button, oops, sorry. Okay. So this is the button, the filter or button, like several buttons. This one, these are all the shifters for the vegetable, the fruit, the nuts, and they all have the same customer, which is fine. And now I want to say, okay, so when you are, uh, where you are, when you are. Um, in focus. Thank you. A copilot. I'll give you a red border. Now it save and we refresh. And now suddenly these buttons are no accessible. I mean, they were accessible for keyboards before, but they didn't have the indication. So it's like, how's the way? I mean, it could work, but, uh, I need to guess that they weren't focused. Now it's really clear that if I hit enter, the button is not or be okay, that's consumed. So now I'm continuing with my journey, uh, with my journey here, and I'm trying to add an eggplant. So I think of eggplants and it doesn't add the eggplant and go to a different page. So that's okay. These are working. So we see that when, when we are, uh, having, something happens here, right? I mean, it disappears and then comes back. It means that something is, uh, something is a, something, I mean, it is changing. Okay. Now it works. So as you see, I mean, now we have a, the focus, the active, active element is like, what is it, answer the question. Like what element is in focus. Okay. So when I'm typing, this is the, the aid, the age ref, the anchor. And it's on the eight, the eggplant, and now it's on a button. But again, I cannot see the focus indication. So it's the same problem though. Now, as we learned before, um, let's, let's see the, What's the, uh, let's look for the buy button. Uh, and let's add. That's a, actually let's wait and see if copilot is, yeah, actually they know what they want to do. So we added the focus indication to be the one, the button is in focus. It will add a boiler. Okay. So we're, we're getting closer. So now I can click it and then I need to, I mean, if I'm using my mouse, I can, uh, add like number of audience that are very cheap and remove it. But now I want to do the same with, with the mouse. Okay. So I'm clicking, and I, and again, the, the problem is that, I mean, nothing happens if we look also at the active element. Uh, so here we are in focus on the button and now we're on the body. If the focus is on the body, it means that the focus is on nothing. I mean, technically it means that the focus is dropped. So it's, it's not on any element that does anything now. I mean, I continue, but I continue here. Not. I'm not continuing to focus on these buttons, but I am now on the body. To focus on these buttons, but on another age of, so what happens here? Uh, is that we have, I mean, if until now the problem was focusing indication, now we have a complete different ability. For a user that can see and he's that, sorry, that can use the mouth and the user that cannot, because the users can use the mouse can, can, uh, choose the number of tomatoes. And the user that cannot use the mouse can see that there are tomatoes, but can't do anything with them. So it's not acceptable for, for keyboard users. So now we're going to expect, inspect and, uh, and see what's going on here. Are any lucky guess guesses before, before we dive into the console? The button that you clicked is removed and therefore the focus is lost. Interesting. Actually this can happen.

6. Making a Button Accessible

Short description:

When making a button from scratch, it's important to ensure it has the correct semantics and accessibility attributes. By using the role attribute and tabindex, we can make a span act as a button. However, this approach can be cumbersome to maintain. Alternatively, we can replace the span with a button element, which already has the necessary accessibility features. It's crucial to remember that HTML, by nature, is accessible, and using the correct semantics can save time in accessibility adjustments.

I mean, if you are in focus on something that element is removed. So I don't know if the browser moves the focus back to the body or to the element next to it, but it can happen. It happens to code I wrote, which replaced the react component while it was in focus. So I mean, it happens a lot.

Okay. Okay. So what happens here is that, I mean, it looks like a button, but if we inspect it, now I would use the zoom here because I want you to be shocked. I am the basket plus is not a button. This is a span with a nasty SVG inside, but let's leave the SVG alone. So the basket plus is not a button. It's a span. So how come it works with the mouse? Let's go back to the code. If we'll look for the basket plus here, and also his friend, the basket minus, it's a span where on click... It means that this is an element that has a click handler attached to it. It means that if you click with your mouth though, the, it will work, but it doesn't have the required attributes to... The accessibility attributes to be a button. And so what are the, the required attributes for a button? We created a small, a small talk presentation about it. Actually, there is like, this is the presentation, okay? So this is the button. What does it mean for a button to be acceptable? It means that if I use it with my mouse it does something. If I use it with my keyboard, there are a few things. First, it receives the focus. Second, there is a focus indication, the border, the border around it, okay? The blue border. And now if I hit enter or I hit space bar, or it's different in any, in every operating system, but Mac supports both enter and space. So it does the same thing, okay? So this is the case with the button. And this is like we can, I mean, this is what we expect from a button and if you'll see the amazing code behind it, if I just dig like... Oh, so this is the code, okay? The button and that's it. So the native button has all the accessibility things required for a button, which makes sense. And so if there is one thing to remember from this talk is that by having the correct semantics, you save yourself a lot of time in accessibility adjustments because HTML by nature is accessible. So let's go back here. So this is the application. Here we have a span. And now when we want to, actually, we have two options. We have two options for making, we have two options. Sorry, I try to read the comments and to speak simultaneously, but my mind paused for a moment. So, we have two options. We can either make the span be a button or like to act as a button, or we can replace span with a button. So, let's do both. Okay, so first let's make this span a button. So, at first it has onClick, which is nice. So, the other thing that we need for a span to be a button is to add a role, if I could type. So, role, a role of a button. Okay, it means that this HTML element, which is not supposed to be a button. This is a button. We decided the browser, and you know this is the button. Thread it to the button. The second thing, we wanted to receive focus with keyboard. So, the tab key will put focus on this button. So, we can use a different type of act, which is called tab index. In React, it's written tab index with a i, in pure HTML, there is like a hyphen, I think. So, if you want to be a part of the regular flow of the page, we can put here the value zero. If for any reason we have an element that we don't want it to be in the tab order, we can put minus one. If we have a button, which is only decorative for a reason, and we don't want it to be on the tablet, we can put minus one. So now, we have the tab index, we have the roll, we have onClick. And, I think it should do. So, let's see. Let's refresh here. And now, it received... Like, we received the focus here, right? But, I pressed the enter, now you can hear it. But, it doesn't do anything, because I forgot the most annoying thing. When you build a button from zero, you need to support everything. So, we have onclick here, which is the mouse click, but we need also to add onkeydown, and I hope it will complete, because, okay, great. So, 13, this is enter, I hope so. Let's see, and if now... If I... Thank you, copilot. So, now, if I hit enter, it increases. I mean, it performs the same functionality, but as you can see, it's a bit hard to maintain this kind of code, because I need to put you like, or this is a space bar click, and imagine the case that this is disabled button. So, if there is onclick, don't do something, and remove the keydown handler. So, it's a bit cumbersome to maintain. Let's look at, sorry, lucky for us, there is another button, the basket minus, the evil cousin.

7. Testing Button Behavior and Accessibility

Short description:

Let's test the behavior of the button. It should have focus when added with the keyboard. The back button is not accessible, but we can check if it gets focused. We inspected the span and quickly converted it to a button. The design broke a bit, but it still works. There's a question about when to use the role attribute. The answer is never, unless you have an image or need to make the entire image clickable. It's best to use the native button element. Let's move on to another example: using coupons on the crazy coupons page.

Here we'll take a different approach, we just move it into a button, and that's it. So, now, let's test how it behaves. Now, this one has focus. Okay. I think I didn't save or something. Hmm. Let's see. Ah, okay, actually it does have the, okay. So if I add here, and, ah, sorry, there are two buttons here. The one remove, and there are two buttons here. Again, not my code, I'm learning as we go. So now if I can add with the keyboard and remove with the keyboard. Okay, you can choose your own path if you want, if you want to make a component to be a button or you can use the native button. So think about it, so let's continue. So now this screen is being fun. Eitan, you are doing the hearts, right? Yeah. Yeah, okay. So let's say now that I'm editing. So I'm editing, ooh, sorry. I'm editing this or I entered. You're talking to the keyboard. I'm entering the strawberry details. Here you have organic and the price, it's similar price to Israel, I must say. Very, very expensive, strawberries. And now I want to go back, okay? So, one of the main issues about accessibility is navigation. So if I'm using the keyboard, I can use this button to go back. But when I'm using my keyboard, and I'll put this here as well. Someone asked about why I put it in the console. Maybe I was confused before, but here you can put like a, there is the eye, it's like a watch. It means that it watches the argument constantly as it changes. Okay. So like, I don't need to, I can like do something and then write every time active element. But if I put it on watch here using the small eye, it just changes while I tab. So it's very convenient to know what's going on. Clear. Okay. So the back button is not accessible, but let's see if it gets focused. So we are on the icon of the Shope. Shope. Shope. And now we are jumping to the plus this one. So this one doesn't receive anything. So let's inspect it. Again, this is the span we did before, but so we do it very quickly. Button. And that's it. And now we just hope it will work. As you see, it broke the design a bit, but it's okay. We'll still make lots of profits. So now it works also with the back. And Okay. So before I continue to the next thing, which is not focused, related, yeah, I see a question. In what scenario would you add this role equals button actually, instead of just making it a native button? Haitian, do you want to? I think the answer is never. I don't see any reason to do that. Not off the top of my head, anyway. I think that maybe if you have like an image, which is a button, or some kind of, I mean sometimes you want to make it like the entire image be clickable. So it's an image tag, and you want to make it, to give it a role of a button, instead of making a button and then locating the image inside of it or something like that. I mean, this is a pattern that maybe, in other cases, if you can use just button, bottom, so do it. It's the same about headers, about pipelines, about the dropdowns. Yeah. So I guess if you find like a very cool third-party library that has an amazing looking and functioning button that's actually a div, or you want to use it without going through the trouble of copying it, it's usually a button window. Yeah. If you have the controller, it will always go with the button, right? Yeah. Yeah. Okay. So let's have another example. So let's say I want to coupon because we love coupons. Actually, I haven't used one lot of time. So let's go to the crazy coupons page. Okay.

8. Zoom and Accessibility

Short description:

One of the criteria for accessibility is supporting Zoom up to 200%. Not every disability is the same, and some people just need to make the font bigger. However, when zooming to 200%, some elements may disappear, indicating that the site is not responsive to Zoom. Finding a solution requires considering the design and functionality of the application, and may involve options like horizontal scrolling or wrapping items. UX design plays a crucial role in ensuring accessibility for zooming and handling long content.

So now I'm going to speak about something different, which is Zoom. So one of the criterias for accessibility is the ability to support Zoom. Zoom, not like the software, but for people that cannot see, one of the criteria is that a website needs to be, to support Zoom up to 200%. And again, it shouldn't look exactly the same. It should provide the same functionality. Okay. By the way, if you want to know, like to look for a place to learn about, about accessibility, you can visit Vince Knowledgebase. Okay. If you go to a Vince.com, then look for the Knowledgebase. And there are a lot of, I think like a lot of things there, for example, about, about the buttons, about most of the things. I mean, a lot of examples and things to do and not to do. But the dialogue, switches, I mean, a lot of things. And. So if I'm going back to the Zoom, so Zoom is one of the criteria for a people like with vision disability. Not every disability is different. Like not everybody sees blur, some just need to make the font bigger. Okay. And if you think about it, it doesn't mean it just may be it happened with age. You know, some people like me, I use Zoom now more than I used before. And I'm not part of the statistics in any way. I just use it as a utility for me. So what happens if I Zoom here for 200%? So, okay, so I have the buttons here and I have some buttons here as well, but some of the coupons disappeared. Okay, it means that the site is not responsive to Zoom. Okay, so because this is not like a session about CSS, I mean, some of the solutions here, look like something that the solution is not adding another thing on top of the application, like another role or another focus handler. We need to think about how we want our application to look. This is a kind of scenario that maybe will require the designer or the product manager. Because like one option is let's add a horizontal scrolling. Another option is let's add wraps, so like it will be like three items and then three items below. And I mean, maybe we want to show it like maybe one by one and with like a private next button, I don't know. But if this was like something that I'm working on. In my work, this is the time where I say, okay, so this is not like a technical magic and when we add rows and everything goes fine. Here I need to take the product manager and speak about what is the most important thing. Maybe we need to show less text, I don't know. But this is something that needs more thinking, more design. But I mean here because I am, because I can do whatever I want, maybe we can remove the overflow, it's hidden and we just have like horizontal scrolling. Where you want to put things nice, you say, okay, so there is no scrolling, the application is always in the same place, we need to consider zooming, okay, and also long content, but I mean this part of the thinking about UX in general.

9. Using Lighthouse for Accessibility Testing

Short description:

We ran Lighthouse on the homepage and it gave us a lot to think about. The accessibility score was 91, but there were still issues that manual testing could uncover. One issue was contrast, where colors were not distinguishable enough. Language tags were also important for screen readers to provide the appropriate accent. We're building an extension that goes beyond manual testing and uses machine learning and image processing. Let's see what it found.

Okay, so we did a lot of things here and I want to show you one more thing before I'm giving the stage data to even dig even deeper is that there are extensions that can help us perform the accessibility testing. One of them is Lighthouse, okay? It's Google Lighthouse. Actually, it's built in inside the browser. If you look here, we look for Lighthouse and we will say analyze, it will run a bunch of analysis on performance, accessibility, best practices, SEO, progressive web app. So, I want to ask you, and I'll give you like 20 seconds to answer in the chat. So, I mean, this is Google, right? They know what they're doing, I think, I hope. And if I would run this test on this site, what will be the score from one, from zero to 100? I mean, before I did the changes. Okay, you can write the numbers. I'll start between one and 100. Okay, 26, 60, 30, 40. Do I hear 41? Sorry, 50. Okay, very interesting. It varies like there is a range. Okay, great. So we ran Lighthouse on the homepage, on this page, and it gave me something, it really gave us something to think about because when we ran it, this was the result. So these are all the criteria. Accessibility, 91, which is, I mean, if I got 91 on my website, I would not invents like a single minute in accessibility. Like dear product manager, go away. Let me do, let me work on the Redux state refactor or something. It's fine. So, but you can read this one. I mean, if you use the, we can read the text here. It says, this is only a subset of accessibility issues that can be automatically detected. So manual testing is also encouraged. Thank you for also encouraging manual testing. I mean, the things here, we'll look into them. There are things that we did not see with our tests. There are things that are different, but to say that this site is 91% accessible and I cannot use it with the mouse, I just cannot. I mean, I cannot order my broccoli, which is very sad. So, well, that's my point. You can take it to whatever place you want. There are extensions that are different. I will show you. I mean, in a visit we are building an extension that does more things that simulates a lot of the things that we did manually and does more analysis with machine learning and image processing. I'll show it in a minute. I'm not going to sell anything. It's going to be like a small pic. So let's see what it did found. That we didn't. So it said something that we didn't find which is called contrast. It says that the two colors here in the filter button, they are not the same. I mean, they're not the same, of course they're the same but the contrast is not good enough so people that cannot see very well maybe won't be able to see the text. The same for this button. If you click on this button, it's on this button. So it makes sense that people have the same error. Also for this button. Okay, so this is, I mean again, this is also the kind of thing that for my blog I will fix it on my own but in a real product I will go to the designer and discuss it. And if this is the part of like the color palette a new logo that the company paid $20,000 off, we're in a problem. I mean maybe it's not that easy to replace because it's part of the brand. Okay, there are other things here. Links with screen, but name, Eitan we'll talk about it in a moment. Okay, one more thing. There is something called Language Tag. I mean, every HTML document can declare what language the content is in. This helps for example, screen readers to say the right accent. So, if it says the language is French, the voice you will hear in screen reader, it would be maybe in French or with French accent. I mean, if you think about like user experience of the voice, so this is important for that one because it will make the names more real. I can't imagine like French accent calling Israeli names. It would just sound very weird. So, and I'm blaming the Israeli names, not the French guy. Okay, so this is another thing. If I, I mean, I can do, oh, I missed something. Nevermind. Okay, so if I take this one and just run it on a different extension, okay. This is the extension that we are building in events. Okay, so it's a, it runs over the page. And one of the things it does, it doesn't only like record a specific state. When we are, I mean, when I'm moving states, it records after the page changes. It analyzes each time and finds more and more issues. So these things that like I would do.

10. Exploring Issues and Using the Screen Reader

Short description:

Let's discuss the issues we found on the page after the fix. There are color contrast issues, unacceptable names for screen readers, language errors, and more. We'll also explore using the screen reader tool, specifically voiceover on a Macbook. Voiceover provides detailed information about the elements on the screen and how to interact with them. It's a valuable tool for testing accessibility.

And now I'm going to add and press the plus and the minus, actually this is the page that is after the fix, but nevermind. And pressing the heart. So let's see what we found here and let's go back to the, let's go to the state also. And okay, so here it has several issues. If we had it down, we can see, okay, so this is the color contrast. This doesn't have an acceptable name, which is for screen readers. Also this one is the color contrast issue. Also color contrast now because even after a fix, this is gray and gray. This is the language error that we spoke about before. It says that this entire document has this problem. If I go here, So We get many color contrast issues. This button is a nightmare. We didn't discuss it. And there are a bunch of other things that are going on here. This is the link name. Again we'll discuss it in a minute. So the other extension that can, I mean, this is, and it's also, it finds all of the things about tabbing that I did manually. But if you don't use this extension, sadly it's not publically available yet. I hope it will be soon. You can, I mean, use the keyboard. It will do, it will give a great start. So Eitan, what do you want to tell us about, how to use the screen reader? Yeah, okay. So we've covered the keyboard. And can everyone see this identical app, I'm sure? Cool. So we've covered the keyboard so far, most of it or large parts of it. And the next tools we promised to discuss is the screen reader. So I'll do a demonstration with voiceover, which is the built-in tool in my Macbook. And I'll start by activating it with a... Voiceover on, speech off. Special key. Now it's off by default because I want to be able to hear myself think and for you to be able to hear me. Let me just turn it on for a little while. Voiceover on, speech off. You are the winner! Let me turn it on for a few seconds so you can experience what it's like to work with an active voiceover. So unmuting now. Voiceover on, speech off. You are sure that has left the arena asked from the fans. Add strawberry. Image. Add onion to basket. Image. You are currently on an image inside of web content. To begin interacting with the contents of this image, press control option shift down arrow. To exit this web area, press control option shift up arrow. That's poetry, right? Someone has to make a tune for it. So, do notice that the screen reader it, tells us exactly what's on the screen and how to interact with it. In addition to the, to hand it out loud, we can read it in the like in the popup menu here. So I'll use that for the rest of the demo, if you don't mind. So muting again. All right. That's nicer. Bass debug to everyone, party popper. Thank you. Okay. Completely lost my train of thought. Let's start with, okay. So I wanted to talk about the heart button, right? So you'll notice that my version isn't fixed, I can't get to the heart button with the Tab key. I know Aidan, we cannot see the screen reader, small thingy, maybe it's shared only Chrome? Sorry about that. Yeah, I'll fix that in a second. Okay, sounds good. Maybe you can explain again what is this thing? Okay, so there's this new thingy that you see in front of you and it's details exactly what element I'm currently on and how to interact with it. Basically the same instructions we just heard out loud a minute ago. So if I'm going to tab into the page and use the voiceover dedicated keys. That us a LHAT, yes, entered the waiting room. Close, admit view, press C and D plus U to the waiting room. That us a LHAT, yes, has entered the waiting room. Press C and D plus tilde to open the box To the participants panel to admit participant. I bring voiceover. Anyway, let's try that again. I can use the voiceover keys to navigate between the different elements and I can reach the heart shape thingy button, whatever.

11. Fixing VoiceOver Accessibility Issues

Short description:

That's basically because voiceover did something that is better than specified. So it's not guaranteed that other screen readers will be able to do the same. When I get to the heart image, it only describes it as an image, which is not helpful for users. I fixed this issue by adding a highlight label that says 'add to favorites' and changing the element to a button. Now, VoiceOver describes it as a button and prompts the user to click it. However, the description 'add favorites' is not very descriptive. There is also a useful feature in VoiceOver that lists all form controls on the page, but it doesn't provide enough information about what is being added to favorites.

That's basically because voiceover did something that is better than specified. So it's not guaranteed that other screen readers will be able to do the same. So we still need a soft fix from earlier. But here you notice one more thing that when I do get to the heart thingy, voiceover only describes it as an image. So let's try that again, image. Now, that's a shame. Now, okay, if I'm a user and I get to this, like image thing, I don't know what to do with it. I mean, should I, I don't know, should I, should I look at it? What does it mean? Should I click it? Should I move it aside? So that's something that we really need to fix. It's a critical violation. So let's do that in the code. Turn this off. VoiceOver off. And switch to my ID, which is here. There we go. Okay, everyone seeing this? Cool. Yep. So the element I'm interested in now it's called interest and it has the heart thingy right here. And as you can see, it doesn't say anything except for like a div that is clickable and contains an image inside of it. So one way to fix that would be to like describe the image, right? So I can leave it a highlight label and say that this is a, I don't know, add to favorites. And if I do that, and go back to the app, and activate voiceover again. Voiceover on, speech off. So now when I stand on the heart image, so it describes it as add to favorites. Which is nicer, then it goes on to mention that this is an image. And I can do that. We cannot see that. We cannot see it again. Okay. And that's about one. I get the hang of it eventually. Thank you for your patience. So again, to the heart and add to favorites. You're currently on an image inside of web content to begin interacting, blah, blah, blah. Control option shift down to interact with it. Now, I guess a normal user will by now understand that this is something you interact with and it adds to favorites, but it's not very nice. Like it's still an image. I'm not sure what the interaction that they're expecting of me is, and we can we can do better, right? So let's try and calling. Your screen sharing is paused. Your screen is off. And let's not do that. let's, instead, turn this div into a button. I've seen it before. This label can move, button element. and we go back to the app. Like this. turn on voiceover. VoiceOver on. Speech off. Thank you. Let's see what the heart button says now. Add favorites. We are currently on a button inside of web content. To click this button, press Control Option Space. So this makes sense, knowing that this is a button. It adds favorites and I should be clicking it. So I'll do that. Way better, right? But still, not quite there. Add favorites. That's not very descriptive, is it? Okay. To drive the point even further, let's see another feature that VoiceOver has. You see this long list. Cool. This list depicts all form controls on the page. So you can see, we have a lot of items that say simply add to favorites. Add to favorites. But what am I adding here? This list is very useful if you want to navigate quickly to a different section in the page. It's widely used. Or you can... Vitaly babed to everyone how to open this list of form controls. Excellent question. So this is VoiceOver.

12. Using VoiceOver for Accessibility Testing

Short description:

In VoiceOver, you can navigate through different sections using front controls, landmarks, window spots, and links. However, finding specific items, like bananas, can be challenging. To address this, we can define a dynamic label for favorites, such as 'add something to favorites.' By implementing these changes, we can improve accessibility and fix issues identified through VoiceOver testing.

I didn't mention it because it is just an example of a screen reader. In VoiceOver you do it with a VOU, which means VoiceOver, VoiceOver key plus U. VoiceOver key is configurable. By default, it's Control and Option pressed at the same time. So Control, Option and U. Escape will close it. And it can be opened again. So this list depicts all front controls. I can use Control, Option and arrows to navigate between different sections. So front controls, landmarks, which shows the banner navigation in Flutr. Window spots. So this is like... Higher up in the hierarchy, content in Flutr. And links. We have lots of links here. So going again to the front controls. If I am a user and I know that I'm looking to add some bananas to my favorites, it's kind of hard to find them here, right? Let's try to fix that. VoiceOver off. I'll buy a VoiceOver. Let me go into my code. And what I'm missing is some dynamic label, right? It's not always just add to favorites, it's add something to favorites. Let's define it. So, favorites label, I guess, is, I'm sorry about naming, but that'll go with it, is a favorite dot title, was it? No. Post title, let's check. And going back here, sharing the right desktop and activating voiceover. Voiceover on, speech off. Yay, got carrots two baskets, cucumber, and I wanted bananas, até bananas. Very cool. So that's much better. And we've seen one typical example for accessibility issue and several ways, VoiceOver can help us find issues quickly and fix them. What's next.

13. Exploring More Examples and Fixes

Short description:

Let's look at some more phone controls. Another issue is the add button. Let's fix the last example above the coupon section. It's a deal that contains a label with an input inside it. We want it to be a switch to move between two states. Give the input a role of a switch and provide it with a proper label. This was the final example I wanted to show you.

So let's take another. VoiceOver off. We're going to do that. VoiceOver on. Speech off. Okay. Let's look at some more phone controls. Thingcard has joined the meeting. Welcome. Yeah. Let's try to shop something. Oh, darn it. Okay. So another issue I wanted to show you is the add button. So let's look at the codes just so you can see the fixed version. Your screen sharing is paused. Your screen sharing. Voice over voiceover off. And it was in the card component. And looking at the add to basket button, that button to didn't use to have the R level here, which I added and this fixed the problem that I wanted to show you that like before the fix, if I make it go away for a second. Okay, everyone seeing the app. Voice over on, speech off. And this one, and we have a lot of add buttons. So it will be very hard to find a specific item to add if I didn't fix it earlier. So that's one more example. And finally I wanted to show you the last example that I use. By above the coupon section. So I'm going there for a second. Okay. You'll notice this, a cool section at the bottom with references. So, if I activate voiceover again, voiceover on, speech off. And navigate there. This one says unchecked. Again, not very descriptive, I have no idea what to do with it and should I be checking it or not? I can get a hint if I like Navigate to the label next to it for to receive emails about carrots for example. So we'll proceed to this unchecked thing. I might be able to guess that that's a way to opt in or out of receiving emails, but not very user friendly. So let's fix that one too. VoiceOver off. All right. Got it. Hey, so again, I was wise enough to provide one example of a fixed tagger thingy. And if you take a look at the one that didn't work well, so basically, it's a deal that contains a label with an input inside it. It's type is checkbox. But we don't really want it to be a checkbox, right? We want it to be a switch to, like, move between two states. And the right way to do that is first, give the input a role of a switch. And provide it with a proper label, so voiceover will be able to tell us what this switch is about. And if I look at this specific instance. VoiceOver on. Speech off. VoiceOver. So again, this is the label. I prefer to receive emails about all these counts. We're currently on the text element inside of WebContent. To interact, press Ctrl-Option-Shift-App arrow. Remove the switch, we get a receive email for all these counts. Off. And on again. And if I... Marty to everyone, you need to leave now. We'll see the last part with the recording. Really interesting and good to learn about this and is important to be inclusive. So thank you, colon D. I couldn't have planned it better, huh? Colon D should be our repping name. Right. Absolutely. Voiceover off. And this was like the final example I wanted to show you about... Again, we could have stopped at like several places along the way of this demo, of these FIX examples. Examples. And it would have passed I guess, any automated testing or most manual testing because it's like good enough and workable.

14. Day-to-Day Accessibility Maintenance

Short description:

It's important to go the extra mile and ensure the user experience is consistent. Legal compliance may not be enough for users who cannot use a keyboard or mouse. We'll discuss day-to-day accessibility maintenance, including using accessible components and automated testing. Our component library approach ensures accessibility across the entire application. We also utilize a linter tool to enforce accessibility rules. By running manual and automated tests, accessibility is never broken. Let's watch a talk on accessible components and explore the component library. Additionally, we'll demonstrate a linter plugin for enforcing accessibility rules.

I mean, people can make it functional but it wouldn't have been as usable, as fun. And I think it's very important to go the extra mile and make sure the user experience is the same all around.

Okay. That's it for the voiceover part. And asos, back to you I guess. Okay. Okay. So as a single emphasis again about this 91, because it's really the key to understand what the difference between like having the compliance, like legal compliance and having the product actually doing what it should for the people it should, because legally maybe this 91 can cover you from somewhere, from some place or some angle, but from people who cannot use keyboard, you cannot use the mouse or need to use voiceover, it's just, it's not enough. It's just not enough. Sadly.

Okay, so we either, apart from the things that we covered in the live session, button, link, colors, inputs, we discussed area labels, the language tag, we discussed the switch also, the things that's not here, we covered the switch, we covered how to add labels to images and to make them to button. And to our next chapter, we're going to talk about the day to day accessibility maintenance. I mean, there are, as we see it, in a way to work with our customers, our company that want to work, like what not want, want to work on their accessibility solutions.

So they want their products to be accessible, and we see that there are two phases, like the initial phase is the thing that we're doing here, what we did now, like we're taking it from zero to a hundred or from zero to 90%. It been that you have something that is not accessible, and now you're working really, really hard to make it accessible. And now you have something that works. It can take a year of a team, it can take a lot of time. You can maybe you need to ask for consultants and things that know a thing or two about accessibility, but it can be done. The day after is the day that your accessibility assignment is complete, and then you have a new brand book, and then you have a new logo, and then you have new colors, and then you have new interactions, and then you have a new feature that flips your application upside down on its head. And the challenge is to maintain accessibility. So I mean, even if you don't have a big change, but you are writing code, and then a new developer comes to the team and changes something we need to make sure that the change is still accessible. And this is a real challenge. It's a different challenge because it's like, it's a maintenance challenge, right? So these are the best practices that we gather both from ourself that we strive to make our application accessible and from clients that are working on it with their accessibility team, their front end teams.

So the first thing is using accessible components. In the link below, like in the video here, you can see me with a purple shirt and purple background which doesn't have a good color contrast. And this is a talk about accessible component and it's a 30 minute talk. So let's watch it together. I'm kidding, I hope you won't watch it together. It will be not very fun. You're welcome to watch it, you can look for accessible component. It's called My Accessibility Journey. It's an entire talk about how we created like our accessible component library. It has the same principle that we spoke about before.

The idea is that if you're building an application because we are using React as, I guess, you too because we are in a React conference. So we are tend to, we are used to thinking components. When we were looking at the page and it's built out of a nav bar, of buttons, of images, of sliders, of different components that build several pages. So our approach was to, I mean, what we did here in this session, we did a top-down approach. We looked at the website after it's built, we looked for things that popped from the top, from using the accessibility tools. If we have a big project and several applications, we can look at it from bottom up. If we'll make the base components accessible, if we have like a common button and this button enforces the use of a role or enforces uses of aria-labels, then our entire application will have accessible buttons. So this is the component library approach. And we added, I mean, we did all the manual tests for our component library. And we also added automated testing for accessibility. This again is something that we're working on in a VIN. And it's not public yet, but it's going to be like a framework that you can, that you write your cycle step and then you can also test for accessibility while you're writing your code.

So, I mean, I, that's not what I wanted. So if we will, I mean, this is the component library that we have. It's not small. It has like 30 plus components. These are storybook. If you are familiar with storybook, it has like the different permutations of a component. If it's a menu, it's closed and open and with buttons inside or images inside or icons. And there is the button which is disabled and not disabled and tabbing that have state. And I mean, there are many, many variations of the same components. Also there are graphs and charts and tables, which are a completely different thing when speaking about accessibility. They are like deserve their own talk. Accessibility of charts, like imagine how to make a screen reader talk about a map or about an image, about a complex chart. It's something we need to speak about. So all of these components, we run them, we run manual test and functional test and we run accessibility tests every time we perform commits. So accessibility is never broken. We have, it's like a regression test for accessibility, every time. So this is the component library or the component approach. And the second thing I wanted to speak about in this area is the thing that, this is a free tool that you're welcome to use. It's called a linter. There is a plugin for ESLint or JSlint or like every leading library can use it. It's a set of rules that enforces accessibility. I want to demo it, because demo is fun because in demo, things can go wrong and it's more interesting. So this is the product where I configured the ESLint. It's called ESLint plugin JSX accessibility is the plugin for React and there is also for Angular and for others of you if you're working on other frameworks. And if I create, for example, if I created these and I put in a click render on it and say, okay, so this is a button, it says, okay, so this is a non-interactive element with click element, but have at least one keyboard listener.

15. Using ESLint for Accessibility

Short description:

When adding event handlers to HTML elements, it's important to provide appropriate roles for accessibility. The ESLint tool enforces accessibility rules, such as requiring alt text for images. Alt text is useful for providing descriptions to users who cannot see the images. The ESLint plugin offers a range of rules, including those for emojis and anchor tags. While compliance with the plugin is a good start, it does not guarantee full accessibility.

So you're having, you have a button and this button has on click. It means you need to provide also something for the keyboard. Okay, Linter, sorry. So I'll add on key press and it will do something here. Okay, sorry. But it still is not happy because it needs a role. It says, okay, so this is a div, but and also it's not like a valid react. I just remove one right there, I wanted. Okay, it says, well, static HTML elements with event handlers require a role. So screen reader will know what is the switch, is it the button, what is it? So if I add a role button here, it's still not tapping. I say a single quote. Now it's a different thing. Okay, so I was no, I was with button must be focus about, ah, okay, sorry. So, actually it needs to be focused. So I need to add tab index. Okay, so I wanted to make a div with on click and it made me add the focus and the key press handler and the role. And this is really nice. And it also works on button. It also works on image, if I put an image it has, like some gear, it shouts, the image must have an alt prop. So it enforces a lot of accessibility rules. So now it has an alt, and now it's valid. I mean, if you want the picture to, the image to have, I mean, if it's meaningful and you want someone who does not see, understand what's going on, you need to put an alt text. If you want someone that cannot see to ignore it, if for example, if just a flower's decorating your website or something like that, if you put alt text, then screen readers won't read this text. That it's a way to tell screen readers to ignore it. Okay. It's another trick. It is very useful. So this is the ESLint. They are, if you look here, there are a bunch of tools, a bunch of rules here, about the emojis, alt text, the anchor. It has a lot of rules that you can use. It's really nice. We use it all the time. And again, even if you're a 100% complaint with this plugin, it doesn't mean your website's accessible. But it's a good start. Okay. It's better than not having it.

16. Developing Accessible Web Applications

Short description:

Let's talk about the process of developing accessible web applications. Accessibility is a crucial part of user experience, and it should be incorporated into every step of the development process. Design features with all kinds of users in mind, consider accessibility when coding and testing, and ensure the UI is accessible and usable. Use tools that integrate with your workflow to make the most accessible products. In summary, we discussed the importance of accessibility and the process of testing and fixing website issues. Making accessibility a part of the conversation and utilizing available resources can help create more inclusive applications.

And Eitan, now we're going back to you. Yep. Thank you. So that was the winter. And can everyone see my screen? Okay. Next thing I wanted to talk to you about is a bit philosophical. It's like, it's very opinionated. And it's sort of our approach for developing accessible web applications. And I wanted to talk about the process. Let me just voice out my own personal thoughts on it. And I'd love to hear back from you. If you agree, disagree, have like other opinions or ideas.

And let's start with looking at like this nice visual. I guess most of you are familiar with it. It's one depicting the three pillars of user experience. So user experience is about how the product looks, how it makes us feel when using it and how easy it is to use. And looking at this visual, I feel like it's missing the accessibility part. And honestly if I had to place it anywhere, it would be like smack in the middle, because if you think about it, like how the product looks, it has major impact on accessibility. If the UI is simple and straightforward and easy to operate and understand what's going on, if it's clean, so accessibility is much better and how it makes us feel. So beautiful UI is something that you can feel, right? I mean, when you look at some beautiful visuals on a user interface that you understand intuitively and immediately how to operate and like go through it without making any errors, that's a great feeling and when it comes to accessibility, you also have to make sure that it's accessible and that you provide the same kind of feeling of nice, calm inside when four users that have any sort of disability. I guess the word I'm looking for is inclusive. UI has to be inclusive for all kinds of users. And usability is like the obvious part. I mean, if you can't use the application for whatever reason, it's not very usable. And I think we need to like think carefully about how we can incorporate accessibility in the entire process of creating amazing user experiences.

So to do that, let's look at this chart here. This trifecta is also very common. I mean, or in each and every company I ever worked with, they had this like three groups, the product group and the engineering and the UX or UI or designers. And these three interacts on a daily basis, right? I mean, in the design phase of the next iterations or sprints, when thinking about concepts for new products, when examining the outputs of a sprint we just finished, the interaction is continuous, is, it's all around, I mean, products interact with engineering and UX and the other way. And again, we have to see where we can talk about accessibility and inclusiveness, is that a word? I think it is. Accessibility anyway, and incorporate it in like every step of the way. So when you design your features, think about all kinds of users. Really think hard about what kind of users you might be leaving out when making decisions about a product, about engineering. While developing applications, think about accessibility all the time. So when you code, when you write tests, that's the functionality as well as accessibility of all your code and components. And when you design the UI and try to come up with the best, nicest, most usable user interface, also take into consideration how accessible it is. And try to incorporate tools that help you do that. So tools that integrate with your IDs, with your browser, with your design tools, Figma, Bits, Storybook, whatever. There are wonderful tools out there, and I really encourage you all to, if you take something from this talk, it's this. Go out there, find the best tools to help you make the most accessible products and bring this into your organizations, into the mindset of everyone involved. Oh, that was me gushing. Thank you. I guess that's it. Saf, back to you. So to summarize, what did we do here? So what did we do here today? We discussed, we spoke about pizza. And everybody agreed that we love pizza. And everybody agreed that we need pizza. And even the ones who cannot see or cannot use the keyboard or use some kind of assistive technology, everybody deserves pizza because accessibility is important. And it's something that our world is getting more and more digitalized. And without accessibility or supporting several scenarios, people will be left out. And the second thing is we went through the process of testing a website, learning what the problem is, and fixing it. Some of the fixes are easy. Some of the fixes are hard. What we encourage you to do is to try, to try on your own, to see what works best for you. We discussed, Aytan discussed about how continuous it is and how can we make it something that is a part of our daily job. Of course, we are developing features or capabilities for the product. We're not developing only accessibility, but making it part of the language, both in tools and technology and in the conversation, is the right way towards making your application more accessible. It needs to be a part of the conversation. And if you want to learn more, here are some resources that we mentioned here. The Event Knowledge Base and blog, they are a technical knowledge base. This is technical knowledge base about criteria and things like that. They are a blog that we and other, I guess, startups or something like that, are writing about making acceptable code and tackling different problems, both in processes and technically. You can listen to talks. There are great talks about accessibility. If you are in conventions and conferences, accessibility is getting more and more staged. You are welcome to view the talk I spoke before. You can look at my name in Google or something and get the talk there. And there are other great speakers, such as Maa Shavin, which also talks about accessibility and accessibility. And both in React and in Vue, they are great talks. And the third thing is to try it.


Importance of Accessibility and Convincing Others

Short description:

Just start. We love speaking about accessibility. Legislation is forcing companies to ensure accessibility. Investing in accessibility has good PR. In 2025, the European Union will have a law about accessibility. Companies are exposed to lawsuits if their site is not accessible.

I mean, just take your application. Don't overthink it. Open the voiceover then close it because it's intimidating. Then close, open it again, or mute. And then try. Try to see what's going on. This is the way to learn. Or try to take your mouth and literally cut its wireless wires or hide your battery or something. And see if you can work with your own application. It's really interesting.

So on behalf of Eitan and me, I want to thank you for listening. We love speaking about accessibility. We think it's such an important topic. And it crosses so many vectors, which is development and user experience and equality. And although we know it's hard to learn and the commutation sometimes is just awful, just start. And so we want to thank you for your time. We'll leave here some time for questions, if you have. I will be happy to answer. And also tomorrow you'll get the survey about the talks. And we will be happy if you give us a positive feedback, or at least, or a positive feeling or an awful feeling, but not like, OK, if you like this, if you don't, put it on the way. Don't spare your energy. So this is time for questions or even if you want to say something.

No, absolutely. I just want to echo Saf's words. We love this topic. It's very close to our hearts. And if you have anything you want to know, or just reach out after the workshop. And we'd love to hear back from you.

OK, maybe I have a question. So I know that a lot of people, especially men, are color blind or have some form of color blindness. That's quite a big percentage. Do you know of any tools that exist to test your website for color blind people?

Yeah, go ahead. OK, so there are some extensions that look for color contrast. I'm not sure. I don't know if there are specific criteria for color blindness. I guess that I don't know. I don't know from the like to pull from my head. But I'll Google it after the talk. It's really interesting. Actually, we have a guy in our work that is color blind. And once we did rebranding, he didn't understand what was going on the logo. So it sends the UI team to a different trajectory. It was really fun from this side.

Yeah, I see. There's a tip on the chat also. And maybe I can add on this. If you're using Storybook, like we've also seen, it has a plugin that enables you different kind of color blindness levels to choose from. And it simulates that pretty well, from what I heard. So it is worth taking a look at it. Vitaliy? Yeah, I also have my question, and I also can answer the previous question. You can use Firefox and its dev tools without any plugins. It has ability to simulate at least five different color disabilities or so.

Yeah, and so first of all, thank you for this workshop. My question is, it is a bit hard. How to convince your team and the business to invest in accessibility? Maybe you know this. I would say, just show them some numbers. I mean, there are a shit ton of people with various kinds and severities of disabilities that you just lose as potential customers if you don't invest. And in many countries, and this is a trend that's actually very positive and ongoing, legislation is picking up the slack and forcing companies to make sure their entire digital presence is accessible. Enormous-sized lawsuits are getting more and more common. So it just makes sense, and it's the right thing to do. It has very good PR if you invest in it, and very poor one if you don't. Anything to add, Asaf? Yeah. In 2025, I agree with Eitan about the numbers. There are two kinds of numbers to show. One kind of number is the number of people that have disabilities. The other number is the number that in 2025, the European Union is going to have a law about accessibility being mandatory if you want to work with the European government or any government in Europe, or you need to work with a number of users that are using, you must have accessibility. Or you are exposed to lawsuits that can be the American law is that you are exposed to up to 1% or 2% from your annual revenue. If your site is not accessible, this is a huge amount of money. And this is one of the reasons that huge companies are investing in it. There is another approach that can work very well.

Improving Accessibility through Team Diversity

Short description:

Diversity within a team can lead to improved accessibility. If team members have different preferences or limitations, such as a preference for using the keyboard over the mouse, the application can become more accessible over time. However, addressing accessibility challenges may be as difficult as fixing the problems themselves, requiring awareness and budget allocation.

I like the startup of the Core of Blind I told before. If you have diversity inside your team, like if you have someone that has maybe not a serious disability. But for example, if you have someone that really does not want, does not love to use their mouse and use the keyboard all the time, over time, your application will become more accessible to keyboard because he'll just edit because it annoys him. I mean there are different approaches to tackling these kind of problems. But if it is as hard or even more hard than fixing the problems itself, like making it, making the awareness and getting the budget.

Watch more workshops on topic

TestJS Summit 2021TestJS Summit 2021
85 min
Automated accessibility testing with jest-axe and Lighthouse CI
Do your automated tests include a11y checks? This workshop will cover how to get started with jest-axe to detect code-based accessibility violations, and Lighthouse CI to validate the accessibility of fully rendered pages. No amount of automated tests can replace manual accessibility testing, but these checks will make sure that your manual testers aren't doing more work than they need to.
React Summit 2022React Summit 2022
161 min
Web Accessibility in JavaScript Apps
Often we see JavaScript damaging the accessibility of a website. In this workshop, you’ll learn how to avoid common mistakes and how to use JS in your favor to actually enhance the accessibility of your web apps!
In this workshop we’ll explore multiple real-world examples with accessibility no-nos, and you'll learn how to make them work for people using a mouse or a keyboard. You’ll also learn how screen readers are used, and I'll show you that there's no reason to be afraid of using one!
Join me and let me show you how accessibility doesn't limit your solutions or skills. On the contrary, it will make them more inclusive!
By the end, you will:- Understand WCAG principles and how they're organized- Know common cases where JavaScript is essential to accessibility- Create inclusive links, buttons and toggleble elements- Use live regions for errors and loading states- Integrate accessibility into your team workflow right away- Realize that creating accessible websites isn’t as hard as it sounds ;)
React Summit Remote Edition 2021React Summit Remote Edition 2021
91 min
Creating Accessible React Native Apps
React Native is a framework used to create native iOS and Android apps in a way web developers may already be familiar with. But how do you ensure your React Native apps are inclusive and usable everyone? Scott will share tips on how to test and build React Native apps with accessibility baked-in!

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

TestJS Summit 2021TestJS Summit 2021
30 min
Configuring Axe Accessibility Tests
Axe-core is a popular accessibility testing engine that is used Google, Microsoft, and hundreds of other companies to ensure that their websites are accessible. Axe-core can even integrate into many popular testing frameworks, tools, and IDEs. In this advanced session, we'll be learning how to configure axe and its integrations to fine tune how it runs and checks your pages and code for accessibility violations.
JSNation 2022JSNation 2022
24 min
a11y and TDD: A Perfect Match
Accessibility has been web development's ugly duckling for quite some time now. I often get asked, "when should you test for a11y in your apps?" My answer is simple, "right from the start!". Regardless of the framework considered - React, Svelte, Vue, YourOwn™️ - as developers we are in a privileged position to help the ugly duckling grow into a beautiful swan. How? By diving deep into the pond and harnessing the power of Javascript APIs to build the right components for your web apps. And how can do you know you are building them right? By pairing Test Driven Development with the Testing Library family. Ready to grow your web apps into swans?
JSNation 2023JSNation 2023
10 min
Dialog Dilemmas and Modal Mischief: A Deep Dive Into Pop-Ups
Our design systems commonly feature components that show on top of other content: tooltips, date pickers, menus and teaching UI, to name just a few. Proposed updates to the web platform are about to make building these a whole lot easier. You might not even need JavaScript. In this talk, you’ll learn all about the upcoming ‘popover’ attribute, modality and the top layer.
React Advanced Conference 2021React Advanced Conference 2021
32 min
How to do Good Without Doing Anything
There’s no arguing that building accessible websites is a force for good. But ensuring that our React websites and apps work for everyone can be time-consuming and isn’t always easy to get right. Luckily, investing a little bit of time on your accessibility workflow and setting up a series of automated tools will end up saving you tons of time and energy in the long run.In this talk I will demonstrate how you can leverage automated tools, clearly documented code standards and a well-defined development process in order to make building and testing accessible React apps a breeze. I will discuss the ways that I automate certain aspects of my development workflows to catch accessibility errors, define and set up tests and go through the entire lifecycle of accessibility feature development using a real-world example.
JSNation 2023JSNation 2023
30 min
Accessible Component System Through Customization
Most current UI libraries provide great user experience with a vast of components. But when it comes to heavy customization, and non-standard scenarios, especially for E-Commerce, they become hard to manage, scale or even slow down performance.
How to create a UI library that provides users the most possible freedom in customizing components, while keeping our performance and scalability to the fullest? How much accessible we can provide out of the box to our users? How much customization freedom is enough?
That's what my talk's about.