Building UIs - By the People, for the People!

So, I'll be talking about an interesting topic that's building UIs by the people, for the people. So, before diving in, for those who don't know me, I'm Nikhil. I'm a software engineer at Postman. I mostly handle stuff around Postman on the web, Postman's desktop platform and the design system at Postman. So, I'll be there. You can connect with me via Twitter or GitHub. Come say hi. Would love to have a chat. All right. So, before diving in, let's understand a small analogy, which I really like when introducing a concept like an accessibility thing. So, imagine if there's a constitution of a country, it guarantees the citizens some rights. Let's say there's right to education, there's right to religion, and there's also right to expression. So, stuff like that. Taking that just out of the example of a constitution of a country, we can say that, like, the constitution is the one that guarantees an equality of stature, regardless of what the background of a person is. Now, when it comes to accessibility, we can make some changes to the statement. And now the statement can say that, all right. Accessibility also does the same thing. It guarantees us an equality of consumption of a user interface, regardless of what the disability of a person is. So, simple things, simple put. Accessibility just means that if I have a product or a service, accessibility would allow a person, regardless of any sort of disability that he or she might have, to access the product and use all its features in a seamless experience. So, in our case, we'll be restricting this talk to only web content accessibility, but accessibility is a far wider topic. We use many tools to have accessible experience for our users, which is using screen readers, which can help us announce what is there on the screen for people who have vision, a problem with vision. There's keyboard navigation, so that the ones who don't have a mouse or have a problem with having a steady hand over their mouse cannot use it directly. So there's keyboard accessibility for that. But we'll discuss more about that once we progress to the talk. So going ahead, you might already know that we already have accessibility there in the real world, right? So for ones who have a problem with walking, we have wheelchairs for them so that they can go around. We have a stick invented for people who have a problem with vision, or we have braille scripts so people who have problems with vision can read clearly. So if accessibility has so much of its importance being realized in the real world, so why would our JS world be left behind, right? So with this thought in hand, let's see two important concepts before progressing with the talk. So on the left, you'll be able to see there's WCAG. Now this term means Web Content Accessibility Guidelines. Now this is nothing fancy, but just a set of guidelines and checklists that have been put together by a group of people around the world. And these checklists help people make the content inside their apps more accessible and more reachable to any sorts of people with any disability. Now on the right is just a subset of this WCAG, which we say W-A-I-A-R-E-A, which stands for Web Accessibility Initiative, Accessibility Rich Applications. Now what they say is that, okay, you want to meet WCAG guidelines? Now, okay, I have some APIs so that you can use in your code and you can meet those guidelines. So we already know that there are many such accessibility APIs like this, there's ARIA Invalid, which says that, okay, screen readers will know that once an input is invalid, they can announce that on the screen. There's ARIA Required to announce on the screen that, hey, you're on an input which requires a feed. So there's stuff like that. And we'll see more about it in the coming slides. But yeah, just one thing to keep a note of in mind is, like, especially this is like especially related to the JSX or the React world that we have this sort of like a mental model that we have a camel case for every prop, but that's not the same with accessibility. So with these accessibility attributes, we just have to use them as it is that you have been using with HTML, which is like a hyphen separated values and not with a camel case. So just a small tip there. And moving on to like why we should care about accessibility. Now the very first and foremost reason is you might be surprised to know that 15% of the world's population has some sort of disability. So if you're not making our apps accessible, that means 15% of a big chunk of our audience, which is a number that we can't ignore, cannot use our apps in the way that we want. And second thing is like if we have an application that is being going to use like in multiple countries, it has a reach over like the whole world, we might want to see that there are countries which really like you can still give importance to accessibility and like the people who are like having, they have some disability. For example, there was like a very recent case, right? Which we all know regarding the Domino's website where we, according to the Americans Disability Act, it was not compliant with accessibility practices that should be there. So if you're creating a website and you are going to go pan world, make sure to have these things in mind. All right, so with this talk, we're going to bust up some myths for accessibility. For example, accessibility is just for disabled people. I wouldn't say that because disability can also mean if someone does not have a mouse, that's also disability. Like if you show a loader on a screen, but something is still being fetched, that's also an accessible experience that we're giving to users. So the deeper meaning of accessibility is to cater to any sorts of disability and rather not just physical disability. So that's just a subset. And second is that accessibility is hard. I think we're going to see this at the end of this talk that no, it's not. And accessibility is also not just about like blatant idea attacks. And there's like 10 or more practices that you can do so that our apps become more accessible. And yes, this talk is not an accessibility primer. This is not just a theory class. I would want to like make this more and more inclusive and like more demo driven so that after this talk, we take a key takeaway of what the deeper meaning of accessibility is and how we can get started without reading those big, big blogs on the internet. All right. So with all these thoughts in mind, let's get started. So the first and foremost tip that I give to everyone is using the right HTML tags, which usually wins up most of the battle for us for accessibility. Now when we use the right HTML tags, our screen readers use that information to deliver the right context over like what is there on the screen. For example, if you're using a button HTML, the screen readers can tell people that, okay, this is a button. And it also like these HTML tags also give you like some wins big day. Like for example, you don't have to handle tabbing order of like your buttons or like inside a form if you're using many input elements. You don't have to think about like what should be tabbed first, what should be tabbed last, what measure is a focus line first or not. So this is like all big thing once you use the right HTML. And also accessibility can also, like if you want to extend this definition of accessibility, you have your peers who are using the same HTML structure in their daily code base and they're working on to it. And if you use like something on the left that you see like a big list of this, it might be a hard time for them to like, they have to just open each of their div, they have to find out, oh, what, oh, this is like a header div. Oh, then in this div, okay, there's this main section here in this last div. Oh, this is a footer. Okay. So like I said, if you see, if you're using a right set of HTML, it not only gives screen readers a good, like a screen readers a good experience, but also gives your colleagues and your developers to find out what's there in like each and every part of your app. So there's just a small chart to help you find out like what does each area and like where, what should be the semantic tag for every area should be. So for example, the top most thing should be a header, there should be a nav tag after the header that should show navigation and stuff like that. And accessible JSX, as I already mentioned is like not accessible HTML. So like, I usually like see some queries from people that they say that, Hey, I'm using these three things, as you mentioned, Nikhil, but I'm not still having accessibility. So I would say that there's accessible HTML that should be implied to your accessible components like header and main on the left that should make it make things accessible. So another thing to keep in mind. And let me also give you a like a small gist of like, we are also the ones who make things difficult for both users and like also us, right? So let's imagine a case where we have a div and on a click, we just have a function which will handle stuff when this div is clicked. Now, this is giving a simulation of button, but now you will say that, Hey, my screen readers are not reading this. They read this as a div. How do I tell my screen readers? Now you'll say, okay, we have IE attacks. Let's give it a rule as button. And we'll say, Oh, that's fine. Now I've solved it. And then you'll say that, Hey, but it does not give me a tabbing experience. How do I show that a particular focus comes in when someone is there on this particular day for a button when someone clicks it? So we will say, okay, there's tab index, you have to give it a value zero and you have to, so you have to do all of this mumbo jumbo, right? When you're not using semantic HTML, but the reality was like, like super simple. You just had to use something that was just a button that all of that came out, like picked in for you. So if you're using the right HTML, you also have less of a, for you and lesser work for screen readers, et cetera. All right, coming into the next topic, that's keyword accessibility. Now, as the name already suggests, keyword accessibility simply means that your app should be usable and you should be able to interact with any part of the app by just dabbing in, like without using a mouse, you should be able to use it. And that means that there should also be like no keyword traps. Like if I like keep pressing tab, it's, it's that I should be able to go to every part of my app, like every part of my screen. And like, not just, I just like keep revolving around only one or two buttons and inputs. So that's just basically what it means. Now why is keyword accessibility important? The first and foremost thing is like, if like there are people who have problem with vision or like who are like blind, they usually rely on keyboards. And like when they dab on things, they rely on the screen reader so that the screen readers tell them where exactly on the page are they. So that is really important. And also like if someone is like not having an like a vision with a problem with the vision, there is a problem with motor disabilities where like if someone is using a mouse, they are not able to have a steady hand. Or like they have a problem with like interacting by a mouse because their hand is not steady. So that's also when keyword accessibility comes into picture because they have to rely on a keyboard. And thirdly is like, as in general also, we all love keywords. Like if you're also seeing like in this slide, I'm using more of a, like my keyboard's navigations to go between the screens rather than, and like rather than all the, like the mouse and the trackpad. Right. So it's like good to have keyword accessibility in your application in this way. So I like this semantic HTML for the win here itself, because I am using like in this small demo, I am using a login form and in here I am showing that once I tab, I'm like using, I'm like not using any mouse. I'm just like simply tabbing over elements and I am able to go to every right set of my HTML in like the right order. So there's semantic HTML for the win. So although like a browser gives you a default focus, like I think as we just saw in this screen, so like the browser is giving us like a default blue color border on every element, but we can like make it customizable and like more vibrant because we want to make our websites look more beautiful. Right. So you can use a focus pseudo class in this case and apply a border or like you can add a box shadow in those cases to make your focus styles more better. There can also be a case where like you have an input form and you want to focus by default like specifically one input field whenever a form loads, because that's a better experience. So in that case, although this snippet is like more focused towards React, but you can use that in JavaScript itself. So like using this use effect hook that you have in React, you can use a ref of that particular input and using that reference, you can focus it at the time this page loads. Now coming up to the inputs and the labels, it's always a good practice to use labels and those labels should point up to your inputs. Like whenever someone clicks on a label, the input element automatically gets focused, which is like a very small thing, but a good user experience. So there's an HTML for attribute that one can use. So that's a very simple thing in a one line code to add. Now you'll ask me that, Hey Nikhil, there's not every time that I will need a label with my input, right? So in that case, my answer would be still have a label, but use a class to hide that label from your screen. But that label should still be rendered into your DOM. So I have this class called visually hidden, which I'm using to hide my label, but my label is actually there in the DOM. It's rendered because screen readers are still going to see what's rendered on the DOM because they want to announce what this input is all about, right? And they're going to make use of that label. All right. There's like also a bunch of ARIA level tags that you can use. For example, there's ARIA invalid true, which gives like, which lets the screen readers know that, Hey, you are, your input is invalid and they can announce it on the screen. And again, like accessible forms, I have a ton of other input elements like field set legend so that they can give more information about the forms. Now coming to navigation, navigation is also like very important because now in our case, we have so many like nested level of spars and we are, once we are like in deep down into like in a flow, we want to see like that exactly where we are and like we want to navigate faster. So there's been like navigational element that breadcrumbs come into picture. So coming up to this, you would want to handle a navigation to a main content when it comes to a tabbing experience, right? So like if someone is tabbing and you have a lot of links in them, some users might not want to go to those links. They directly want to switch to the main content of your application. And that's where we can like just insert an anchor class, an anchor tag, and that and clicking on that anchor will directly skip our tabbing experience. You just go to the main content. So that will be like another user experience for those people who are just like keyboards. All right. Coming to accessible SVGs, although like, yes, we already know how to use SVGs, but using a title and a description attribute inside them can help screen readers know what this SVG is all about. So like when announcing, they will not go haywire, but they will know a small description about it. So it gives users like a meaningful picture about, okay, what this image is or like what this SVG is. All right. So using a document title is like a very small thing. We usually like usually skip this, but it's a very important thing. So once we have in like inside us parse, which like a single page applications like meet in JavaScript or react, although our page is changing, but our document titles usually remain the same. So we also want to keep changing our document titles because our screen readers are also going to read it. So like, let's say again, in React, you can use the component readmount or like you can also use hooks to change the document title. Like every time you like change the screens or like every time you think that you are going from one page to another page. So that's a better user experience. There's also a library called like React document title that you can use. And I feel like it's like much more declarative, but you can use any of those approaches. It's totally up to you. All right. But this, I think I like shared like a few ideas with you. And there's like, again, like accessibility is like, although a very long thing, it's a long journey, but with this talk, you'll be able to get things started and you will have like, I think most of the things like you will be able to be in a position to start migrating your screens and using like starting to develop some accessibility practices in your apps. There's also like a ton of examples that like I wanted to cover, but I could not do to the time. There's like textual content that should be like precise and clear to people who are like not having the right vision. There should be internationalization in place because people who are across like different, like who live across different areas of the world, they don't have the same language. They might be like other sorts of languages that other than English that they want to use the app in. So if our apps are converted to the same language, according to the region, that makes it like more usable and more appealing to people. So there's like another like ton of practices. So I would say like, if you, if anyone's interested, go ahead and deep down a deep dive into these concepts. All right. So with this, let's quickly see a demo of like a same login app that I had created. I'll just first show you what was like, what the screen reader will announce in this app. Which does not have any civility in hand. And then we'll see like after applying these practices that I just discussed in the talk, what can like, what was the change to like someone. So just like, just close your eyes and like try to vision, like try to see that what you in, in the space of a blind user or like a visually impaired person would see or like when you are tabbing in this form. So all right, let me just start this recording. So this is the screen reader. And this is the screen reader. And this is the screen reader. And this is the screen reader. And this is the screen reader. And this is the screen reader. You are currently on a link inside web content voiceover of that web content. All right. Let's minimize this. So yeah, although I think web content, yeah. So basically now you would see like the image name is like being pronounced up to like its length and I'm like not getting some meaningful information about like where exactly I am. Now let's try to see what exactly is the experience now after we add some accessibility. Okay. Software is entering react good daily demo web content visited link skip to main content visited link skip to main content Chrome main login foreign banner image image enter username enter require edit text enter password enter require secure edit text submit button visited link learn more list two items visited link contact us heading level one login for main you login foreign banner image image enter user. All right. So seems to be slightly better right software. So all right. So I think that we have been making some progress. Another like some small things to mention. I really like this tool but axe dev tools and I would really recommend anyone who has been handling accessibility use this because it not only shows you the error like in terms of the accessibility practices that you've been doing but also it also gives you a fix up to up to that. So and it's also very descriptive. So I really love this. So would advise like anyone who is interested to use it. All right. So I guess we would want to end our discussion and there are just like some links that are added which are related to the demos that I have actually added and also the link to the slides which I don't anyway share with everyone. Some of my personal favorites that I think are like a very good reads other than this and would also give you like a like more knowledge around like some other things like we wish we could not discuss in a talk. So feel free to go ahead with it. And yes let's make our web content more accessible for everyone. So I think I hope with this talk you would be able to get some insights out of it and you will be able to use now accessibility into your apps. On a side note we at Postman are also like fascinated about technologies at React and also like accessibility. So if you would want to come join us with this journey of like building something cool feel free to reach out to us at our careers page and we'll be glad to connect. All right with this I rest my case and thanks a lot for having me out.