Accessible Component System Through Customization

Rate this content
Bookmark

Most current UI libraries provide great user experience with a vast of components. But when it comes to heavy customization, and non-standard scenarios, especially for E-Commerce, they become hard to manage, scale or even slow down performance.


How to create a UI library that provides users the most possible freedom in customizing components, while keeping our performance and scalability to the fullest? How much accessible we can provide out of the box to our users? How much customization freedom is enough?


That's what my talk's about.

30 min
01 Jun, 2023

Video Summary and Transcription

The Talk discusses the importance of building an accessible UI component library, focusing on reusability, customizability, and responsiveness. It emphasizes the need for visual and functional consistency when developing components and highlights the key aspects of accessibility, including keyboard navigation, contrast, and content structure. The Talk also covers the building of accessible dialogues and provides tips for enhancing user experience. It emphasizes the significance of documentation, scalability, and customization in component planning. The Talk concludes by discussing the use of ARIA, accessibility testing, and strategies for persuading organizations to prioritize accessibility.

Available in Español

1. Introduction to Accessible UI Component Library

Short description:

You know what? I'm still... I need to recover a bit from the whole night of getting a Switch. This is my new motto now, Accessibility will bring you a Switch. We talked about UI component library. What defines a component in a component library? It has to be reusable, stylable, and customizable. Accessibility is something very hard and not relevant to component library at all, but this is the wrong thing. It also means that you have a website that looks good on desktop, mobile, and any device, screen view port, 200, 400 percent, everyone nowadays needs Zoom anyway, and that comes down to responsiveness.

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

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

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

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

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

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

2. Building a Component Library

Short description:

And lastly, the components you offer have to be isolated and testable. When you develop a component library, you need to ensure visual consistency and functional consistency. The component library is just a small part of the whole design system you are building. When building a component library, you need to plan and decide what, who, and why you build it for. An example is Storefront UI, a component library tailored specifically to the e-commerce industry.

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

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

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

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

3. Understanding Accessibility and Design

Short description:

This way it keeps us more focused and based on that we build our component on four categories: Customizability, scalability, accessibility, and ease of use. Accessibility is about more than just visual appearance. It includes keyboard navigation and ensuring that elements are focusable and usable. Keyboard navigation can be challenging, and it's important to consider the accessibility needs of users with limited mobility. Another important aspect of accessibility is contrast, which is crucial for users with visual impairments. Additionally, considering the layout and structure of your content is essential for a user-friendly experience.

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

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

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

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

4. Understanding Accessibility and Component Building

Short description:

The landmark and content layout is very important for screen readers. When using tabs, it's crucial to determine the landing point in your application. Content layout should be adaptable to different devices and zoom levels. Localization is essential for non-native English speakers. Accessibility encompasses form handling, media typography, external links, and tab orders. Breaking down components into smaller pieces can make accessibility compliance more manageable. Focus on color, landmarks, and informative content at the atomic level. Consider navigation flow and layout landmarks when building more complex components.

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

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

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

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

5. Building Accessible Dialogues

Short description:

The OneArea team developed a patterns page with common accessibility patterns and ready-to-use code. I will focus on three common examples: dialogues, autofocus, keyboard navigation, and refocusing. The implementation is simple, using attributes like aria-modal, tabindex, keydown, and ref. Avoid using z-index and consider using the native HTML dialogue element for better accessibility.

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

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

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

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

6. Enhancing User Experience

Short description:

It's doing it automatically. Just add a watch and it will work. Make sure that when a user returns to the flow, they return to the same place. Toontips can be displayed using CSS pseudocode, slotted focus, or the focus event. Avoid putting links inside toontips. When dealing with loading, keep the button reference to maintain focus and trigger refocus when the loading finishes.

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

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

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

7. Fixes, Customizability, Scalability, Documentation

Short description:

Some solutions to fix this: keep the ref of the button reference, don't unmount the button and just hide it, trigger refocus when loading finishes. Customizability is important for designers, consider using CSS variables or container queries. Scalability is achieved by designing a good design system with separate logic and components. Documentation is crucial, define the single source of truth and maintain a good code structure.

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

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

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

