React Accessibility: Beyond the Basics

Rate this content
Bookmark

Accessibility in React has been a hot topic in the last few years, but in this talk, we'll be going beyond the basics. We'll discuss what disability means beyond what you've heard before, and then use code examples to learn why semantic HTML is helpful, and when it's just not enough. We'll then look into tooling, and talk about how you can introduce accessibility testing into your teams and existing code. You'll leave with the tools and knowledge to make a difference starting today.

Jen Luker
Jen Luker
32 min
17 Jun, 2021

Comments

Sign in or register to post your comment.

Video Summary and Transcription

Today's Talk on React Accessibility covers the importance of manual testing, the challenges faced in addressing accessibility, the impact of accessibility on user experience, and the use of subtitles and user settings for accessibility. It emphasizes the need for manual testing in addition to automated testing, the role of empathy training in understanding accessibility challenges, and the significance of addressing accessibility issues for all users. The Talk also highlights the benefits of implementing accessibility features, such as increasing website accessibility for disabled markets and improving user experience for all.

Available in Español

1. Introduction to React Accessibility

Short description:

Hello everyone. Today we're going to be going over React Accessibility Beyond the Basics. Jen Luker is a knitter, quilter, sci-fi nerd, accessibility advocate, and software engineer. She recommends watching Sophie's talk on accessibility as a first class citizen for an introduction. Chrome and Firefox have built-in tools for accessibility testing, including colorblind features and contrast comparisons. AXE Chrome and Firefox extension is an educational tool that provides descriptions of violations, highlights their locations, and suggests solutions. Manual testing is necessary to ensure the right things are easy and the wrong things are hard to do.

REACT JS ReactiveJS ReactJS TypeScript ReactJS ReactJS ReactJS Hello everyone. Today we're going to be going over React Accessibility Beyond the Basics.

Now to tell you a little bit about me, my name is Jen Luker. I am a knitter and a quilter, a sci-fi nerd, an accessibility advocate, and then I'm a software engineer. And I like to play with IOT devices. And as you can see from all of these photos, I am a lover of pretty dresses.

So, before we get too deeply into the advanced portions of accessibility, if you want more of an introduction, you should go watch Sophie's talk on accessibility as a first class citizen. She does a fantastic job of giving you that introduction.

So, one of the things that goes with accessibility are various web tools. Now Chrome has quite a few built-in tools that we used to be able to use plugins for, but we really don't need to. At this point, we have the dev tools that allow us to do things like emulate the, you know, colorblind features, or we can see the comparisons between different contrast colors. And it really gives us a great idea on how to modify those CSS rules that we need to.

Now Firefox also has their own, but it's a little bit more complicated to get to. You're going to need to modify your settings in order to get to these. And once you turn on that simulate dropdown, you're going to be able to do the same thing. Now, don't forget that when you do that, you are in fact going to need to close all of your Firefox windows and bring them back up. A refresh is not an up. So, make sure you do turn it off and turn it back on again.

I also really enjoy using the AXE Chrome and Firefox extension even though Chrome and Firefox have this built in. In fact, Chrome uses AXE for their Lighthouse extension which gives you not only an accessibility overview, but also an overview of your entire app. This, however, is more of an educational tool for me because it gives you not only your violations, but it also gives you a description of where it's located. It highlights it for you and gives you more of an idea of what the impact is. It also gives you a lot of different ideas regarding how you can solve this. No one problem has one solution. Therefore, understanding what the problem is in the first place is a very big deal. I love AXE because it gives you the opportunity to learn. It's not just telling you what's wrong, it's telling you why it's wrong and how to fix it. Fantastic tool.

Now, beyond doing manual testing using those tools, you want to make the right things easy and the wrong things hard to do. It can be difficult when the only way to handle accessibility features and accessibility problems is to manually test and manually fix.

2. The Importance of Manual Testing for Accessibility

Short description:

Taking care of low-hanging fruit using automated testing is helpful. Automated testing can prevent resentment and anger between team members. X is not just a web tool but also a CLI that can be integrated into existing test suites. However, automated testing is not enough to ensure full accessibility. Even with a 100% Lighthouse score, a website can still be inaccessible. Clicking through and manual testing are essential for accessibility. Axe tools can provide reminders but cannot replace manual testing. Accessibility goes beyond technological functionality to include readability for diverse users.

