Making Interactions Accessible to All Users

Thanks, Metin. It's actually my honor as well to be introduced by Metin. He's like my favorite MC, so, yeah.

And hi, everyone. I hope you are all enjoying the conference today. First of all, I would like to ask you, again, to give a big round of applause to all the organizers as well as all the volunteers. They have been doing a great job in organizing this. So give it up. Awesome.

So my topic for today is making interactions accessible to all the users. Okay. Good. So the agenda is we will start with some quick introductions. Then we will see a bit how users interact with the web and how can we make it accessible, right?

So before we start, a bit of introduction about myself. I'm working as a frontend consultant here in Amsterdam. I'm a Google Developers Expert for web. Microsoft MVP. Women Techmakers Ambassador and Cloudinary Ambassador. So you can connect with me on LinkedIn or Twitter at anrada15 or on Twitter at Miracle Underscore 404. So let's get started.

What exactly is interaction? So in simple terms, it just means some contact has happened between the user and the interface. So user could have done some action and there is some response from the interface and it is called an interaction.

So how do we all interact with the web? Can I get some examples? What do we do to interact with the web? You open a website. What do we do? Click. Yes. Hover. Scroll. Tab. Tab key, yes. Awesome! So yeah, we also type on it when we see an input box or something.

We have to fill the information. We hover. We scroll. We tab of course. So these are the ways in which we interact. We will see more just in a while.

But before that, what is accessibility? Accessibility means making resources and services usable by everyone regardless of their disabilities. Now, why should we care about accessibility? Because whatever we build, we build it for our users. So users should be able to use it, right? We have pretty diverse users. They can have different kinds of disabilities. And since they have different types of disabilities, they also interact with the web in different ways. Different kinds of technologies and devices. And they are called assistive technologies.

So there are multiple ways in which we can be accessing the web. We can be using the normal mouse, we can be using keyboard, screen readers, braille readers, a braille display switch, and so on. There are lots more. So now let's revisit. Yes, we interact with web in these ways. But we also can use tab. We can use enter if we want to go there. If we cannot click. If we cannot use a mouse. So maybe we are just reliant on keyboard. So we will go and press enter on it. Spacebar, we can use tab, scape to move away from a model, we can use arrow keys to navigate. So there are lots of ways in which we can navigate. And this is something which we need to be mindful of. So I will be showing some examples now. And the link is on Code Sandbox and I will be sharing the slides in the end. So don't worry about that.

And examples are fairly simple, not that complex. The format is I will just show an inaccessible scenario. Then we will see how can we fix it. And what should be the accessible behavior.

So the first scenario is button. Very simple, right? But buttons are everywhere. Buttons and links. We cannot do anything about that. Anywhere you want to go, you will use buttons, you will use links to navigate and so on. So let's see. Again.

So here is a button, maybe sign up, log in. I click on it, something happens. Here just a message happens and so on. So I can do fairly well when I'm using mouse. But let's start using a keyboard. Is the font size okay? So I start using tab. So I press tab. Can you tell me where I am currently, if I'm pressing the tab? Press tab again. We don't know, right? So there is no visual interaction. So if I want to know, if I'm just using a keyboard and I want to go to login, like, press enter, just on my wish or just count, and then, okay, these many tabs I have pressed. So maybe I'm on the right button and so on. No. But sadly, this is a very common behavior, which we see across all the websites.

So the culprit is just a very simple style. So when we go and focus on something, I know I should be focusing on a button. So let's go to a button and let's say focus. And we see there is a style. This one line of code is a culprit. And if you go ahead and check in your codebases, maybe in many codebases we search and we will find this, it's a sin.

It should be considered a sin. But anyways, if I remove this, now again if I tab, maybe can't see it properly, but there's a blue outline on it. So there is a browser default outline which goes on the button. But still it gives you a feedback that, OK, where I am currently, right, or everywhere.

