Creating an Accessible Web Together in 5 Simple Steps

This ad is not shown to multipass and full ticket holders
JSNation US
JSNation US 2025
November 17 - 20, 2025
New York, US & Online
See JS stars in the US biggest planetarium
Learn More
In partnership with Focus Reactive
Upcoming event
JSNation US 2025
JSNation US 2025
November 17 - 20, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

Accessibility is often left as an afterthought in the software development cycle. However, with 5 simple techniques, we can build accessibility in our apps from the get-go. In this talk, I will talk about how to test for accessibility, aria tags you need to know, and how to use them. We will see a walkthrough of how jarring a non-accessible app can be for users, and how to fix it. We will also look at how Slack has built an accessible app while going above and beyond.

This talk has been presented at React Advanced 2022, check out the latest edition of this React Conference.

FAQ

Accessibility is crucial in web development as it ensures that everyone, including people with disabilities using assistive technologies, can use websites effectively. It enhances user experience for all users and is a legal requirement in many jurisdictions.

Common assistive technologies include screen readers, screen magnifiers, keyboards, selection switches, and head trackers. These tools help users with disabilities navigate and interact with web content.

WCAG 2.1 AA compliance refers to a set of guidelines that ensure web content is accessible. It covers principles like being perceivable, operable, understandable, and robust, which means content should be accessible via various assistive technologies and understandable to users with disabilities.

Semantic HTML uses elements for their given purpose, improving accessibility by providing built-in roles and behaviors. Using appropriate tags like <button> for actions enhances the experience for screen readers and supports keyboard navigation out of the box.

STARK stands for Semantic HTML, Tabindex, ARIA tags, Role, and Keyboard navigation. It is a mnemonic to help developers remember key elements to consider when building accessible websites.

Testing with real users is crucial as it provides feedback on the usability of a web application from the perspective of people with disabilities. This helps identify issues that automated tools might miss, ensuring the app is truly accessible.

Tools like Axe, WAVE, and built-in browser accessibility checkers can automate the process of identifying accessibility issues. These tools can highlight problems such as missing alt attributes or poor contrast, which can then be addressed before deployment.

Making web applications accessible is not only a best practice but often a legal requirement to prevent discrimination against people with disabilities. For example, the UK's Equality Act 2010 mandates that websites must meet certain accessibility standards like WCAG 2.1 AA.

Shruti Kapoor
Shruti Kapoor
31 min
21 Oct, 2022

Comments

Sign in or register to post your comment.
Video Summary and Transcription
The Talk covers the importance of accessibility in web development and provides practical tips for building accessible web applications. It discusses the basic principles of accessibility, WCAG guidelines, and the use of assistive technologies. The Talk emphasizes the use of semantic HTML, tab index, ARIA attributes, and keyboard navigation for app accessibility. It also highlights the importance of testing and debugging for accessibility issues and recommends the use of accessibility tools. Overall, the Talk aims to raise awareness about accessibility and provide developers with the knowledge and tools to create inclusive web applications.

1. Introduction to Accessibility in Web Development

Short description:

Hello, everyone. Thank you for coming to my talk. We all care about building performant web applications and creating an amazing user experience. Accessibility is often left as an afterthought in software development. I will talk about five simple things to keep in mind while developing to avoid shipping an inaccessible app. Building accessible web apps is a big undertaking. I'll continue to share my learnings on accessibility through blog posts and social media.

Hello, everyone. Thank you for coming to my talk. And staying here, actually. So we all actually care a lot about building performant web applications and creating an amazing user experience. We put a lot of effort in making fast websites. But what use is a fast website if people can't use it? Accessibility is often left as an after thought in a software development cycle. When it is time to ship, we actually do a quick accessibility test and find out that our app is not accessible and put some hacky code in and make sure that it's accessible enough. And then ship it. And sometimes it kind of ends up looking like this.

We make sure that it's visually pleasing and aesthetic, but the experience itself looks pretty hacky. In my talk, I will talk about five simple things that you can keep in mind while you're doing development so that you can avoid a situation like this. My name is Shruti Kapoor. I am a lead member of technical staff at Slack. And over the last few months, I've been working on building accessible user experiences in I would be lying if I said I was an expert at accessibility. Don't ask me any hard questions. When I built my personal site, I made it look visually pleasing, it looked beautiful, I used Tailwind, everything looked great. And when I did an accessibility test, I found out that most of my site wasn't accessible and people weren't able to do the things that they wanted to do. Like for example, read the blogs. And so through the means of this talk, I want to share some tips and tricks I learned and some things I now keep in mind that you can do while developing your web application so that you don't end up in a situation where it's almost time to ship and your app is not accessible.