So, taking care of a lot of the low-hanging fruit using automated testing is helpful. Now, another reason for automated testing is because when you as a person go and tell your coworker something needs improvement, needs to be in a different format, they need alt tags or ARIA roles or even that their props are in the wrong order, it can build resentment and anger between the team. If your automated testing suite or your linter tells someone that these things are needed, they just fix it. So, if it is a hill you are willing to die on, write a lint rule. It will save everyone on the team a lot of strife and anger and frustration.

X goes beyond just being a web tool. It is also a CLI and you can implement it into your existing test suites. Now, testing tools, like React testing tools, has it built in, so you don't have to deal with trying to set this up on your own. But these are some examples of how you can use it in Selenium or Jest or Cypress or Express or a various list of formats. You can, in fact, set up all of these DevTools within your existing test suite without having to switch to something else.

But once we've integrated automated testing, where are we? Are we good? Absolutely not. And the problem most deeply is something like this. We have a website here that is 100% inaccessible. And this is a beautiful article that walks you through how they wanted to keep 100% accessibility score and how they started excluding people by removing various features or converting code. And when we get down to the bottom of this, and we run the very last test on CodePen, you'll see that your cursor disappears when you're on it. But when you're off, it's fine. Nothing is clickable. You can't tab to anything. You can't do anything with it. But it is, in fact, a valid website. It does give you information. You just can't see it at all. And this still gives you a 100% Lighthouse score. So just because you've used all of your automated tools, you've gotten all of your reminders that the functionality needs to be available within the code, it doesn't change the fact that this code is still not accessible. There's nothing at this point that is going to replace clicking through, looking at your website. Which ties us back again to the axe tools that can help you look at those things and give you reminders but isn't going to do it all for you. There's a lot that goes into accessibility. It's not just can I click on something? Can I see it? Can a screen reader see it? It's also as deep as can someone who's coming into this with English as a second language read it clearly? Or can someone who is autistic be able to understand what's going on? It's not just about the technological functionality. It's about the readability.

3. Testing and Component Development

Short description:

It's about the readability. It's about how people can use the website the way that they need to in order to reach their goals. Testing resources include checklists, such as the WebAIM checklist, which provides detailed explanations for each section. Code examples, like those found on the YARIA page, can help with component development. React accessibility and component libraries like Material UI, React Kit, and Reach UI provide accessible components. Remember that everyone is fighting JavaScript.

It's about the readability. It's about how people can use the website the way that they need to in order to reach the goals that they're trying to obtain. So what should you be testing when you're looking at a website? I'm going to give you a couple different resources. One of them is a list of checklists. These are beautiful because when you go to each one, you're going to notice that they have a list of what each one is, what you're looking for. So you can walk through this list and understand what it is you need to be testing.

Clearly identifying input errors or making sure that all elements are built for accessibility. But what does that mean? When you go to something like the WebAIM checklist, it has a similar option but does in fact give you a little bit more detail on what they mean for each section and you can in fact check them off. It gives you a lot more detail on how you may want to walk through that testing manually or even create automated tests.

Now even if you're trying to figure out your components when you're coding, it can be easier to have code examples and this is a difficult to find YARIA page, but it gives you references, like a dialog modal, what a modal code should look like and examples. It means that you can go here and start building your own components that include these features like what happens when you tab, what happens when you shift tab, what happens when you escape. These things are expected. So, you're not deviating from that expectation of functionality.

React accessibility is React's actual website, or not today, that walks you through the React specific formats and suggestions for how to keep their components accessible. Material UI, React Kit, Reach UI, they're all component libraries that are starting you out with accessible components. And you can take those and build upon them or compose them in order to make the websites that you're working with. It's a beautiful way of developing a website with components that have already been in existence, that have already been vetted and troubleshot that's also open source. And above all, just remember while you're working with all of these accessible features and inaccessible features that everyone you meet is, in fact, fighting JavaScript.

4. Addressing Accessibility Challenges

Short description:

Thank you for the accessibility talks. Manual testing can address issues not caught by automated testing. Use built-in tools in Chrome and Firefox to simulate color issues. For small hands and big screens, involve others or hire an auditor. Empathy training can provide insights into accessibility challenges.

