Accessible Component System Through Customization

[♪ music ♪ & crowd cheering ♪ You know what? I'm still... I need to recover a bit from the whole night of getting a Switch. Even though I know I will not use it, I don't know who will use it.

Anyway, how you doing, everyone? Are you having a good time? Yes! And you know what? This is my new motto now, Accessibility will bring you a Switch. Okay. That is my goal, to talk about accessible components. Let me take a bit of water. Excuse me. Woo, okay. Come.

So, quickly about me, because we have 20 minutes, so I don't have time to talk about me a lot, I'm Maya Chavin, I'm a Senior Software Engineer in Microsoft, and yes, I'm not going to fix the window for you, so don't expect it. And I'm also write books, I have more to view, react, anything about component design, you can follow me, or you can also try my book for free.

Anyway, so we talked about UI component library. How many people here ever use a UI component in their life? Oh, that's a lot. How many of you ever write a component library? Wow, that's good. That's exactly what I expected, because if you don't raise your hand, meaning either you don't do your work properly, or you don't write any frontend code, and you probably shouldn't be.

Anyway, what exactly is a component library? What defines a component in a component library? First of all, it has to be reusable, meaning if you have a sidebar, it has to be able to display a menu or a card. You can reuse it in many ways, but the functionality stays the same. It has to be stylable, meaning you have a toast notification. It can be styled in different colors and different stylings in order to represent what it's meant for. In addition to this, you also need to make sure that the component that you offer is customizable according to what users need. Let's say if I don't want to have an icon like the default icon, I can change it. Or I can decide that the X button is not accessible enough, so I change to a text button. This is customizable. And we talk about that meaning, accessible.

A lot of people, a lot of developers, tend to think that no one cares about accessibility. Accessibility is something very hard and not relevant to component library at all, but this is the wrong thing. You develop a component, it has to be accessible at some standard in order for the whole system to work based on what you do. And talking about accessible, it also means that you have a website that looks good on desktop. It also has to look good on mobile and not just on mobile, in any Zoom, any device, screen view port, 200, 400 percent, everyone nowadays needs Zoom anyway, and that comes down to responsiveness.

And lastly, the components you offer have to be isolated and testable. Well, no one uses a component library without being tested properly, right? Because otherwise you don't want to end up in the morning, wake up and saw that someone report another bug that belonged to the component library because the component library doesn't test and you have no idea how to fix it.

And that comes to these categories divided into things. One is visual consistency. That means when you develop a component library you need to make sure you have a standard to follow. Colors, palettes, painting, typography all of these are visual things. No user will want to experience something not consistent, both developer and end user. This is the UI part of component library.

And the second category is functional consistency. What does it mean? If the user sees a close button on a sidebar it means, when he clicks on it, he expects to close it. No matter what the designer can tell you, a close button only needs to do one thing. Close it. Don't surprise anyone. No one likes surprises. I don't like surprises. So, just don't do anything extra. And that part is user experience of component library. And these two categories come down to one thing.

People think that component library is something like, just a big thing. Like, something you offer and people will use it. In fact, component library is just a small part of the whole design system you are building. And the component library is actually the implementation code after you define all these style guides, design system, themes, typography, everything else. And when you develop a component library it's not just sitting down there and write code. It's sitting down there planning a good design system. So, how are we going to build a component library? All of that. Well, first of all, you can't decide that you want to build a generic component library that have everything else, have multiple, a lot of different components for every single use case. No, that's not the case. When you build a component library you need to plan and decide what, who and why you build it for. And one of the example is from one of my projects called Storefront UI. We built a component library tailored specifically to a user from e-commerce industry.

This way it keeps us more focused and based on that we build our component on four categories. Customizability, scalability, accessibility, and ease of use. And today we're going to talk about these four categories only. Well, we should talk more, but we don't have time. So let's start.

Accessibility, everyone knows what accessibility is, right? Well then tell me how you're going to click on this button. We need to click on this to continue. Anyone? Any idea how to click on it? My mouse? Come, take your mouse and click on it. By anything? Touch? Can you touch from here, from far away? You can't because it's not accessible. It's the image. So no matter how great it looks, it's not focusable, it's not usable, it's not accessible. And that means accessibility, when we talk about accessibility, we talk about keyboard navigation in also in addition to everything else.

Keyboard navigation, this is actually a funny picture because if you pay attention, you will not have the delete button here. So if you want to click control and delete, you won't be able to. This is actually the real keyboard that was designed a long time ago. So they have the keyboard and then they have another additional keyboard for the delete button and so on. And it's meant so that you have to use both of your hands to do control and delete. But then it's not accessible because these people don't have enough both hands. That's why later on they come down and they designed this again and they put control at and they're on the same side so we can use one hand to click them.

The next thing is called a contrast. I saw here a lot of people were in class. And that's why it's very important because every one of us here has a problem with color contrast. Otherwise, we wouldn't need dark mode or light mode. They won't scream about it's too light. I'm a vampire. Something like that. A landmark and content layout. How your website will look like when there's no CSS. What you will end up... The first thing in your application and what will attract the user the most when there are 10 applications.

The landmark and content layout is very important for also for screen reader. And lastly, where am I landing when I do the tab? When I click tab for the first time, I enter your application. Focusability. All of this make into the whole things of accessibility guideline.

And not only that, you have more. Content layout nowadays you use on phone. So you always have to zoom in and zoom out. This 200%, 40% is the standard for accessibility readable enough. Understandable content localization. Not everyone is native English speaker. And you also make sure that people understand your website correctly. Form handling, media typography, external link, tab orders, all of this, a lot. And more. That's not a full list. All of this make into accessibility.

And you probably at the moment think it's very, very annoying and very, very hard to do. Yes, everyone on my team said the same thing. It's very hard to comply. But if you divide it into smaller scope, it will be easier. Everyone here working with design system. Here is an example of atomic design. Which breaks down the component into subcomponents and smaller, smaller pieces of the whole system. And then you build your application on top of each piece.

So, for accessibility, I would say if you're in the bottom component, which is the atomic component, such as button. What you focus here is not the whole accessibility compliant. You only need to focus on the color, the focus of the landmark usage where you're using the button or you're using something that is not a button. Informative contents, do you have alternative text for an icon button and so on. Typography, all of this is from the lowest level. And only when you start building more complex component on top of this component, you have to be more aware of navigation flow. Layout landmark, a table of form, how to control them, focus flow between the connection between different component together in order to provide the whole experience and so on and so forth.

The good news is the OneArea team developed a very nice page which is called the patterns page that will give you all the common patterns for accessibility with ready-to-use code and what you need to implement in order to have it work. You can check it out it's still work in progress but they have a lot of nice features there.

In this talk we don't have enough time to talk about all these things so I will focus on three most common examples. A dialogue is a complex dialogue where you can do a lot of things like fill in the form, submit the form or just an alert dialogue to tell you that you are doing something wrong and if you are sure that you know you are doing something wrong, you click on OK and that's it. To make the dialogue accessible you need to first auto focus on the first focussable element On Escape keyboard navigation, on Escape button, it has to close the modem or you click on the background or you click on the button, it has to close the modem first. And lastly, when you close the modem, this is important, the focus needs to be restored. Whatever triggers the modem has to be refocused.

How are we doing it? How many people here are using Vue? Oh, come on. Anyway, this is actually a code of one of the component library, the store-from-UI one. So, if UI react or Angular is similar, you know, is JavaScript in the end. So here, the implementation is pretty simple. So, they have aria-modal, which shows just a tab-index, key-down, and ref, something like that. And then, in order to do all the click, you do click-outside, key-down, and trap-focus. Remember this trap-focus. Everything in the dialogue stays in the dialogue. You don't have focus outside of the dialogue at all. So when you implement the dialogue, remember that. Same thing with TuneTick.

And does it work? Let's see. Here is an example. You go to checkout, you click on it, you see that the dialogue is hidden. Because the dialogue was implemented right below the button, and according to the order of appearance in the website, it's not working. To overcome that, you need to change it to a z-index to make sure it appears in front. But you know, using a z-index is not the proper way to handle things because then you end up with z-index 9999 in the end. So another way to do it, and here, if you click on the close button, you don't have the refocus. User have no idea where they are. And this is the wrong implementation because it's not accessible enough. Instead, what you can do is try to use dialogue element. This is the native HTML dialogue element, which allows you to get the dialogue functionality without doing anything. And then you can use form with method dialogue and you don't have to click on the close thing.

It's doing it automatically. And what you're doing here, just add a watch. That's it. Now it will work. Let's see. I have one minute. I should be okay. You can see that? It's autofocus on the first thing, and then now when you close it, you can continue the flow to the next navigable element. And this is the way you should do. Whenever a user is disturbed by something, when the user is returning back to the flow, make sure that he returns at the same time at the same place.

The next example is toontips. We all know toontips, right? The toontip is so simple, just a text. When you hover on it, it displays it. But this is on focus, but there's no toontip. Why? Because there's no hover event on anything. There's no hover event. You cannot add the event to display a toontip on hover. In touchscreen, there's no hover. In keyboard, there's no hover. To do that, either you can use CSS pseudocode, slotted focus, or just use the focus event to listen and display the toontip accordingly. And remember, in the toontip, it's only to display information, and you're not supposed to put any link inside. No. No link, because that is a very antipatent for toontip.

The last example is about loading. Let's say you have a lobby, loading. Okay, where's my focus? Why go back on the top? So now, in here I'm using visual, so to fix it, I will have to say it to if, which I don't know why, in Vue, it works this way. In React, if you do if, you will never get back the focus, because the element is already unmounted from the domain, the browser doesn't know that it's working there. Here, it's working in the way that when you finish, when you do the next step, it will refocus on the old one, which is good, okay, kind of. Anyway, so some of the solutions to fix this is to keep the ref of the button reference, don't unmount the button and just hide it, so you will always have it back, and trigger refocus when the loading finishes.

Anyway, so some of the solutions to fix this is to keep the ref of the button reference, don't unmount the button and just hide it, so you will always have it back, and trigger refocus when the loading finishes. And some of the guides here is definitely invisible view. Don't use dip, number one. Don't use dip when you don't have to use dip. And test everything. Test all the combinations, okay.

Next thing, customizability, since I only have one minute left, I have to move forward fast. So customizability, we have, well, as a designer, you know, we have a trigger million things to think of, and icons, font size, color theme, everything is here. Utility customization, no one is happy with whatever you do. Even you. So they always want to change it. The second thing is how you're going to change the content button. You can do it by using CSS variable or using container queries to style the container specifically. And this will keep your component isolated enough and not breaking anything of the applications. And to change it, you can use a lot of props like here. You have an icon, a lot of icon props here. All you can do is only a single use case to cover, to make it better and leave the 20% left for user instead of providing a lot of props. But again, pay attention. If you do this, it can end up killing you because one user overwrites your default design. Your design system gone bust. And there's no accessibility.

Scalability. Here, if you design the design system good enough, you will have logic and components separately and then you can combine them to make into a final design, working application with less work to do. And lastly, how are you going to use it? This talks about documentation. Documentation is about writing, there's a lot of things to handle, but Copilot here is for help but you don't trust Copilot 100%. First, you need to define what is the single sort of truth. Storyblock is a good one. Second, you always have to have a very good code structure because accessibility is always for developer. The next one who come to your team needs to understand how they can navigate around your code. And instruction, short and concise.

Don't give us 3,000 essays' documentation because no one is going to read it. An example is always good. Accessibility tip on example is always a thing to do. It helps people to navigate, to copy and paste, to know how the component works. And lastly, for your team, you can design some accessibility guidelines with some tips and tricks and common bugs. How to fix it helps them help you to do your job and build a component. And lastly, using a co-pilot to automate whatever should be automated.

Okay, so key takeaway. All of this comes down to one thing, plan your component ahead. And some resources here, and that's it. Thank you. APPLAUSE

We have loads of questions, and because it's a subject very dear to my heart, I'm just prioritising them as I care. You say don't use div if you don't have to use it. Can you give me more details about why you shouldn't use div if there's something better to use? Okay, so everyone here knows what div stands for? It's a division element in HTML. Which means it's more like an anonymous, random person on the street. So if you're using that anonymous, random person on the street to display some app, the screen reader won't be able to detect what this is going to be for. And that's the second thing, we have elements that are dedicated for special types, such as search box. That one is not supported yet, but you have a section, you have car, you have input, a button. It's for buttons, so use it. Yeah, if anybody's interested, later I'll tweet. A couple of years ago I did a videocast with a woman called Leonie Watson, who is a blind web developer. She used to be a designer and went blind in her twenties. And I asked her to show me how she navigates a website with a screen reader. And it's a six-minute video just showing how using the nav element rather than div class equals nav means that a screen reader user can just press one button and the focus will go immediately to the navigation or jump straight over the navigation into the main content. Whereas if you just use a div, those shortcuts are not there for somebody who's a screen reader user. And if you're not a screen reader user, then those things are completely oblivious to you and you don't care. So if typing in nav is as many bytes as div, but you type in nav and you're giving blind people a much better experience, sorry that was a question for you and I'm talking, so. Sorry. But they don't invite me to speak at these things. Can they have the slides, Maya? Will you tweet out a link for the slides? Well, if you print me a copy I'll give you my slides.

Okay. Bribery and corruption for half of Microsoft here. If you buy Maya a coffee, you can have a copy of the slides. No, I'm joking. I have to tweet my slides afterwards. I just need to convert it to proper PowerPoint that is accessible enough, so.

Here's an interesting question. Why would you create a UI component library from scratch when you could do something like take something like Radix UI, which has UnStyle components that you can then apply your styles to? Well, you know what? It's not one or the other. It's not black and white. Basically, it really depends on what your use case, whether if you only need to build a system or an application for one time for people. You don't need to write the whole component system from scratch. But if you're working in a company like a corporate company, for example, like Microsoft, then we have to build on ourselves or things that would be reusable by different teams internally. And as the corporate grows, using an external library will be a bit more problematic in terms of bug fixing, maintainability, and testing, and so on. Because you always have to rely on someone to provide your service. Even with Microsoft, we still have problems with working with the component libraries inside.

You said don't use ARIA, why ARIA is the accessible rich internet applications specification that can sit on top of HTML. Why did you say don't use ARIA when ARIA is meant to be for accessibility? Well, the rule is don't use ARIA when you don't have to use ARIA. That's the one rule. Basically, you should use ARIA when you have no alternative. For example, you know rows, button, right, row as a button? But if you have a button element, you don't need row as a button because that's just overengineering. ARIA is only meant to provide you additional supporting things for screen readers to be able to pick up your element, your component correctly. So if you have a way to do it without it, do it. Otherwise, it just gives a lot of complexity to your code. Yeah, I second that. Basically, if you have something that's supposed to be clickable and it's supposed to do something, if it looks like a button, if it smells like a button, just use a button. Don't use div role equals button, tab index equals minus 1, listen for the spacebar. All of this – can I say shit? Yeah, all of that shit. Just use a button. Buttons are good.

The question that everybody gets when they're talking about accessibility, what is the best automated tooling to check for at least minimal accessibility? Oh, I want to talk about it.

I just don't have enough time on my talk. Okay, for that, if you're using playwrights or probably also testing or any automation testing, there's a library that's developed by the XCore team that is open source. You can get an integration for it, and you can plug into your automation system. And then you will run it on the end-to-end test on your suit, and it will help you cover I think almost like 80% of your accessibility testing.

Well, you can talk to me after the talk, and I'll show you the tool. Also, if you really want to test and you don't know where to start, you can install the Accessibility Insights for the web. That's the project from Microsoft. That's an extension that allows you to run the scanning of the whole web page and give you exactly what's compliant, what is not compliant, and the tab order of your website so you know whether the flow of the tab is correct or not.

This is the last question, and it's a question for Maya, but it's going to be a question for Maya and Bruce because I have opinions. How do you persuade people higher up in the organization to care about accessibility and to allow you the time and time cost to implement accessibility? One of the nice things about working in Microsoft is that you don't have to do that because it's the compliance policy. You just need to put it there, say, you're not going to release this product because it's not compliant to the policy of the company, and that stops everyone. But, well, sorry, other outside of Microsoft, in other companies, I will say that you need to give them a very good experience, a very good example why it's important for the user to get accessible, for the application to get accessible.

For example, you can do a small demo with everything black and ask them to navigate through the application and see if it works, and then you can also show them whether accessibility users are very important to the industry. For example, e-commerce is a very good example for accessibility compliance because everyone uses websites to buy stuff, applications to buy stuff, you don't want to exclude anyone that can potentially bring you profit, regardless how small it is, so you just need to show them. I mean I used to, what I did is I just put a whole blank page and asked them to navigate through that black page, and asked them to tell me their experience, and then it just worked.

Yeah, what Maya said. Basically if you need to persuade your bosses to care about accessibility, the best thing you can do is leave and go and work for a company that gives a shit about human rights, gives a shit about not discriminating, gives a shit about user experience. And that's why I'm not employed at the moment. Friends of JS Nation, please give a big hand for Maya Chavin.