This is a long journey, actually. Building accessible web apps is a lot to take, and it's a big undertaking. My journey here is not done. Through this talk, I want to share some things. But this journey continues afterwards as well. I'll continue to share my learnings on accessibility through blog posts and if you're interested in following, then you can find it on anywhere on Twitter here. Or on my not accessible website for now. And if you've been following me on Twitter, you already know that I'm a big DevJoke fan. So you know what's coming up. I'm gonna ask you a DevJoke question and you can just yell the answer out loud. Did the process say after working in an infinite loop all day? I need a break.

2. Introduction to Web Accessibility

Short description:

Today, we'll discuss the basic principle of accessibility, guidelines, testing, debugging, automation tools, and a web app that prioritizes accessibility. Accessibility ensures everyone can use a website easily, benefiting all users. Examples of accessibility include using a keyboard when a trackpad fails and closed captions for watching videos. Assistive technologies like screen readers and magnifiers help users with disabilities access websites.

You're right. Yes. Okay. Because we're short on time, I'll only do one DevJoke, but if you want more DevJokes, you can find them on Twitter. So here's what we're gonna talk about today. We'll look at the basic principle of accessibility and the guidelines of accessibility. We'll look at how to test if your current app is accessible and we'll have a checklist of things. We'll debug a web app and find out what the problems are and where you can look for solutions. And then we'll look at some tools that can automate this work for you, so you don't have to do it all manually. Finally, we'll look at a web app that has taken accessibility seriously and goes above and beyond.

So first, let's talk about accessibility. By the way, all the slides are available already online, and if you're interested, here is a QR code. I've also tweeted the link out right now, and you can find it on Twitter if you're interested. Everybody has the QR code and moving on.

So what is accessibility? Now I want you to take a minute to think about the last website you built or one of your favorite websites. Are you confident that anyone in the world can use that website? Are you confident that people who have limitations or are using assistive technologies can use that website the same way an able-bodied person can? Are you confident that all parts of your website are easily accessible? Accessibility is enabling everyone to use your site and to perform the critical actions easily. And accessibility benefits everybody.

You may have seen examples of accessibility in your life. For example, when you're coding and your trackpad dies and you need to connect or you need to log in. So, you just use keyboard to access the login screen. We've also seen accessibility features benefiting us in real life as well. For example, when you have a lot of suitcases in hand and go up a flight of stairs and there's no ramp. Or when you need to open the door and you have your both your hands are full. Or in the night when you need to watch YouTube and your partner is sleeping so you turn on closed captions. So, accessibility benefits everybody, not just those with limitations. But building accessible experiences provides a great experience for everybody who's using them. What does accessibility look like in digital or in web? In the web, when a person is using the web, they may use different assistive technologies to browse through your website. For example, somebody may be using a screen reader to read out the text on your site. And they may be using screen magnifiers to zoom your screen to even 20 times to see the screen itself. People who have motor disabilities may be using different technologies.

3. Assistive Technologies and WCAG Guidelines

Short description:

To make sure we are building for everybody, we need to consider the different assistive technologies people are using. According to World Health Organization, 15% of the population has some sort of disability. It's a legal requirement for a web app to be accessible. The WCAG 2.1 AA guidelines specify that websites should be perceivable, operable, understandable, and robust. Perceivable means the content should be understood by assistive technologies. Operable means websites should be operable by other assistive technologies, like screen readers and keyboards. Understandable means the text should be understandable by screen readers. Robust means assistive technologies should be able to parse your code.

For example, keyboard or selection switches. Or maybe using a head tracker to find out where the cursor or to point the cursor on the page itself. So, in order to make sure we are building for everybody in mind, we need to consider the different assistive technologies people are using.

You can actually access most of these technologies on your Mac itself by browsing to the accessibility shortcuts menu in Mac. There are more people using these accessibility tools than you think. According to World Health Organization, 15% of the population has some sort of disability and may need to use an assistive technology. In the U.S., 1 in 4 U.S. citizens has a disability. And it's not just a feature. It's also a legal requirement for a web app to be accessible. In the U.K., according to Equality Act 2010, your website needs to be the WCAG 2.1 AA accessible. So let's look at what that means.