Thank you. Hey there, how's it going? Pretty good, pretty good. It's dark and gloomy in Zurich, how is it in your place? Sunny. Looks so nice, oh my, oh my. Ah, that's a pretty room to be in, that's nice. Jen, I am so happy that we had not just one, but actually two accessibility talks at this conference, and that you went and ventured further than the introduction topic which I think a few people might already know, most people might not know that yet, but we'll figure that one out hopefully eventually and we don't have to get many people up to speed. But I really like that you went through a bunch of different things, and one thing that caught my attention, because I have fallen for this one very specifically myself, was if our automated testing does not catch everything and it never does, and you showed that very very beautifully, how can I manually testing spot things where I'm not affected, like certain colour issues where I'm not in the affected group or issues with accessing information or interacting with touch screens when the phones are large but my hands are small because I have pretty large hands, what would you do about these things that I can't spot manual testing? For things like colour contrast or colour blind issues, within both Chrome and Firefox they have built-in tools that allow you to simulate what those look like. That gives you a better idea of what kind of contrast issues you're running into or whether you're running into colour similarities that are too close for comfort. For small hands and big screens, some people ask their kids to try to do a particular task. Another really important option is to hire an auditor. Once you've handled the basic technological ability, at that point you bring people in that are trained and experienced in using the technologies. A lot of companies are into empathy training. They have you wear goggles that make you vision impaired, or they have gloves that make it more difficult for you to move. The problem with this is it makes things so much more harder for you than it would for someone who's familiar with the tools that they're working with. It's not your daily experience, so everything is awkward to you. Not just what is the expected flow, and whether the process that you have implemented falls within that expected flow. Hiring an auditor, having people that have those various disabilities tested out, is going to be a really important part of adding to that more manual testing side of accessibility.

5. Accessibility Testing and Dark Mode

Short description:

You mentioned a linter called JSX A11y plugin extension that checks alt tags and A11y issues. It is separate from Axe but can be found in linters like Airbnb. For individual component testing, check the web accessibility practices that provide code examples. Dark mode interfaces can introduce complications with accessibility, as different users have different color preferences. Manual testing is crucial to ensure proper visibility and contrast.

That sounds fantastic. You mentioned a linter as well that can catch a bunch of things. Choco is asking, what was that linter that you mentioned to check alt tags and A11y issues? It is built into quite a few of the tools that we already use. It is, I believe it's JSX A11y plugin extension. I'll go ahead and look for it. Is that part of Axe or is that separate from Axe?

That is separate from Axe, but you'll find it in a lot of linters that you're utilizing from like Airbnb or things like that. It's the eslint plugin JSX A11y that will catch a lot of the technological aspects of essentially accessibility while you're coding. And besides that linter and Lighthouse and Axe, as a developer, is there anything else that I can do to make sure and test my website and my components individually for accessibility? That's a question coming in from Paul.

When it comes to testing your individual components, I did add a link to my slideshow, and I will absolutely post that in the Discord. There's the web accessibility like practices that allows you to see not only the expected behaviors for each type of component, but they also provide code so you can see how that's implemented within the HTML element. It gives you a much better idea of what types of features you need to add to the JavaScript to make those interactive functionalities work. Right, awesome. And you're going to post the slide deck into Discord? That's pretty awesome as well because there was a question on if the slides are available somewhere too. Yes. Also, have you seen any complications when it comes to accessibility with the rise of dark mode interfaces so that you can switch between light and dark?

There's so many conflicting bits of information when it comes to accessibility. For instance, someone with ADHD needs bright, direct colors with very little distraction. Whereas someone with autism may need muted colors because the intense bright colors is too much. You have dark mode which means that your light colors need to be brighter and bolder and larger in order to stand out from that black background it tends to fade right in. Whereas on a light background blacks are really strong and bold by nature. So yeah you definitely see things disappear as soon as you transition to light and dark mode. It can be an interesting fight. The other thing is when things are over like background images and you switched from light to dark mode sometimes the colors switch to a color that you can't actually see. Like it'll go from a black text on a white background to a white text on a white background. So being aware of how those are being affected is definitely something you need to look out for. And again a lot of that comes down to manual testing. Switch to dark mode. See what happens. But would you say that if dark mode is implemented properly it can also actually solve some accessibility issues because it offers those who might need the tone down muted colors a little little more um comfort? Or... It may not be that the tone down muted colors is what you're going for. You can have black with really with white text and it'll still be a very high contrast.