Now designers most of the times are like, oh, these are ugly. So outlines are ugly is a very common notion in our web development. But we can change it. It doesn't have to be browser behavior. We can use some styling relating to our theme, our design system, and we can make it a bit better. So for example, I can just, instead of saying outline none, I can do something. I can add some offset, some color, and then suddenly it will be a bit better and it corresponds to the color scheme I have.

So second thing, when we have buttons like these, which just have an icon, we don't have any text. We have an icon and we want to do some interactions. Now again, I can see it. I can click on it. OK, it works. I know that. OK, maybe I'm favoring something. But many times we use non-semantic HTML for it. Maybe we have an SVG or an image or an icon and we go ahead and put an onClick on it. When we do that, these things are not accessible to the keyboard users. Because, since they are non-semantic, they do not get keyboard accessibility out of the box. So what should we be using instead? We should be using a button. That we will see in a while. But I would like to tell one thing here, that there are some times where we are creating something which is non-native, maybe HTML doesn't have a native element for it. Very rare scenario but can happen. In those cases we need to add some extra code to make it interactive. Like tab index, we put it a proper role. And in just, in addition to adding just onClick, we also need to add key down on it. So that the users who are using keyboard, they can also perform the action.

But don't do it just for a button or something. If we have a native HTML element, let's go ahead and use the semantic HTML. So we will be using the button. So once we use a button, it still works like that, right? So here also it's a button. And I did not remove it. So anyways, yeah.

So here I can press and I can press and it works. Now there are two more problems with this. Since this is just icon only, how does a screen reader user know that what this button is? They do not know the name of it. So we can provide some text for it. We can use ARIA labels for that. But then ARIA labels are also found that sometimes they have problems when we are using internationalization and stuff like that. So instead what we can do is we can create a visually hidden component, and we can have a styling on it. This is styling. What does it do is it just takes the text out of the viewport. So you wouldn't see it visually, but it is there in the DOM. So when the screenreader is used, then this text is pronounced. So I can say that, okay, put a visually hidden text here and give the name. So this is name is favorite.

The other thing is this has also kind of a state. It has two states. Either I have pressed it or I have not pressed it. So either it's a favorite or it's not a favorite. But again, a screenreader user would just hear maybe button favorite. How would they know if it's favorite or not? So if we have such kind of toggle behavior, we can use something called aria-pressed. And once we do it, what it does, when I go ahead and use the screenreader here... VoiceOver on Chrome, favorite, toggle button name, DevTool, selected. So once I select it, it says selected. And somehow when I open the VoiceOver, styling doesn't apply. But if I close, you will see that it's already selected.

Yeah. So it says that it's selected when you have selected that and you wanted to intend it to be selected. So next up is link. For the link, similar things happen. If we are using an image or something, we should be providing some alt text or some text for it. So the screenreader users also understand what that link does.

Apart from that, one important thing that I want to talk about is that sometimes in design systems, we are like, okay, this link looks like a button. And then we go out and implement using a button element. And we say window.location or use a hook like use navigate or something like that. What this does that okay, this will again still navigate you to that URL. But what we don't understand is that anchor tags have a purpose. They navigate us to somewhere. So they also have some behavior which we are used to. Like, for example, if I hover over a link, we get the URL down. We know that what is a real URL, even though whatever the text is. Also, when I right click on it, I get some extra behavior. Like I can open it in new tab and stuff like that or I can use control click and it opens. But if we use a button and use it as a link, then those capabilities are not there. So we take away these extra interaction capabilities from the user. So we should be always mindful of which element we are using. So again, there are more nuances to when should be using button and when should be using link. But one of the main thing is if we have some actions to do, a button should be there. And if we have to navigate somewhere, like we take user from somewhere, from other part of the page or to a different URL or so, then a link should be more proper there.

The next scenario is forms. Forms, again, are very important component of our web. Like everywhere, if you have to do a transaction, if you have to fill some form, you have to log in, you have to sign up, do whatever you have to fill in some information in forms. So forms is something that we interact with almost daily. Then they should be accessible. One very common error, if we go ahead and check webm-1million report, what it does is that it audits the top 1 million websites of the world for their homepages, and it lists out the errors. So this is one of the most common errors where the input labels do not have proper labels.

