Building UIs - By the People, for the People!

Hey everyone, hope you all are having a great day. 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 Xen 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 accessibility thing. So imagine if there's a constitution of a country, it guarantees the citizen some rights, let's say there's a right to education, there's right to religion, and there's also a 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. 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 sorts 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 like a far wider topic. We use many tools to have accessible experience for our users, which is like using screen readers, which can help us announce what is there on the screen for people who have vision, like 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 keyword accessibility for that. But we'll discuss more about it once we progress with 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 their vision, or even we have braille scripts so that people who have problems with vision can read clearly. So, if accessibility has so much of its importance been realized in the real world, so why would a 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 like more reachable to any sorts of people with any disability. Now, on the right is just a subset of this WCAG, which we say WAI, 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 an 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 the 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 like, which is a number that we can't ignore, cannot use our apps in the way that we want, right. And second thing is like if we have, like, if we have a application that is being going to use like in multiple countries, it's like, has a reach over like, like the whole world. We might want to like, 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 to the accessibility practices that should be there. So if you are getting 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 a disability. Like if you show a loader on a screen when something is still being fetched, that's also an accessible experience that they'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 aria and there's like, 10 or more practice 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 like what the deeper meaning of accessibility is and how we can get started without reading those big, big blogs on the internet, right? 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 that 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. For example, you don't have to handed, having order of like your buttons or like inside a farm, if you're using many input elements, you don't have to think about like, what should be tapped first? What should be tapped last? What measure is a focus like first or not? So this is like all baked in. Once you do 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 like a big list of divs, it might be 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. But on the right side, if you see, if we are using a right set of HTML, it not only gives screen readers a good like a screen reader, a good experience, but also gives your colleagues and your developers to find out what's there in 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 like. For example, the top most thing should be a header. There should be a nav tag after the header that you show navigation and stuff like 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 mean on the left, that should make it make things accessible. So another thing to keep in mind, and let me also give you, I 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, uh, this is giving a simulation of button, but now you will say that, Hey. I, my screen readers are not reading this. They read this as a div. I, how, how do I tell my screen readers? Now you'll say, okay, we have IA text. Let's give it a role as button. And we will 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, uh, a particular focus comes in when someone is there on this particular day for a button, but 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 mambo-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 big thing for you. So if you're using the right HTML, you also have less of both for you and less of both was three leaders, et cetera.

All right. Coming into the next topic, that's keyword accessibility. Now, as the name already suggests, keyword accessibility simply means that, uh, your app should be usable and you should be able to interact with any part of that 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 that it's, it's that I should be able to go to every part of my app, like every part of my screen and 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? Uh, 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 tab 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, uh, 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 and like, they have a problem with like interacting by a mouse because their hand is not steady, right. So that's also when keyboard accessibility comes into picture because they have to rely on a keyboard. And thirdly is like, as in general, also, like we all love keywords, like if you're also seeing like in this light, I'm using more of a, like my keyboards navigations to go between the screens rather than like, rather than all the like the mouse and the trackpad. Right. So it's like good to have keyboard accessibility in your application in the space.

So, and like, there's them and HTML for the wind here itself, because I'm using like, in this small demo, I am using a log-in form in here. I am showing that once I tab, I'm like using, I'm like not using any mouse and just like simply tabbing over elements and I am able to go to every right set of my HTML in the right order. So there's semantic HTML for the web. So all the like browser gives you a default focus. Like, I think as we just saw in this green, 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 tiles more better. There can also be a case where like you have an input form and you want to, uh, focus by default, like specifically one input feed whenever a form loads, because that's a better experience. So in that case, uh, although this snippet is like more focused towards the react, but you can use that in JavaScript itself, so like using this use effect hook that you have in react, you can, uh, use a ref of that particular input and using that reference. You can focus it at the time, the space notes.

Now coming up to the inputs and the labels, uh, it's always a good practice to use labels and, uh, 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. You'll ask me that, Hey, there's not every time that I will need to live 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 dog. So I have this class called visually hidden, which I'm using to hide my label. But my label is actually there in the top. It's rendered because screen readers are still going to see what's rendered on the top 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 a like, this 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. Right. So coming up to this, uh, 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 and anchor tag. And that and clicking on that anchor will directly skip our tabbing experience to just go to the main content. So that will be like another user experience for those people who are just like keyboards.

Coming to accessible SVGs, uh, 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 give, it gives users like a meaningful picture of what, 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, we usually like usually skip this, but it's a very important thing. So once we have insight as far as 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 the document titles because our screen leaders are also going to read it. So like, let's say again in React, you can use the competent amount. Or like we can also use hooks to change the document title. Every time you like change the stains or like every time you think that you are going from one page to another page. So that's a better user experience.

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 all like again, like accessibility is like a, 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 it to the time. Uh, there's like actual 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 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, it does not have any similarity 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 like 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 typing in this form.

So, all right, let me just start this recording. App web content heading level one. Login forum. You HTTPS colon slash slash www.mindinventory.com slash blog slash WP dash content slash uploads slash 2019 slash 0 6 slash reactjs dash benefits.jpg image and the edit text, one password and secure edit text visited link. Learn more. Chrome has new window visited link. Contact us. You are currently on a link inside web content. Voiceover. App web content heading level. All right. Uh, it's minimize this. So yeah, although I think yeah, so basically now you would see like the image name is like being pronounced up to like its length and, uh, 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 entering, react, good daily demo web content visited link. Skip to main content visited link. Skip to main content. Chrome main. Login for a banner image. Image enter username and the require edit text, enter password. And the require secure edit text, submit button. Visited link. Learn more. List two items visited link. Contact us heading level one.

Login for main. Login for banner image image. Enter. 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 liked the 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 accessibility practices that you've been doing, but also it also gives you a fix up to that. So, and it's also very descriptive, so I really love this. So what advice like anyone who is trusted to use it.

All right. So with this, we would want to end our discussion. And there are just like some links that are added, which are related to the both 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 more knowledge around like some other things that 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 that React and also like accessibility. So if you would want to come and 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.