6. Accessibility Challenges and Manager Support

Short description:

However, what I asked was what you do use, not what you should use. The most common thing I see is people using a div instead of a button. The first rule of ARIA is don't use ARIA. And another issue that I have been seeing is that it sometimes is it's great that we convince developers to do things right, and then they want to do that, but then they don't find backup in the manager or in the team that they work within or the entire organization they work within. I know that some countries are penalizing accessibility issues on websites, especially if they are like government websites and things like that. But outside of these countries, say in Germany, say in Switzerland, what would you say to a manager who's like but we don't need accessibility. It's fine, just skip it. If you had a bug in your purchasing flow that prevented a user from actually buying your product, you would be hot fixing that, like immediately. So why is it different when someone with an accessibility requirement can't purchase something? Why is that not a bug? That's a fair question.

Right? However someone with like photosensitivity issues like me, the dark backgrounds hurt less. It's not quite as bright in my eyes. The amount of brightness is left to small things like text as opposed to the entire bold white background. That makes that makes sense.

And also that brings me into something. Because I found it very interesting. I have not heard or thought as much about the different needs of the different groups as in colors and less contrast versus those who need higher contrast and more vibrant colors. What would you say are the worst offenders in terms of accessibility issues on websites that you see and what can we do to work against those? What are the most prevalent in practice? This might skew the poll.

However, what I asked was what you do use, not what you should use. And I see people use a div for everything. A div for containers, a div for buttons, a div for links, a div for literally everything. We have these landmarks like main and content and article and these various options that give context to screen readers or to the web platform as a whole that allows people to interact more fluidly. However, when we use a div for everything and we just add on clicks to stuff, it breaks that process. So the most common thing I see is people using a div instead of a button. There are times when you want to use a div instead of a button and that's when you try to include a div inside of a button and that's not allowed. Or you can, but it's not semantically correct. At that point then you want to start adding the button accessibility features. But it's extremely rare when you should be adding that. As they say, the first rule of ARIA is don't use ARIA. When there's a better alternative available. Yeah that's I think it's very rarely necessary to tread outside of what the browser offers you. And if you do you have to be very, very careful and most people unfortunately aren't. That's definitely a problem.

And another issue that I have been seeing is that it sometimes is it's great that we convince developers to do things right, and then they want to do that, but then they don't find backup in the manager or in the team that they work within or the entire organization they work within. I know that some countries are penalizing accessibility issues on websites, especially if they are like government websites and things like that. But outside of these countries, say in Germany, say in Switzerland, what would you say to a manager who's like but we don't need accessibility. It's fine, just skip it. If you had a bug in your purchasing flow that prevented a user from actually buying your product, you would be hot fixing that, like immediately. Heads would spin so fast based on the hot fix. So why is it different when someone with an accessibility requirement can't purchase something? Why is that not a bug? That's a fair question.

7. The Impact of Accessibility on User Experience

Short description:

You could double, triple, quadruple, quintuple, octuple the number of people accessing your website by catering to the disabled markets. Implementing accessibility features makes the website easier for everyone to use. It's not just fixing an alt tag, it's making the website more user-friendly. The more often people are hindered from using the website, the less likely they'll come back and make a purchase. Providing accessibility options can make a huge difference in user experience.

And the answer I heard from managers in the past to this was like, well, that's not our customers. Our customers are young and healthy and sporty, and we don't need that. How do you convince them, how do you fix that thinking? There's quite a few different options there. So many places my brain is going right now. One of them is to argue that you are selling things for young, sporty people. However, there are aunts and uncles and grandparents and cousins and friends and siblings who buy things for young, sporty people. Not all of them are young and sporty and physically abled. Some have disabilities and are young and sporty. Either way, they need to be able to purchase these things or you're losing sales. Not only that, but as Sophie mentioned in her previous in the talk before mine, is you are, you have the potential of accessing 15% of the world who is considered disabled. Now, if you have a code base or a product that accesses like 10 million people, right, you've got 10 million users, but we have like 9 billion people and 15% of those are disabled. Are disabled, but only 1 in 10 website is even partially accessible, which means that you have the ability to corner the market on that many people. So many more than you currently have as users, if your websites accessible. So you're dealing with the fact that you could double, triple, quadruple, quintuple, octuple, the number of people that you can have accessing your website just by catering to the disabled markets. Not only that, but when you implement accessibility features, it makes it easier for everyone to use the website. It's not just a, I fixed an alt tag, it's I made the website easier to use. So if you've got the sleeping baby in your mouse hand, then you can use your keyboard on your left hand to navigate the website. Or you are in a noisy room and you're trying to show your friend a video and you want the subtitles to display so they can see what's going on. It's not a standard situation where they are deaf or they are missing an arm. It's that they're everyday people doing everyday things and utilizing these features as well. And the more often they are hindered from doing that, the less likely it is they'll come back to your site and the less likely it is they'll make the purchase in the first place. And this is something that I'm surprised that not more of us think about. And thank you very much for giving us ammunition to have this conversation with our managers. Because especially the example of being partially incapacitated throughout our daily lives. I know so many moments where I was in a public setting, did not have my headphones with me, and then I wanted to read up on something. I was presented with a video that had it all in sound and I'm like, yeah, no, this is worthless to me. Bye. And then going somewhere else and probably making the purchase there as well, if they had textual information or just subtitles. The small things sometimes can make a huge difference. Yeah.