Either the labels are missing or maybe they have not been connected properly, and hence missing. So again, there's almost half of the webpages are with this error. So we need to do a lot here as well. So here, instead of just using a span or div for labeling, or skipping it altogether, we should be using proper labels. So we use a label, and we put for, or if we are using React, HTML for, and we give the ID of the element. And hence, the label gets connected. Somehow, so this is one very important thing which we need to do.

Other thing is let's say this is a form, and we have labeled it properly. Now what will it read? First name, text, last name, text, password, password field, and so on. Sometimes we have some extra information, some validation information for some of these input fields. Like for password, it could be very complicated. And you put out a long hint that, okay, minimum characters, they should have underscore and blah, and blah, like lots of stuff. Now when we are using a screen reader, again, it just reads out the label and the input. Like what you should be feeling. But this hint wouldn't by default be read out to our screen reader users. So they would miss on some important information that we have. For that, what we can do is we can add aria-described-by, and we say that this input is described by this SPAN or DIV, which contains that extra information.

Now demo gods were angry for me today. So in Chrome, all of my accessibility things have stopped working, but still it is working in Safari. So I'm going to show you the screen reader example in Safari. VoiceOver on Safari. First name. Last email. Password. Password. Required secure edit text with autofill menu. Minimum eight characters. So it will read out all the validation information that we have so the user knows exactly that, okay, this much I need to fill in. All these other things I need to follow if I want to pass through that. Now, the next thing is dynamic information.

So this also can be part of form. But I put it out as separate because we can have dynamic information, some alerts, messages and all, apart from forms as well. So sometimes we can have some important information which we want to tell our user. Example here, let's say, some error comes back. So if we can see error or message anything, if we can see, we know that, okay, this is the message. I know what to do next. But again, the user who is using screen reader, does they get this information? How will they get this information? For that, we need to have something called live reasons. So those reasons, one rule is that when the DOM is painted, that that should be already there. Like so do not create the element when the message comes. The element should already be there. And what we do is when the message comes, we put that message inside that live reason. So for example, here, what we can do is that this is a div where I am putting in my validation messages. So I can say that ARIA life polite and the role of status. So there are different values of it. There is also assertive and all. But I'm using polite because this means that, OK, this message is not that urgent. So what you do is that if the screen reader is already reading something, let them finish and then announce this message. So how this works now is again, I wanted to be doing something wrong. Register button, error submitting form. So it goes ahead and gets the message so the user knows there's something wrong. There are more layers to it, but due to time I wouldn't go and check everything. But one more important thing I want to say here is this is something of which some message comes from server or so and we show it to the user. Now there's one more very important pattern that we are following web. What we do is that when anything goes wrong in form, we just show it in red. We use a color, we make it red, and this is the error. Now there are different kinds of disabilities. There is one more condition called color blindness and there are different kinds of color blindness. One is called achromatopsia. So there could be a user who could be just showing in black and white and gray. And if you use just color to show some information, again, the user will not be able to understand, if they don't know where the error is, how will they go ahead and fix it? They will face the problem.

So we shouldn't just use the color, we should be using specific errors and showing them that, okay, this is the field where the error is and what is the error and so on. Okay.

So the last scenario is models. So about dialogs and popovers, I think Hiday yesterday did a very nice talk about that. So I wouldn't go into that but I want to show something about the models. Because this is one of the complex component out there, so we have something called, here I would like to talk about something called authoring practices guideline by area, it's by W3C.

So this is something which I really like because whenever we are creating something if we are confused what should be the interaction, like what should be the different flow, right? So what we can do is we can go ahead and go to patterns and search for the pattern we are trying. Like for example, here a dialogue, we can go and see that what are the intended interaction that user can perform? So these are the things we need to take care of when we are thinking about accessibility. So for example, it will give a list of all the keyboard interaction and what should happen like when the dialogue opens the focus should go to the automatically first focusable element inside and what tab should do, shift tab should do and all. Escape should close the dialogue and so on. So it's a pretty nice thing to go and read, but on the note of that, previously we had to write it all from scratch.