This actually specifies guidelines that your website needs to be perceivable, operable, understandable, and robust. What does perceivable mean? It means that the content presented on the screen should be understood by people who are using assistive technologies. An example of this could be you have images on the page and you need to provide all text for it. Or if you have video on the page or audio on the page, you need to provide closed captioning so people can read them. This is also the principle that specifies that color should not be the only way of displaying information.

The next is operable, which basically means that websites should be able to be operated by not just mouse but by other assistive technologies as well, for example, a screen reader. For example, a keyboard. It specifies that keyboard focus should not get trapped and the user should always have understanding of where the keyboard focus is as on the web app. The next one is understandable, which basically means that the text presented on the screen should be understandable by screen readers. And it ensures that people who are using assistive technologies can use the learnings that they have from one website to navigate to your website. For example, you may have seen skip to main content on most websites. So people who are using assistive technologies have muscle memory built in because they've been using their technologies for a while. And if you move the skip to main content from that part to some other part, it becomes very hard for people to understand where that is and access it. So this principle basically guidelines that things like this should be on the same part of the website. And finally, robust, which basically means that assistive technologies should be able to parse your code. And this is why using semantic HTML is very important. And your code should work in every browser. There are different types of accessibility needs we have to keep in mind.

4. App Accessibility and Semantic HTML

Short description:

A few examples of disabilities include motor disability, cognitive disability, and auditory disability. To ensure app accessibility, remember the acronym STARK: semantic HTML, tab index, ARIA tags, role, keyboard navigation, and screen reader. Use semantic HTML elements like buttons instead of divs for actions. Ensure anchor tags have href attributes and images have alt tags. Avoid using font formatting for headings. Semantic HTML provides free accessibility features like keyboard navigation and select functionality.

A few of them are motor disability, which is when a person has problem with which is when a person has limitation of muscular control and inability to use maybe a mouse or a trackpad and they may have slow response time. Cognitive is when a person has learning disability or may have ADHD and it may be hard for them to remember large amounts of information on the screen. And auditory includes things like deafness or hard of hearing.

So that's accessibility 101 and now how can we make sure that our app is accessible? So while learning how to make things accessible, I came up with, like, five main things that we can keep in mind and they are as follows. Aria tags, role, finally keyboard navigation and screen reader. And to make that easier for us to remember, just think of stark. Or this guy. Or if you're a Game of Thrones fan, still, these guys. So again, stark is semantic HTML, tab index, aria tags, role, keyboard navigation, and screen reader.

So let's talk about the first one, which is semantic HTML. I think we all know what semantic HTML is, so I'm going to jump to the tips, which is a big tip that everybody says is use buttons for actions instead of adding it to div. So basically instead of adding like an onclick handler to a div, you should be using the semantic HTML version of it, which is button. And whenever you have an anchor tag, make sure it has an href. Whenever you use images, make sure it has all tags. And don't use CSS or font formatting only to use headings. And as much as possible, use the native semantic HTML elements to show content on your screen. But let's take a minute to think about what is the problem if you use div instead of a button. The problem is that when a screen reader encounters div and it has an onclick handler, the screen reader doesn't understand that it should operate like a button. So if it encounters a div with an onclick handler or just a div, it will announce it as roll or it will announce it as group. So the person using the screen reader has no idea that I need to be clicking on it. So it could happen that they would completely overlook your button and go past that page. So that's why you need to have button instead of div onclicks.

Now what's the problem with not using correct heading tags and just adding formatting? The problem is that when a screen reader encounters a heading, it actually announces heading in the text. But if you just use font formatting, the user has no idea that this is a heading and needs to be paid attention to. Another great thing about using semantic HTML is that you get free accessibility out of the box. For example, things like, let's say you're using select, you can use space bar to select an item. Or if you have a button, you can use the enter key to select or to click on the button. So you don't have to actually build these things. You don't have to make accessibility you don't have to make them accessible. These are already given to you out of the box.

5. Slider Usage and Tab Index in Web Accessibility

Short description:

Another great example is using a slider. You can use the space keys to move the slider around. Use semantic HTML. Tab index is used to set focus on certain elements on the page, allowing for keyboard navigation. A quick tip is to use zero for elements to be focused by default and minus one for programmatically focusing an element with JavaScript. Avoid using a tab index greater than zero, as it confuses screen readers.