8. Subtitles and User Settings for Accessibility

Short description:

As a parent, I use subtitles to watch movies quietly. Subtitles are also helpful for non-native English speakers and understanding intense dialogue. It's not necessary to have separate versions of your website, but providing user settings and leveraging browser features can enhance accessibility. Start with the low-hanging fruit and ensure your own code is accessible before expanding accessibility efforts. Component libraries and peer reviews can also improve accessibility. Testing components for accessibility, especially with VoiceOver, can be challenging.

That's a good point. As a parent, I use subtitles all the time. I'm watching a movie later at night. And you know how it is, the explosions are really, really, really loud, but the quiet moments are so quiet you can't hear them and you're constantly adjusting that volume, this way I can just leave the volume down at something that's reasonable, and then just watch the subtitles for the really quiet parts that I can't hear what they're saying without waking up the kid.

Yeah. Yeah. And also if English is not your first language, and then you have someone with a strong dialect in an English movie, you might also just need the subtitles. It has nothing to do with having a choice at this point really, because you just don't understand what is carried in that part of the conversation, which makes it also very frustrating when subtitles are like intense dialogue. I'm like, yeah, but what are they saying? Exactly.

Nantunes is asking us, with all that diversity in the options that we touched on and that you mentioned, could it make sense to have different or separate versions of your website or app to cater to these different requirements? I'm not sure you need complete separate versions, but some options would be great, being able to go into your own user settings and select those options. Keep in mind that the browsers themselves do have some of those features to increase the contrast of your site, to reduce the contrast of your site, light mode, dark mode. Understanding what the browser gives you, and then being able to make sure that whatever settings they choose are going to still work with your website, gives you a good chunk of that to begin with. And then after that, you can start adding individual setting options. However, don't jump right into those setting options when you're still fighting with the fact that all of your buttons and links are dips. Start with the low hanging fruit. Get the stuff that's going to work for everybody and then start narrowing down as you go.

I know that we should always start working on accessibility before we start building a product, but we very few have that luxury. And we are trying to add accessibility to an existing website already. And I say start with your own definition of done. Make sure that you've decided yourself as a developer that no code is going to get past you without being accessible. Your own code is going to be accessible. And then you can start extending that to like peer reviews. Hey, this isn't going to be an accessible thing. Can you just add that alt tag? Can you turn that into a button? And then beyond that, start looking at your component libraries. The component that's reused the most, work on that. Once that component is accessible, then its use everywhere is accessible, then you can go dig into individual one-off pages and see how the combination of those components are used together and how that can create some inaccessibilities in your site. And then start working on how you can expand it to make it more accessible for people that need different setting options. But definitely start with the low-hanging fruit. That makes sense.

And speaking of components, there is a question from, hold on, let me see, GJ asking, is there a tool to not just integration tests like X does, but also unit test components accessibility, and specifically VoiceOver is apparently very hard to test for? VoiceOver is very hard to test for.

9. VoiceOver, Axe-Core, and the 508 Standard

Short description:

Part of VoiceOver is ensuring you're not using ARIA roles. Axe-Core is a great option for testing. The 508 standard ensures accessibility for US government websites. It's important to consider accessibility problems and prioritize inclusivity. The frustration for people with disabilities is feeling ignored and erased. Thank you for the talk and Q&A session. Jen is available for further discussions.