We had to write JavaScript code to create this dialogue element, but now HTML also has a dialogue element, a native element attached, which is pretty cool. So we can use that. And it does almost all of the things. For example, I press enter, the focus is inside, we are inside. I press escape, it closes, focus moves back to the place from where it was taken away. But one thing still is that the focus trap is not inside this dialogue still. So when I press tab again, I still move to different parts. So there is no focus trap. So what this does is that this could be a problem if we have a model which we don't have anything besides it. And if the focus goes behind the screen, that's not a good user experience. So instead what it should happen is I press tab and the focus should be inside the model. Because this is the only place where a user can interact right now if it's open. So for that still we can use some JavaScript code to make it better. What we can do is we can use a key down event handler, and there we can have some logic for... What we can do is that we can have focusable elements from the model. We can say that, hey, give me all the focusable elements of the model, which is basically just query selected into the model ref and get button anchor inputs, whatever interactive elements we have inside it. And we focus on the first and last active element, and then we can put the logic that what it does when it has tab and shift key, and when we are on the last... When we... Yeah.

So, this is the logic. When we press this and we are tabbing, when we are on the last element, when we tab again, it goes to first interactive element, and when we shift tab, it goes to last interactive element.

Now, again, I'm almost out of time, but... Yeah. So, this is not something, again, which we need to reinvent. We could have different component libraries in frameworks which we can use. For React, there is something, React ARIA, which provides lots of hooks, and they are pretty good. Even the use dialog is pretty good. So, go ahead and check this out.

So, to summarize, whenever we're creating something, we should be testing for all different ways the users interact with web. We should never remove the outline on focus. Use semantic HTML whenever possible. There should always be a text description for graphical interactive elements. Dynamic elements, messages should be announced. And always think from accessibility perspective. I have some links for further read. You can scan the QR code or go to tinyurl.com forward slash A11y-interactions. Thank you. Thank you for advocating accessibility. It's an important topic and, yeah, there's a lot of things that people do and, yeah, people don't think about it enough. So thanks a lot, Anuradha, for sharing.

One question that is asked by an anonymous visitor, which is asked a lot. How do they convince upper management to get the time and budget? Yeah. That's pretty, I think a very common question as well. And pretty difficult, you know. Like it's very difficult to talk to your upper management. But what I find works is one very important thing is make a scenario for accessibility. Like whatever product we are working on or services we are working on, we find that, okay, this flow is not accessible enough. And it's good to find a critical part. Because this is how we approach. If something is not accessible already, so we can not go ahead and in one day make it all accessible, right? So let's all first figure out the critical part. This is where the user does the most. Like if it's e-commerce, like what does a user do? The add to cart and buy flow is the main part, right? That's all the business is about. So take an accessible part of that, make it accessible, present it to the management and show them that, hey, this is such an important thing to do in our business. Our business depends on this. And if our users are not able to do that, then we are losing users, right? Like users wouldn't be using our websites and applications. So hopefully the management understands. And also we can show that this is not that difficult. We do not need 100 years to do something accessible, right? Like and we can do it in sprints. It doesn't have to be zero to 100 percent. You can go from 5 percent, 10 percent and just do it. Yeah. And if nothing works, then go for the laws. There are laws in all countries for accessibility. Please go and quote the laws. Just get the law involved. Yes. Yeah. And it depends on the company where you are and the budget you have, of course. But for me, like, if it's just part of the requirements, you can't merge anything if not everyone can use it. So that's a good thing.

And that's a good thing about working in a big company. Yeah. Yeah. I mean, we can definitely use multiple tools for automated testing. Like, some tools are in browsers. You can use Lighthouse. You can use AXE DevTools. Actually, anything related to AXE is pretty good, because even Lighthouse is powered by AXE. Then there are Microsoft Insights for web, which you can install as extension. There's AXE-Core. You can install AXE-Core and actually use it in the CI-CD pipeline. So it tests for it. There are some linters which we can use. But one thing to note is all these automated tests will not like, you know, catch the 100% of accessibility. Like, the examples which I gave, like Outline and Search, these are not something which will get caught in automated tests, maybe. You need to do manual testing as well and also user testing. So, yes, use automated tests and they really help us to tackle all the low-hanging fruits I would say. But we cannot rely just on automated tests to make it more accessible.