QnA

Importance of Accessibility and Component Planning

Short description:

Don't give us 3,000 essays' documentation because no one is going to read it. An example is always good. Accessibility tip on example is always a thing to do. And lastly, for your team, you can design some accessibility guidelines with some tips and tricks and common bugs. How to fix it helps them help you to do your job and build a component. All of this comes down to one thing, plan your component ahead.

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

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

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

Creating UI Component Library and Use of ARIA

Short description:

Why create a UI component library from scratch? It depends on the use case. For a one-time system or application, you don't need to build from scratch. In a corporate environment, building internally becomes necessary. Using an external library can be problematic. Don't use ARIA if you don't have to. Use it when there's no alternative. ARIA adds complexity to code. Use buttons when something is clickable. Avoid using div role equals button. The best automated tooling for minimal accessibility will be discussed.

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

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

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

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

Accessibility Testing and Persuading Organizations

Short description:

I just don't have enough time on my talk. If you're using playwrights or testing, there's an open-source library developed by the XCore team. You can integrate it into your automation system for end-to-end accessibility testing. After the talk, I can show you the tool. If you want to start testing, install Accessibility Insights for the web, an extension that scans web pages for compliance and tab order. How do you persuade organizations to care about accessibility? At Microsoft, compliance is policy-driven, but in other companies, provide a good example and demonstrate the importance of accessibility. E-commerce is a good example of accessibility compliance, as excluding potential customers is not profitable. Show them the impact by conducting demos and emphasizing user experience. If your bosses don't care about accessibility, consider working for a company that prioritizes human rights and user experience.

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

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

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

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

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

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

React Advanced Conference 2021React Advanced Conference 2021
47 min
Design Systems: Walking the Line Between Flexibility and Consistency
Top Content
Design systems aim to bring consistency to a brand's design and make the UI development productive. Component libraries with well-thought API can make this a breeze. But, sometimes an API choice can accidentally overstep and slow the team down! There's a balance there... somewhere. Let's explore some of the problems and possible creative solutions.
TechLead Conference 2023TechLead Conference 2023
35 min
A Framework for Managing Technical Debt
Let’s face it: technical debt is inevitable and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn't have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes. New abstractions, updated patterns and cleaning up those old functions - it all sounds great on paper, but it often fails in practice: todos accumulate, tickets end up rotting in the backlog and legacy code crops up in every corner of your codebase. So a process of continuous refactoring is the only weapon you have against tech debt.In the past three years, I’ve been exploring different strategies and processes for refactoring code. In this talk I will describe the key components of a framework for tackling refactoring and I will share some of the learnings accumulated along the way. Hopefully, this will help you in your quest of improving the code quality of your codebases.

React Summit 2023React Summit 2023
24 min
Debugging JS
As developers, we spend much of our time debugging apps - often code we didn't even write. Sadly, few developers have ever been taught how to approach debugging - it's something most of us learn through painful experience.  The good news is you _can_ learn how to debug effectively, and there's several key techniques and tools you can use for debugging JS and React apps.
React Advanced Conference 2022React Advanced Conference 2022
22 min
Monolith to Micro-Frontends
Top Content
Many companies worldwide are considering adopting Micro-Frontends to improve business agility and scale, however, there are many unknowns when it comes to what the migration path looks like in practice. In this talk, I will discuss the steps required to successfully migrate a monolithic React Application into a more modular decoupled frontend architecture.
React Advanced Conference 2023React Advanced Conference 2023
22 min
Power Fixing React Performance Woes
Next.js and other wrapping React frameworks provide great power in building larger applications. But with great power comes great performance responsibility - and if you don’t pay attention, it’s easy to add multiple seconds of loading penalty on all of your pages. Eek! Let’s walk through a case study of how a few hours of performance debugging improved both load and parse times for the Centered app by several hundred percent each. We’ll learn not just why those performance problems happen, but how to diagnose and fix them. Hooray, performance! ⚡️

Workshops on related topic