Part of VoiceOver is that technological aspect of making sure you're not using ARIA roles over various pieces. Axe-Core actually can be used in unit tests as well as functional and end-to-end tests. Axe-Core is the basis or the foundation behind Lighthouse in Chrome and the Axe Firefox in Chrome plugin, so it's a great option to start with.

All right, okay. Axe-Core is also, that's really good to know. One last question. B. Benedict is asking what's your opinion on the 508 standard, never heard that before, and how important is certification to the standard? The standard goes a long way to making sure that the websites in the US are accessible if you are either working on government land or within a government website because they need to be accessible. As a government entity, they need to have access, or everyone needs to be able to have access to their information. Important. I feel that it's important because it takes into account so many different accessibility problems that we run into on the web as a standard. And it's not just I'm going to get sued if I don't do this. It's also just the right thing to do. Talking with a lot of people with disabilities, their biggest frustration isn't always that the website doesn't work for them. But most importantly, it's that they didn't matter. Their experience didn't count. They're considered not important. And sometimes they're not even considered at all. Their existence doesn't even occur to you. And that's literally the definition of being erased. Right.

Awesome. Thank you very, very much for being with us and giving this amazing talk and answering all these fantastic questions. I think you are also in the zoom room afterwards if anyone wants to join and have a formal informal Q and A with Jen as well. That is totally possible. Let's quickly look at our poll before we jump into the break. So thank you. Thank you very much, Jen, for joining us. And again, thanks for everyone who submitted questions. Jen is definitely available and will post her slides into the Discord channel as well if you're interested. It was a great talk. It was a great Q and A. It was fantastic to be with you here.

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 Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
Top Content
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into 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 new web framework from the creators of React Router that helps you build better, faster websites through a solid understanding of web fundamentals. Remix takes care of the heavy lifting like server rendering, code splitting, prefetching, and navigation and leaves you with the fun part: building something awesome!
React Compiler - Understanding Idiomatic React (React Forget)
React Advanced Conference 2023React Advanced Conference 2023
33 min
React Compiler - Understanding Idiomatic React (React Forget)
Top Content
React provides a contract to developers- uphold certain rules, and React can efficiently and correctly update the UI. In this talk we'll explore these rules in depth, understanding the reasoning behind them and how they unlock new directions such as automatic memoization. 
Using useEffect Effectively
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Top Content
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
Routing in React 18 and Beyond
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Top Content
Concurrent React and Server Components are changing the way we think about routing, rendering, and fetching in web applications. Next.js recently shared part of its vision to help developers adopt these new React features and take advantage of the benefits they unlock.In this talk, we’ll explore the past, present and future of routing in front-end applications and discuss how new features in React and Next.js can help us architect more performant and feature-rich applications.
(Easier) Interactive Data Visualization in React
React Advanced Conference 2021React Advanced Conference 2021
27 min
(Easier) Interactive Data Visualization in React
Top Content
If you’re building a dashboard, analytics platform, or any web app where you need to give your users insight into their data, you need beautiful, custom, interactive data visualizations in your React app. But building visualizations hand with a low-level library like D3 can be a huge headache, involving lots of wheel-reinventing. In this talk, we’ll see how data viz development can get so much easier thanks to tools like Plot, a high-level dataviz library for quick & easy charting, and Observable, a reactive dataviz prototyping environment, both from the creator of D3. Through live coding examples we’ll explore how React refs let us delegate DOM manipulation for our data visualizations, and how Observable’s embedding functionality lets us easily repurpose community-built visualizations for our own data & use cases. By the end of this talk we’ll know how to get a beautiful, customized, interactive data visualization into our apps with a fraction of the time & effort!

Workshops on related topic

React Performance Debugging Masterclass
React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Top Content
Featured WorkshopFree
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 🤐)
Concurrent Rendering Adventures in React 18
React Advanced Conference 2021React Advanced Conference 2021
132 min
Concurrent Rendering Adventures in React 18
Top Content
Featured WorkshopFree
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.
React, TypeScript, and TDD
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
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.
Web3 Workshop - Building Your First Dapp
React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Top Content
Featured WorkshopFree
Nader Dabit
Nader Dabit
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.
Designing Effective Tests With React Testing Library
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Top Content
Featured Workshop
Josh Justice
Josh Justice
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn