Building Accessible React Components

So, hi, hello, everyone. And today I'll be talking about building web apps for everyone. How do you take care of accessibility in the same field?

So, let's quickly introduce myself. I'm Manjula Dube. I basically work at Vanguard. And Vanguard is only a largest asset management company that is wholly owned by investors and has no owners or shareholders. So, this client-owned structure helps us to focus on the best outcomes for our clients. And I'm also a Google Developer expert in web. I'm also an organizer at React India and JSConf India. And that's how you will find me on Twitter and GitHub.

A few things about Vanguard. We are growing in Europe and Australia, and also in Asia. One thing I would like to talk about is, although we are a financial-focused company from outside, but internally we focus a lot on technology and accessibility in general. Very good example of this is, we have around 7,000 people working in the technology team. What we believe is all the users have equal access to information and functionality regardless of their ability. One thing we always believe at Vanguard is all the users have equal access to information and functionality regardless of their ability. And if you want to really check more about what we do at Vanguard, you could quickly go on this link.

So before I start, we, I would like to, you know, always start with the sentence saying that because what we believe at Vanguard is we work to ensure that all the investors can access our products and services to help them reach their financial goals. And today what I'll be covering in this presentation is all about what is accessibility, what are the common practices you can take care of, you know, while building your web apps with React. And we'll be covering all sort of common practices, how we'll be handling forms, error handlings, images and icons, animations, and you know, how could you basically test accessibility. So to start with, I always start with saying that it's not a barrier to innovation. In fact, it is an innovation to web because you're building and including everyone to use your product. And when I say accessibility with React, it's not something to be, you know, afraid of or, you know, do that. It's, you know, it's how semantic you write your HTML. And why should accessibility matter to you? I mean, you know, we are in this world where we it's not just us. It's our friends. It's our grandparents. It's also the organizations that are monitoring our websites. And it is people with different and varied backgrounds. So, to start with, I would say, you know, there are people with disabilities around.

There are visual disabilities, cognitive. And I would say we need to serve all of them. And to give you a stat, I would say one in every ten users will always have some kind of disability. And sometimes disability can be situational. I mean, you know, so I often say this that accessibility depends on situations as well.

To quickly start with, I would say what is WCAG. We often come around with these terms, you know, when seeing accessibility in general. So, WCAG is a set of guidelines or techniques published by a working group at the accessibility initiative of worldwide web consortium, which is also known as W3C. And you see this AA and triple A. These are the three compliance levels for WCAG 2.1. And each level includes guidelines that must be met to consider if your website is accessible or not. So these levels are nothing but these are like three principles, which means must, should and could. So if your website wants to be accessibly compliant, you should at least follow level A. Or else, if you are not following it, you might have to deal with several As in your life. So better start following the AA standards.

To give you a short report, what I also found out that web AIM 2020 did a small random research on all of the top websites and what they found out is 98.1% of the top websites homepages have WCAG2 failure, which means you know, what are these common problems? So the common problems that are is, you know, low contrast text, missing alternative text for images or maybe they have like an empty links, they have missing form input labels. So although these websites like are top notch, but still they have WCAG2 failures.

And when I say, you know, I had a very wrong view of disability, I always thought that, you know, it's all about blind people, but it's way beyond that. I mean, we all have different perspective, but you know, we should start thinking and building for everyone. To quickly talk about principles of accessibility, there are four core principles, which means your website should be perceivable by everyone, which means captions and other alternatives should be available. It should be operable. I mean, functionality is available from keyboard. Any random stuff that you are trying to use is used by and is accessible by everyone. It is understandable, which means text is readable, content appears and operates in a predictable manner. And it is robust, which means, you know, content is compatible with current and future user tools. So, building for everyone, irrespective of what framework you're using, it's React, Angular doesn't really matter. How you would imagine your input component to be? I mean, let's say you have an input component, you know, how would you design it? The way I would design it is, you know, I would have my ID, type, name, all the things past as a prop. The one thing to notice here is you've passed required is equal to true. Now, when I see this input component, it looks something like this. So, all the input components are basically tied up using label and input and trust me, it's a good idea to always have a label with the input.

And if you see here, since I passed required equal to true as a prop, you know, it already knows that this field is a required field. And when you pass required equal to true, it already takes care that it is also, you know, going to hint the screen readers, if they are navigating through your input component. And this is how you would basically do it. So if you're passing input, if you're passing required as a prop, you will make sure that, you know, your input props is required true.

Now, one thing, if you saw here, is, you know, I also mentioned that area required should be true. So you should be doing this, you know, as a fallback, because there could be, there might be sometimes that you know, you don't have an HTML5 support. So often good to also include area required as true.

So let's say you have multiple required fields. And you know, how would you handle that? The way you would do that is, you know, providing some prior information to the screen reader users already. Saying that, you know, all the fields marked with asterisk are required. So you know, they already have the context while they're navigating through your web app. Provide more instructions more often. So there could be a there could be a field that is required and that, that has specific format. For example, a very good example is date. So let's say we have this input component we passed required to it. And this has, you know, all the props that needs to be passed to it. Now what happens here is, you know, you, you're sort of giving it a date, but you don't know where it specifies that what should be the format of your date. So here, what I do is, you know, I basically pass area labeled by to it. So saying that, you know, instruct. And this instruct is nothing but a span ID where you say, you know, your date must be of DDMMYY format. Now, this thing will give the screen readers enough information about this particular field already. So, you know, you're providing more information because your screen reader users might not know of what and how the format should be. So, when we use area labeled by, it is mostly intended to identify the element that labels the current element.

Which means, now, let's see what we did here. So, we were trying to provide more information about the label. So I always prefer doing it in a way where I use area described by instead of area labeled by. I'll quickly tell you the difference between them as well. So, here, instead of using area labeled by, I would go and use area described by, and I would pass instruct to it, nothing, a span element, and I give it an ID. Why did I use area described by? Because I'm providing more information about the label. And using area labeled by is generally used when you want to overwrite the label and not provide more information about it.

So, I prefer using area described by here. How would you handle errors? Let's quickly see because all of us have this error in the forms. So, it turns out that area described by is perfect when you want to basically deal with error handling. Let's quickly see how you would deal with. So, this is like a very small example where you say invalid email address.

So, let's have an input component. Make sure that your input component and error component is always tied together because that's how it should be, you know. When the screen reader is navigating through your website, they should know where the error is, what is the context. Which field has the error. And since these users are the screen reader users, they need to have that context of where the error is. So, you always make sure that you pass an area described by, and the error is nothing but a component, which I'll show you further in the next slide, is basically a component and has an ID email errors. This means your input and errors are always tied together. So, whenever there will be an error, it would always give a reference that this field has an error.

How your error component will look like is you'll have a div with a role alert, which is very important because, since the screen readers might come across this element, they need to have that information. Okay, there's something more important that I need to fix and the role attribute that you pass to the div will give that information. So very important stuff. So all I say is a field should always be mapped to the container error by area described by, and that's like the first important thing whenever you're dealing with errors. And you also saw in the code I passed an area invalid to it. So you see here area invalid and errors.length is greater than zero. Why I did that is because area invalid should always be used in conjunctions with associating and array, which means, you know, it will always check for. I mean, if you've passed required field, definitely it will check for required field. If there is an error, it will check, okay, if the error length is greater than zero, now let me pop up the error. So that's how area invalid works. And it's basically a hint to the screen reader that the field is an error.

How would you handle disabled buttons? So talking about disabled buttons, I mean, you know, all of us have gone through this, that when you disable the submit button, then you want the user to wait until whatever happens. So you'll only make it enable then. But this is not a good idea. I mean, to not disable the button. First thing, they're often removed from the accessibility tree. So it's not really a good idea.

What I would suggest is, I mean, if you have a component, let's say, you know, action component, which is like a button to me, and I pass a disabled attribute, how you should, you know, basically deal with it. So, you would do something like this, right. And as soon as you pass a disabled attribute to it, you know, it gets removed from the accessibility tree, which means if screen readers is going through that disabled button, they will no longer have an idea of whether this button is already there or not there. So, to work around this problem, the submit button should never be disabled, which means it should be disabled, but in a way, you know, only visible for the visual users. So, how I would do it is disable the button for the screen readers using area disabled and apply some visual styles for preventing touch and click.

So, let's quickly see how you would do this. Which means I have a button. I've passed an area disabled. Which means now my screen readers will know, okay, this button is disabled. But to make it look visually disabled, I'll pass some CSS to it. And, you know, the CSS that you would use is cursor, not allowed, opacity, so you cannot have a pointer events. Let's see what you would do for the keyboard users. You will prevent the click, right? You want the click to be prevented. So, are we done now? No. So, you would want to enable the button at some point. Make you set the area disabled to false, remove the disabled classes to visually make it look enabled, and this is how you would do it.

There are some rare cases where you could use disabled attribute, I mean, definitely. There could be some scenarios where you cannot skip. So, these scenarios are often, you know, maybe you have a carousel and you want to reach to the first or the last element, it makes sense to use that. There might be some off-screen controls that should not be focusable, makes sense there as well.

Next I would go to, you know, focus indicators. I mean, often by default if you have some links or buttons and if you press tab, you often see this, you know, focus ring around your element, and this is by default provided by the browsers. Do not remove them unless you have an alternative. And even if you have an alternative, for example, you know, what you would do, you know, your designer comes to you and says okay, you know, remove the default outline and, you know, make it more custom so that it is consistent across all the browsers. What you would do is, instead of setting the outline to none, I would say make it transparent so that, you know, in high contrast mode, sometimes box shadow behaves a little bit weird. So I would say don't remove it. I mean, make the outline as transparent.

How would you programmatically test your focus? I would say, you know, whenever you are dealing with link component, you need to be aware of where the focus is. So, you know, take charge of your focus. So simply if I land from one page to another, make sure that on that page you are focusing some main element that should be focused. Take charge of your focus. If you really want to test, you know, test your favorite websites by pressing tab, which means you'll start moving forward on all the interactive elements present on your web app. And if you want to go backwards, shift plus tab.

I often say handling dialogs is very difficult because, you know, you need to make sure that they're accessible as well. Which means once you open a dialogue, you know, the focus should be somewhere on the main element. And area React model is what I prefer is one of the accessible models already in the React community. Go check it out. React so each UI dialogue model is also something that I have tested. I mean, used. But there are some issues with the screen readers. They behave a little bit weird. So, there's also an issue attached to this. So, go and check out. I mean, there's a GitHub issue attached to this link. There's also React LI dialogue. So, worth checking that as well.

And all these models are accessible. So, you know, you can definitely use them.

Often I also consider DOM and the visual order should always match because, you know, you often have a power of using flexbox. But, you know, you need to be careful that it does not desynchronize the DOM. And your visual and the DOM order are both in sync.

You know, we all of us love performance. I mean, yes. But, you know, with performance, you should also take care that you're not ruining the accessibility. So, all of us this is a new thing that has come up, content visibility auto. And what it does, it enables the user agent to skip the elements rendering until it is needed, which means your page load will be much faster and allow for the faster user interaction with the on screen content. But one thing to note is, you know, you should use it at a right place. If you use it to an element that shouldn't be inside that, for example, headings and other content, it'll be suppressed by the content visibility. So, use it cautiously.

Also a nice article by Marcy Sutton which I always tell people to read it. Hiding content. Again, don't use it. Because, you know, it is it again gets removed from the accessibility tree. So, not a good idea. I mean, yes.

Instead what you would do is, you know, there are some of the valid cases where you would want to hide and show the wicket. I mean, all of us want to hide and show something on the web app. Now, how would you do something that is accessible to the screen readers and still hidden from the users? I mean, I told you not to use display none or, you know, visibility. How would you do it? I would like to create some sort of CSS using clip path. And one thing to note here is clip path is actually deprecated. So, they've got something new called a clip. But I often also keep the clip path because there are not all the browsers that support clip yet. So, always good to have a fallback. So, using the CSS, it will make the content of screen but still be accessible to the users. So, good idea. Whenever you want to use, you know, whenever you want to hide something that is visually hidden, always use this.

You could create a helper. I mean, in the CSS, if you're using style components, whatever. You could just create a helper and always use that CSS in that element. You could also create a component. I mean, wrap the component that you want to visually hide.

And quickly, let me give you some context of what would happen when you to hide something from the screen readers as well. So, you know, you would use area hidden true. Valid cases would be visually content of your icons meaning, which means here you want to give some meaning to your icons, and still make sure that you want to hide something from the screen readers. So, this is a nice table where I, you know, where I say, you know, often use certain attributes and classes, but make sure how visible and accessible it is. So, it's a quick table that summarizes the stuff.

Let's talk about icon component. I mean, all of us have icons in our project, right? How would you deal with that? So, having an icon component, and here if you see if passed, and icon, and my arrow top right is nothing, but it is some sort of icon, which is like an SVG, and I've also passed a label as a prop. Now, how I would handle this is I would have an icon component, you know, I would check, okay, you know, if there's no label, just return the return the SVG. I mean, return that particular icon with area hidden, which means because we don't require that icon to be known to the screen reader users. So, you know, that this is why we want to use here. And, you know, if there is a label already passed to the icon component, you could just display it and make sure that it is visually hidden, because, you know, you want to you want to give this information only to the screen reader users. And there's also a good example of link icon as well, which you could check later. If you want to know more about working with SVG icons, there's a good article by Florence. So, definitely worth checking.

How would you deal with image component? Same, I mean, you should make sure that, you know, you're passing alt source. And if you want to apply some sort of CSS, do that. Now, here you see what I've done is, you know, if you're passing the alt text, make sure you apply to it. And make sure, you know, sometimes you might just trim, you would like to apply trim to it because it makes sense. And what you also see is I have added a period to it, which means, you know, the screen reader would know that he or she, they need to take a pause here for that particular sentence. And it really helps the screen reader users to understand.

How you and, you know, all of us deal with opening a link in a tab and how you would deal with this. So, I prefer when the screen reader is sort of navigating on your website, whenever they open a link on a new, you know, on your website, there should be a warning that is spoken so that they know that this particular link is opening on the new tab. There should also be a visual warning in the text that the link is opening in the new tab. So any of the two things, quickly, if you take the component, I've done the same thing. You've passed something as a visual hidden class, which will only be visible, which will, you know, visually hidden.

Which means not available to the visual users, but still accessible to the screen readers. And it says opening in new tab. Which means now when you're trying to open something in a new tab, the screen readers will already have enough information about that.

Creating accessible animations, I often say, I mean I am a huge fan of, animations, but you should use it properly. I believe that tons of users do not like it, and you need to be mindful of the fact that not everybody experiences the way they do. So, some might feel dizziness, nausea. So, you should not have too much animations on your console. And if you have them, make a toggle, that if the user is trying to toggle that, it's off, and, you know, they have that thing on your website. So, there's already a way you could do it on your Windows or Mac machines. You could have in the system preferences and turn off the reduce motion, which means all your animations will be turned off. Or you could have like a media query, which is preferred reduced motion and use that. Which means all your animations would be off on that particular website. There's a good article by Josh. Definitely worth reading it on animations. One thing I also say is be careful with what you animate. So, I mean, I always provide an option for the user to toggle if they don't want animations. There's a good talk by well had. She talks about like, you know, inclusive motion. So, worth checking it out.

What are the development tools that you would use? And what are the lintings that you would use for accessibility? So, Jxli is one of the tools that statically checks for accessibility mistakes. So, worth checking it. There's aXe core which you can put up in your React application and it will give you all the console warnings already. If the issue is moderate, serious and you can start fixing it. There's automated accessibility testing which is Peli. Known as Peli. It runs accessibility test on your pages via the command line. So, basically NodeJS. And definitely worth checking that out. Make sure that, you know, if you're using sort of design systems, make sure you're using Storybook add-ons so that all of your accessibility stuff is right looked at the start. You can also use web browser extension, you know, to check all the accessibility issues.

I also wrote a book just to summarize whatever I learned from the past two years. And just go and check out. And yeah, thank you so much. And yeah, have a lovely day, everyone. That was an awesome, very informative talk. I learned so much already. A big thank you to Manjuta.

And let's go and check the answer to the question. So, Manjuta asked which one of these was not an accessibility principle. And you, 51% of you said that one that is not one of the main accessibility principles is that something is reproducible. Well, let's find out the answer. I have Manjuta with me. How are you doing today? Yeah, I'm doing good. How are you? I'm good. Thank you. So, can you tell us which one of these was the correct or incorrect answer? Yeah, that's correct. Reproducible is not the accessibility principle. Yes, I'm glad I got it right as well. I'm super happy.

But we've got a couple of questions. We actually have so many questions. People love this talk and wanted to learn so much more about it. So, I'm not going to be able to hit all of these talks. I just want all of these questions, but I just want to remind you that there will be a speaker room where you can ask your question if it was missed.

So, we'll go through. I'm going to do them in order just to be fair. We've got a question from Jordan who's asked, would blind or disabled users necessarily be able to see the asterisk? And would that be indicated fully when they are focused on the field? No, they would not be able to see, definitely. But when the screen reader will read it, it will read it aloud saying that asterisk. But basically, asterisk has some problems with all the screen readers, and that is why we have this required fields that which goes through and you know, basically hints them that this is required field. I mean, not all the screen readers read asterisk very loud, which might be misleading for the blind user. Yeah, that's something I've never thought about, but I've learned it today.

We've got another question from Benito about dates. So for date inputs, are text inputs with clear instructions better for accessibilities than date pickers where you can't type the date in? Can you repeat the question again? So they asked about date inputs. And they're asking about whether for a date input, would it be better to use a text input with clear instructions on formatting or a date picker? I would suggest creating your own sort of date picker that also handles text, because sometimes this is really necessary for the screen reader users. I mean you can have a third party library but make sure that you also have an alternative that supports screen reader that might be visible only for the screen readers, although it is not visually, you can see it, but yes, I mean having a text input is really a great idea.

Cool. Now we had a talk earlier about testing and let's bring this to the field of accessibility. We've got Hama who asked, which library would you suggest to use for automatically testing accessibility? I think I discussed in my talk as well Peli, which is a like sort of automated testing tool and it basically runs on your terminal. So if you sort of get it on board in your project, you can basically run, you can have it in your build process and you can have it as an automated testing process. So while your build is running, you can also automatically test that you know if there's anything failing or if there's anything, you know, not okay. So I would suggest Peli is one of the great tools.

Nice. Hama also has another question, what kind of principles do you have in your company for checking for accessibility as part of Agile implementation? Is there a specific part of that process where you talk about accessibility? I think we do use tools and it's always good to use tools. But you know, not all the issues could be solved by using tools. We use X-Core, which is made by Deque. It's one of the good tools to use, but we also make sure that we do a lot of user testing using screen readers, which is, I would suggest everyone, although, you know, try running your website through keyboard as if you're like a blind user and see if you can navigate to your website. Awesome. So, I think that is a very good idea to start with if you're already, you know, bringing accessibility in your company. Awesome. There's always easy steps for things to people to take. Thank you so much, Bhanjula. It's been great spending time with you. Thank you.