Another great example is using a slider. You can use the space keys to move the slider around.

So in summary, use semantic HTML. All right. The next is tab index. So if you're not familiar with tab index, tab index is actually used to set focus on certain elements on the page. So you can tell keyboard navigation... You can basically specify where keyboard should be navigating to or where it should be setting focus to. There's a really cool tool in Firefox that can help to find out or debug tab index, and I'll show that in a minute. It looks kind of like this. So you see the little black icons zoomed in here. It tells you what the tab order of each element is, if it's interactive and focusable. A quick tip about tab index is to either use zero, which is for elements that you want to be focused by default, like divs if they need to be focused. Or minus one if you want to programmatically focus an element and target it with JavaScript. The minus one gets skipped when you are using it by default, but you can use it with JavaScript to focus on it programmatically. An important thing to remember in mind is to not use a tab index greater than zero, because it confuses screen readers.

6. ARIA Attributes and Assistive Technologies

Short description:

ARIA attributes give extra information to assistive technologies to make them understand what's going on on the page. For example, when you click on a toggle button and you have the ARIA check set to on, it can help announce things. So let's say you have a mic, and you set the ARIA check to true, it can announce the state of that mic.

The next one is ARIA, and these are ARIA attributes. There's a bunch of them, and I only listed a few of them, which I've been using very commonly. ARIA attributes actually give extra information to assistive technologies to make them understand what's going on on the page. For example, when you click on a toggle button and you have the ARIA check set to on, it can help announce things. So let's say you have a mic, and you set the ARIA check to true, it can announce the state of that mic. So you can say mic on or mic off. And it helps screen readers.

7. Roles, Keyboard Navigation, and Tools

Short description:

If you can use a native HTML element, use that instead of using a role. Button gives you free accessibility. Test your site with keyboard navigation. Unplug your mouse or trackpad and see if you can access every part of your app through keyboard navigation. Remember Starrk: semantic HTML, tabindex, roles, and keyboard navigation. Provide audio attribute, audio role, and explicit labels for interactive elements. Use alt attribute for relevant images. Use role=presentation to skip non-pronounced images. Tag multimedia and provide closed captioning. Ensure sufficient color contrast. Run automation tests to catch any missed issues.

R stands for role. There's lots of roles out there. But be careful, though. If you can use a native HTML element, use that instead of using a role. The problem of role is that you have to build accessibility on top of it. So if you're using a div and adding a role, you're not using button. Button gives you free accessibility. So use native elements as much as possible, instead of slapping a role on top of it.

And finally, keyboard navigation and screen reader. So test your site with keyboard navigation. Keyboard navigation basically means using your keyboard only to navigate your site, instead of using the trackpad or the mouse. So a quick tip is to unplug your mouse or trackpad and see if you can access every part of your app through keyboard navigation. And check if your focus outline also stays visible and you know where you are on your webpage.

So if you want to remember those acronyms, again, remember Starrk. And here's a quick checklist of things you can do before you release your app. So remember Starrk, semantic HTML, tabindex, roles, and keyboard navigation. Make sure that there are no keyboard traps and your focus stays visible on your site. For anything that is an interactive element, provide an audio attribute, an audio role, and provide explicit labels on what that element is. For example, a video. All relevant images should be using alt attribute. If you have an image that you do not want to be pronounced, for example, it's a tick icon or it's just a presentation element, you can use the role equals presentation to skip that. And make sure that all your multimedia is tagged. You have closed captioning available for anything that is auditory. Text has sufficient color contrast. And make sure you run automation tests so you can catch anything that you may have skipped.

All right. So now let's look at a few tools that are available. There's a bunch of tools that are available out there. They can do most of this stuff for you and provide a list of errors that your app may be having. There's browser extension.

8. Accessibility Tools and Demo

Short description:

Axe and wave are popular accessibility tools. Use keyboard navigation, screen reader, and automation tools to ensure accessibility. Test your app with real users for a complete assessment. Now let's look at a demo of an inaccessible site and try to debug it.

Axe and wave are popular ones. There's a lot of accessibility tools built into the browsers itself. Firefox and Chrome. We'll demo that in a bit. There's also build tools that you can use within your code itself. And then finally there's CI tools that can help you show errors when you have published your code.

So, before you release your feature or before you finish, before you create your PR, make sure you test accessibility. Use keyboard navigation to make sure that your content is accessible. Remember Stark. And check your app. Make sure it's keyboard navigable. Use screen reader and use the automation tools to find out errors that you may have skipped. And finally, make sure that you're testing your app with real users. Code cannot catch as many errors. Code may even tell you that your app is 100% okay, but if a user cannot understand your app still, it's no point. So, make sure you do user testing with real users.

All right. So, now we're gonna look at a quick demo of a site that is not so accessible and find out the problems that it has and see if we can debug it. Going to mirror my screen. Perfect. Okay. So, I put myself on the spot. I built a site and if you look at it right now, it looks visually okay. My design skills are okay. If you hover on an item, you can see that you can kind of tell what item should be hovered. When you click on it, it will open as well. There are some links and there are some videos at the bottom. Now let's see what a person using an assistive technology would be seeing. So, I'm going to turn voiceover on. And I apologize for the noise.

9. Screen Reader Focus and Accessibility Tree

Short description:

Video playing. Watch for what the screen reader focuses on and what it's skipping. It's focusing on read blogs and browse more talks, but it totally skipped a section. Let's investigate. Closing voiceover, I'll open accessibility properties in Chrome and Firefox. The accessibility tree helps screen readers understand the page. It shows focusable elements and what's being focused next. Firefox has an even better accessibility feature.

Video playing. So watch for what things the screen reader focuses on and what things it's skipping. So it's focusing on read blogs and you can kind of see the outline as well. It's at the top of my blog post. That's cool. And the next thing it focuses is browse more talks. So it actually totally skipped that section. So let's see what's going on. And this is a really bad experience for somebody who is using screen reader because they did not see any blog post I wrote. So I'm going to close voiceover and see what's going on.

Okay. So I've got Chrome open here and I also have Firefox open here because I want to show you both the tools. So what I'm going to do is open accessibility properties in Firefox and open accessibility properties in Chrome. So you can find them here. Make sure it's zoomed in. Okay. The first thing we'll look at is the accessibility tree. And this is the tree that a screen reader would be using to understand what's going on in the page. And you can find that right here. Enable full page accessibility tree in Chrome. So when you click that, it gives you a pop up to reload dev tools. We'll do that. Okay. I reloaded, and you see the little man here, and that's how you can access the accessibility tree. This looks a little different than the DOM tree, but basically the idea here is like it'll tell you all the things that a screen reader would be seeing. So you may be able to see things like focusable true. So that means I can see this and I can focus on it. And then things over here that are next being focused. We'll get back to this in a bit.

So in Firefox, this is actually even better.

10. Debugging Keyboard Issues in Firefox

Short description:

In Firefox, I found keyboard issues while testing. The problem is that interactive elements must be focusable. Adding a tab index to a div is not correct since div is not an interactive element. Instead, find the next interactive element, which in this case is an anchor tag. However, the anchor tag is missing the href attribute.

In Firefox, it has these issues� it has this testing thing already built in. So what I can do is I can click on check for issues. And I found out that I was having keyboard issues. I'm going to click on keyboard. And now I see that it is giving me a few errors here. Let me see if I can zoom that in. Put that down. So you see all of these are problems that my content is currently having. I'm trying to debug this one. So I'm gonna open this one and see what's going on.

So I see that there's a keyboard issue here. Let's see what's the problem. It says interactive elements must be focusable. And to understand what that means, I'm gonna open this link. But basically, it says that you need to have a tab index on your content. Part of stock. Okay. So to do that, let's see what my content even looks like. So I'm gonna inspect this. So if you see here, this is my box. I see that there's a div here. Now, our suggestion was to add a tab index. So you may be tempted to add tab index to this box itself. But remember, tab index should only be added to interactive elements. The problem with adding a tab index to div is that div is actually not an interactive element. An interactive element is either a button or a link. So instead of adding a tab index to div, go down the tree and see what is our next interactive element.

So if I look at the tree, it's an anchor tag here. Now, let's see what the problem is. So I've got a class here, but I don't have any href.

11. Debugging Keyboard Issues and Tabbing Order

Short description:

With the help of the accessibility tree and a quick test, I can identify and fix problems. The tabbing order feature is useful for debugging incorrect tabbing. Use browser accessibility tools to debug web apps. Ensure outlines are always visible during keyboard navigation. Some apps make web apps accessible by adding tab index everywhere.