React Summit 2023React Summit 2023
137 min
Build a Data-Rich Beautiful Dashboard With MUI X's Data Grid and Joy UI
WorkshopFree
Learn how to put MUI’s complete ecosystem to use to build a beautiful and sophisticated project management dashboard in a fraction of the time that it would take to construct it from scratch. In particular, we’ll see how to integrate the MUI X Data Grid with Joy UI, our newest component library and sibling to the industry-standard Material UI.
Table of contents:- Introducing our project and tools- App setup and package installation- Constructing the dashboard- Prototyping, styling, and themes - Joy UI features- Filtering, sorting, editing - Data Grid features- Conclusion, final thoughts, Q&A
React Summit Remote Edition 2021React Summit Remote Edition 2021
87 min
Building a Shopify App with React & Node
Top Content
WorkshopFree
Shopify merchants have a diverse set of needs, and developers have a unique opportunity to meet those needs building apps. Building an app can be tough work but Shopify has created a set of tools and resources to help you build out a seamless app experience as quickly as possible. Get hands on experience building an embedded Shopify app using the Shopify App CLI, Polaris and Shopify App Bridge.We’ll show you how to create an app that accesses information from a development store and can run in your local environment.
JSNation 2022JSNation 2022
41 min
Build a chat room with Appwrite and React
WorkshopFree
API's/Backends are difficult and we need websockets. You will be using VS Code as your editor, Parcel.js, Chakra-ui, React, React Icons, and Appwrite. By the end of this workshop, you will have the knowledge to build a real-time app using Appwrite and zero API development. Follow along and you'll have an awesome chat app to show off!
GraphQL Galaxy 2021GraphQL Galaxy 2021
164 min
Hard GraphQL Problems at Shopify
WorkshopFree
At Shopify scale, we solve some pretty hard problems. In this workshop, five different speakers will outline some of the challenges we’ve faced, and how we’ve overcome them.

Table of contents:
1 - The infamous "N+1" problem: Jonathan Baker - Let's talk about what it is, why it is a problem, and how Shopify handles it at scale across several GraphQL APIs.
2 - Contextualizing GraphQL APIs: Alex Ackerman - How and why we decided to use directives. I’ll share what directives are, which directives are available out of the box, and how to create custom directives.
3 - Faster GraphQL queries for mobile clients: Theo Ben Hassen - As your mobile app grows, so will your GraphQL queries. In this talk, I will go over diverse strategies to make your queries faster and more effective.
4 - Building tomorrow’s product today: Greg MacWilliam - How Shopify adopts future features in today’s code.
5 - Managing large APIs effectively: Rebecca Friedman - We have thousands of developers at Shopify. Let’s take a look at how we’re ensuring the quality and consistency of our GraphQL APIs with so many contributors.
React Summit 2023React Summit 2023
109 min
Web Accessibility for Ninjas: A Practical Approach for Creating Accessible Web Applications
Workshop
In this hands-on workshop, we’ll equip you with the tools and techniques you need to create accessible web applications. We’ll explore the principles of inclusive design and learn how to test our websites using assistive technology to ensure that they work for everyone.
We’ll cover topics such as semantic markup, ARIA roles, accessible forms, and navigation, and then dive into coding exercises where you’ll get to apply what you’ve learned. We’ll use automated testing tools to validate our work and ensure that we meet accessibility standards.
By the end of this workshop, you’ll be equipped with the knowledge and skills to create accessible websites that work for everyone, and you’ll have hands-on experience using the latest techniques and tools for inclusive design and testing. Join us for this awesome coding workshop and become a ninja in web accessibility and inclusive design!
TestJS Summit 2021TestJS Summit 2021
85 min
Automated accessibility testing with jest-axe and Lighthouse CI
Workshop
Do your automated tests include a11y checks? This workshop will cover how to get started with jest-axe to detect code-based accessibility violations, and Lighthouse CI to validate the accessibility of fully rendered pages. No amount of automated tests can replace manual accessibility testing, but these checks will make sure that your manual testers aren't doing more work than they need to.