Yeah, I always feel like most accessibility issues can be tackled just by using the platform, right? Like, not writing your own button, just using a button tag. But if you are using any component library, make sure that it is compliant. Like, it is WCAG compliant, and they say it's like... ...and test it, even if they say it's accessible, do not believe it. Go ahead and test it, please.

Next question from anonymous. Which screen reader would you recommend for development? I saw you using VoiceOver, but for Windows users. It depends on which platform you are using. So, like, the users use different kinds of screen readers based upon which OS they are using or which device they are using. Like, for Mac, VoiceOver is the standard which they use. For Windows, we also have inbuilt VoiceOver kind of thing with Windows, but also we use NVDA. I think NVDA is a free one, then there is JAWS. Linux has something called Orca. Android has TalkBack, like, something like that. So, yeah, every device has one. But screen readers are, like, you need to read a bit before starting using it because users also have a combination. Screen readers are not like you start using in any browser. They have a combination. Like, we are using this device, we are using this screen reader, and then we have this specific browser. They work the best. For example, actually VoiceOver is said to work best with Safari, but, yeah, I do use it with Chrome. Yeah, okay. All right, thanks.

Question from Veronica. Are there some drawbacks to using Border on Focus for styling as opposed to Outline? Okay, so just using the Border styles. If there are any I'm not aware of yet, I will have to search more. But, like, what I feel is that if you are putting it out there, that user can still see it. Like, they get that visual feedback. There should be a visual feedback. If it's there, it is, I think it's okay.

But again, don't take my word for it. I do not know yet if there are any disadvantages. Well, I think the biggest drawback is that if you use Border or you change the Border width, because usually it's bigger. The styling. Yeah, the styling will be messed up because it will get bigger.

Yeah. We have time, yeah. You said ARIA labels should be avoided as internationalization issues. If we translate labels, do you have a preference of a label or hidden screen reader elements? Label or hidden? Hidden screen reader element. So the visually. Ah, the visually. No, I mean, if there's a form, it should be labeled. Even if you are visually hiding it, it should still be labeled. Because if we are just using any other text, so for forms, they wouldn't be read out. If you are navigating through forms, then labels are attached with our form inputs, so they will be done. But there's another way we can use ARIA labeled by like some people use it, but I think just use labels. Yeah. I always like if it's labeled because you can just click the text to focus the input. Exactly. It provides so much. You click on the label and you know that, okay, you are in this input text. It's pretty cool.

This is a good question. There are some ways. Like there are some tools which we can use, but also there is one in Chrome DevTools. In Chrome DevTools, if you do I think command shift P or something and you write emulate, you get different kinds of blindness that you can emulate. You can also emulate different kinds of color schemes. You can go to dark mode, light mode, and you can emulate all these blindness. This is the way if you're using Chrome DevTools, or you can install some extensions. Or there are some event softwares which people use to emulate this.

If you are not using web but using a photo or something. It comes in layered in lots of components. Cool.

Next question, from Metin Parzinski. Who is he? Weird name. I always use the title attributes for icon buttons. Is that also allowed? Actually, title is also inherited. So if you go ahead and see the accessibility tree, you will see that even for interactive elements you are using title. They read that title and they try to use it if it does not provide any text. But I do not know if we use title how it works when we are translating the website. So I don't know about this yet. So what if I'm translating into some different language. I don't know if title gets translated or not. If you're using the Google Translate automation? Yeah. That I don't know, but then you just shouldn't translate. Then we have to test it.

Now but what I like about the title attribute is that also for people that can read, that they can hover over it and you get that text. No, that's definitely good. I actually love it a lot, because you don't know all the icons. You don't know. For me, I'm always lost. What is this? I need to know. And that's definitely something which is useful. All right. And time's up.