And so that's the problem. So with the help of this accessibility tree and a quick test, I can find out what the problem is. If I add href here, it will be able to tab onto it. No problem. All right.

There is another really cool thing here, which I want to show you. And that is a tabbing order, if I can find it. There. So it has a tabbing order here. And it takes a while to actually load up. And basically what it does is it will show me which element is being tabbed onto in what sequence. So it puts like a 1, 2, and like 4, 5 here, based on what the tabbing order of each element is. And so that's super handy in debugging whenever you want to do whenever you want to debug, suppose your element is not being tabbed onto correctly. So that's tabbing order. Let me make sure I've taken all of these. Cool. OK. So that's how you can find problems with your web apps and see, use the browser accessibility tools to debug them.

Now I'm going to switch back. And let's see. Ah, shoot. The other one. OK. Going back to the presentation. And play. Sweet! OK. So, some things that we looked at was fixing broken anchor tags. One thing that I don't know if you noticed was that when we were focusing, our outlines were visible because of the screen reader. So that's something that we need to make sure when we are using keyboard navigation that our outlines are always visible. Now there are apps that have gone to making the web app accessible by just adding tab index everywhere.

12. Keyboard Shortcuts and Section Focus

Short description:

But you can do more than that. You can provide keyboard shortcuts for commonly used actions. I'll show you an app that goes above and beyond in ensuring accessibility. It offers keyboard navigation, section-specific focus, and shortcuts for common tasks like editing messages.

But you can do a little bit better than that. There are a few apps that provide skip to main content and that's a great first step. But you can do more than that. You can provide keyboard shortcuts for things that are commonly used by a user. And now I'm going to show you an application that has gone above and beyond in ensuring an accessible user experience.

Okay. So let me play this video. Doesn't work very well. Okay. Okay. I am going to go back to main screens. OK. So if you look at this video, I am going to use keyboard navigation to actually tap through all of these items, and you'll notice that it detects that I am using keyboard, and it shows me a pop-up saying if you're using keyboard, then these are some shortcuts available. And that was really cool. I was very amazed to see this. So basically what it's telling me is that you can use this command key or command shortcut to actually focus in a certain section. We're going to look at how that works.

So basically what it does is when I use command control left arrow or right arrow to move focus between sections, it'll stick the focus in that section itself. So right now I'm going to use command control focus, and you see now it's in the left section, and now if I keep tabbing, it won't go to the messages section. It'll just keep the focus in that section. And that helps people who have problems focusing on a certain section, especially if there's a lot of content on the page. And you can think of Slack as an app where there's tons of messages, so maybe when you keep tabbing on to a message, it may be very hard to navigate to that message. So things like these shortcuts actually help people a lot in ensuring that the focus stays a certain area, instead of having to tab over every single interactive element on the page. And so now I can use my keyboard arrow keys to just stay in that one focused section. I can also use more than just tab keys, and I can use arrow keys to go between other sections of the app. So, for example, like in Slack, one of the biggest things is writing a message. So you'll write a message, and now let's say that I made a mistake and I want to edit it. So now you can use your shortcut key, which is the E key in Slack, to go up a message and edit it. So that's how an app has been thinking about accessibility seriously and not just using tab keys to actually make everything tab-able, but also thinking about the most common things a user may be doing and making that experience better for a user. All right.

13. Overview of Accessibility and Key Considerations

Short description:

In this talk, we discussed the guidelines and principles of accessibility, as well as different types of disabilities. We explored Stark, semantic HTML, tab index, attributes, roles, and navigation. These are important considerations for building accessible web applications to avoid the need for extensive refactoring. I will share more information through blog posts in the future.

So because this is getting harder, I'm just going to present from here. Cool. Okay. So in the talk today, we looked at the guidelines of accessibility, principles of accessibility, the different types of disabilities people may have. We talked about Stark, semantic HTML, tab index, attributes, roles, and K for... Navigation! These are some simple things to keep in mind to build your next web application. So that once you're done, you don't have to go back and refactor and spend a lot of time undoing the work you did and redoing all of that work. So I hope this gave you a good indication of things that you can keep in mind. And if you're interested in following the journey forward, I'll be sending a blog post of everything I talked about today and everything in the future. And if you want, you can sign it up here.

14. Final Joke, Alt Attributes, Testing, and Pitching

Short description:

We can't leave without one final dev joke. Is there such thing as too much information with alt attributes or ARIA labels? It's a common mistake to add a role to semantic HTML like buttons. Both component-level and end-to-end testing are important for accessibility. Pitch accessible implementation to stakeholders by emphasizing the legal requirement and the cost of refactoring later.

We can't leave before one final dev joke. Who won the debate for the best wearable? Say that again? I won! Thank you so much, everybody. You've been great. Thank you so much, Rudy. Would you like to take a seat? I promise not to hold you too long or ask too difficult questions, mainly because we're a little bit over time and people want their coffee.

But let's do the top-rated question here, which I think is a really good question and I don't know the answer to this. With alt attributes or ARIA labels, is there such thing as too much information? How do you decide what to actually put in? That's a great question. So I think one of the things and one of the most common mistakes people may make is especially if you're using semantic HTML like buttons, you may add a role to it. You could do that. Technically, it's not breaking anything, but it's just useless work to do. You don't need to do that if you're using semantic HTML, so. Yeah.

Great, that was so quick, let's do another one. There are many accessibility testing tools available. In your opinion, what's the best phase to test your code? Is it on the component level or is it on the end-to-end when it comes to accessibility? Oh, great question. I think both of them are really important, but at the end of the day, I think once your code lands in the hands of the users, it's very important to do accessibility testing there. You can make sure you have semantic HTML, your code looks great. But if it's not usable for the user and they can't access the information, I think it's worth for nothing. That's very true. And in my personal practice, I only do end-to-end testing for accessibility because I usually accessible component libraries that do their own testing on the primitive level. Pro tip. Use Radix.

All right. And then final question. How would we pitch accessible implementation to stakeholders? Is there some sort of argumentation that tends to work well? Oh, great question again. One thing that you can tell them that it's a legal requirement, so if they don't take care of it, they're going to have to pay for it, heavily. Another thing to remember is that, I don't know, if you have a use case experience from your own experience, if you have a use case from your own experience, but in my experience I've noticed that we build web applications and then finally we realize that it's not accessible, we go back and refactor the entire component. And that happened to me as well, and it wasted like a month of my time, so it's better to start accessibility from the get-go and design level itself instead of coming back to it and refactoring it. Wise words. And that's all we have time for. Thank you so much, Ruti, for your talk and the jokes. Thank you so much. I hope to hear some more later.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

A Guide to React Rendering Behavior
React Advanced 2022React Advanced 2022
25 min
A Guide to React Rendering Behavior
Top Content
This transcription provides a brief guide to React rendering behavior. It explains the process of rendering, comparing new and old elements, and the importance of pure rendering without side effects. It also covers topics such as batching and double rendering, optimizing rendering and using context and Redux in React. Overall, it offers valuable insights for developers looking to understand and optimize React rendering.
Building Better Websites with Remix
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Top Content
Remix is a web framework built on React Router that focuses on web fundamentals, accessibility, performance, and flexibility. It delivers real HTML and SEO benefits, and allows for automatic updating of meta tags and styles. It provides features like login functionality, session management, and error handling. Remix is a server-rendered framework that can enhance sites with JavaScript but doesn't require it for basic functionality. It aims to create quality HTML-driven documents and is flexible for use with different web technologies and stacks.
React Compiler - Understanding Idiomatic React (React Forget)
React Advanced 2023React Advanced 2023
33 min
React Compiler - Understanding Idiomatic React (React Forget)
Top Content
Watch video: React Compiler - Understanding Idiomatic React (React Forget)
Joe Savona
Mofei Zhang
2 authors
The Talk discusses React Forget, a compiler built at Meta that aims to optimize client-side React development. It explores the use of memoization to improve performance and the vision of Forget to automatically determine dependencies at build time. Forget is named with an F-word pun and has the potential to optimize server builds and enable dead code elimination. The team plans to make Forget open-source and is focused on ensuring its quality before release.
Using useEffect Effectively
React Advanced 2022React Advanced 2022
30 min
Using useEffect Effectively
Top Content
Today's Talk explores the use of the useEffect hook in React development, covering topics such as fetching data, handling race conditions and cleanup, and optimizing performance. It also discusses the correct use of useEffect in React 18, the distinction between Activity Effects and Action Effects, and the potential misuse of useEffect. The Talk highlights the benefits of using useQuery or SWR for data fetching, the problems with using useEffect for initializing global singletons, and the use of state machines for handling effects. The speaker also recommends exploring the beta React docs and using tools like the stately.ai editor for visualizing state machines.
Routing in React 18 and Beyond
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Top Content
Routing in React 18 brings a native app-like user experience and allows applications to transition between different environments. React Router and Next.js have different approaches to routing, with React Router using component-based routing and Next.js using file system-based routing. React server components provide the primitives to address the disadvantages of multipage applications while maintaining the same user experience. Improving navigation and routing in React involves including loading UI, pre-rendering parts of the screen, and using server components for more performant experiences. Next.js and Remix are moving towards a converging solution by combining component-based routing with file system routing.
React Concurrency, Explained
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
Top Content
Watch video: React Concurrency, Explained
React 18's concurrent rendering, specifically the useTransition hook, optimizes app performance by allowing non-urgent updates to be processed without freezing the UI. However, there are drawbacks such as longer processing time for non-urgent updates and increased CPU usage. The useTransition hook works similarly to throttling or bouncing, making it useful for addressing performance issues caused by multiple small components. Libraries like React Query may require the use of alternative APIs to handle urgent and non-urgent updates effectively.

Workshops on related topic

React Performance Debugging Masterclass
React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Top Content
Featured Workshop
Ivan Akulov
Ivan Akulov
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
Next.js for React.js Developers
React Day Berlin 2023React Day Berlin 2023
157 min
Next.js for React.js Developers
Top Content
Featured WorkshopFree
Adrian Hajdin
Adrian Hajdin
In this advanced Next.js workshop, we will delve into key concepts and techniques that empower React.js developers to harness the full potential of Next.js. We will explore advanced topics and hands-on practices, equipping you with the skills needed to build high-performance web applications and make informed architectural decisions.
By the end of this workshop, you will be able to:1. Understand the benefits of React Server Components and their role in building interactive, server-rendered React applications.2. Differentiate between Edge and Node.js runtime in Next.js and know when to use each based on your project's requirements.3. Explore advanced Server-Side Rendering (SSR) techniques, including streaming, parallel vs. sequential fetching, and data synchronization.4. Implement caching strategies for enhanced performance and reduced server load in Next.js applications.5. Utilize React Actions to handle complex server mutation.6. Optimize your Next.js applications for SEO, social sharing, and overall performance to improve discoverability and user engagement.
Concurrent Rendering Adventures in React 18
React Advanced 2021React Advanced 2021
132 min
Concurrent Rendering Adventures in React 18
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
With the release of React 18 we finally get the long awaited concurrent rendering. But how is that going to affect your application? What are the benefits of concurrent rendering in React? What do you need to do to switch to concurrent rendering when you upgrade to React 18? And what if you don’t want or can’t use concurrent rendering yet?

There are some behavior changes you need to be aware of! In this workshop we will cover all of those subjects and more.

Join me with your laptop in this interactive workshop. You will see how easy it is to switch to concurrent rendering in your React application. You will learn all about concurrent rendering, SuspenseList, the startTransition API and more.
React Hooks Tips Only the Pros Know
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
Introducing FlashList: Let's build a performant React Native list all together
React Advanced 2022React Advanced 2022
81 min
Introducing FlashList: Let's build a performant React Native list all together
Top Content
Featured Workshop
David Cortés Fulla
Marek Fořt
Talha Naqvi
3 authors
In this workshop you’ll learn why we created FlashList at Shopify and how you can use it in your code today. We will show you how to take a list that is not performant in FlatList and make it performant using FlashList with minimum effort. We will use tools like Flipper, our own benchmarking code, and teach you how the FlashList API can cover more complex use cases and still keep a top-notch performance.You will know:- Quick presentation about what FlashList, why we built, etc.- Migrating from FlatList to FlashList- Teaching how to write a performant list- Utilizing the tools provided by FlashList library (mainly the useBenchmark hook)- Using the Flipper plugins (flame graph, our lists profiler, UI & JS FPS profiler, etc.)- Optimizing performance of FlashList by using more advanced props like `getType`- 5-6 sample tasks where we’ll uncover and fix issues together- Q&A with Shopify team
React, TypeScript, and TDD
React Advanced 2021React Advanced 2021
174 min
React, TypeScript, and TDD
Top Content
Featured Workshop
Paul Everitt
Paul Everitt
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.