Creating accessible React components is crucial for enhancing user experience across diverse audiences. While there are many aspects to consider, the fundamental principle is to ensure that all users, including those relying on assistive technologies, can interact with your application effectively. This involves using semantic HTML elements and ensuring that interactive components are properly labeled and navigable.
Accessibility in web development is not just about following guidelines; it's about understanding the needs of users who interact with your application through different means. By focusing on accessibility, developers can create inclusive applications that cater to all users.
Choosing the Right HTML Elements
One of the simplest yet most overlooked practices in building accessible components is using the correct HTML elements. For instance, using a <button> instead of a <div> for interactive actions ensures that the element is recognized as a button by assistive technologies.
However, the accessibility journey doesn't end with selecting the right element. A comprehensive approach involves more than just adhering to semantic HTML practices. It requires integrating additional attributes and roles to enhance the user experience.
Role of ARIA in Enhancing Accessibility
The Accessible Rich Internet Applications (ARIA) specification comes into play when native HTML elements fall short of conveying the necessary semantics. ARIA roles, properties, and states provide additional context to assistive technologies, helping them understand the purpose and status of elements on a page.
For instance, when implementing a tabbed interface, developers can use roles like tablist, tab, and tabpanel to define the structure. These roles help screen readers announce the tabs' state, ensuring users are informed about the currently selected tab and the available options.
Implementing Keyboard Navigation
Keyboard navigation is an essential aspect of web accessibility. Users should be able to navigate through interactive components using the keyboard alone. While the default behavior allows for tabbing through elements, complex widgets like tab lists or menus may require custom keyboard interactions.
Developers can implement keyboard navigation by adding event listeners for key events, such as arrow keys, to enable smooth transitions within widgets. This ensures that users can navigate within a widget using arrow keys and exit using the tab key.
Handling Conditional Elements and States
Conditional rendering is a common practice in React, but it can lead to accessibility issues if not handled properly. Elements that appear or change state based on user interactions should be announced to screen readers to ensure users are aware of the changes.
Rather than hiding elements entirely, developers can use aria-disabled to indicate that an element is not currently interactive. This approach maintains the element's presence in the tab order, allowing screen readers to announce its state and any related conditions.
Providing Descriptive Context
A well-designed interface provides users with context about the state and purpose of components. Using attributes like aria-describedby helps associate additional descriptive information with an element, enhancing the user's understanding of its function and any conditions that apply.
By attaching descriptions to elements, developers can provide users with more information about why an element is disabled or what conditions must be met for it to become interactive.
Conclusion
Building accessible React components requires a commitment to understanding the needs of all users. By using semantic HTML, integrating ARIA roles and properties, implementing keyboard navigation, and providing clear context, developers can create applications that are inclusive and user-friendly.
Accessibility is an ongoing process that involves testing and refining components to meet the needs of all users. It is not just about compliance but about creating a web that is usable for everyone.
Twitter influencers would have you believe that if you just use the semantic html tag for elements instead of a div, your components will be accessible. but there’s a lot more that goes into it!
Let’s zoom in on one component from GitHub (one that you’ve probably used before!) and look at all the accessibility considerations involved and interesting challenges in implementing them.
This talk has been presented at React Summit 2024, check out the latest edition of this React Conference.
ARIA (Accessible Rich Internet Applications) provides a set of roles that convey the accessibility semantics of structures on a web page. It helps in making web content and applications more accessible to people with disabilities.
The main focus of Sid's talk is on building accessible React components, with an emphasis on accessibility.
'ARIA disabled' is an attribute that keeps an element in the tab order and allows it to be focusable, unlike the 'disabled' attribute which removes elements from the tab order. 'ARIA disabled' is preferred to make the element accessible while indicating that it is not currently interactive.
Sid recommends the Axe family of tools, which includes plugins for various environments like CLI, Jest, and Storybook. These tools help catch accessibility issues, but he emphasizes that manual testing is also necessary.
Sid suggests providing clear information about the state and conditions of UI elements, such as using 'ARIA disabled' and 'ARIA described by' to make elements accessible while explaining why they are disabled. This approach improves the user experience for both sighted and screen reader users.
No, Sid is not an accessibility expert. He refers to himself as a 'silly React guy' who has learned about accessibility from working with experts over the past year.
Sid works on the design systems team at GitHub, where he maintains the React component library.
Sid emphasizes using the correct HTML elements, like using a button instead of a div for interactive actions, to improve accessibility. However, he acknowledges that this is just one part of making web experiences accessible.
The speaker is Sid, whose full name is Siddharth. He prefers to go by Sid to avoid mispronunciations of his name.
Sid identified that using buttons for tabs can be problematic for screen reader users because it doesn't convey hierarchical or contextual information well. Instead, he suggests using ARIA roles like 'tablist' and 'tab' to provide better accessibility semantics.
The talk discusses building accessible React components and emphasizes the importance of using the correct HTML elements and ARIA roles for accessibility. It explains how to navigate and select options within a form and how to add supplementary text using Aria described by. The speaker also discusses the benefits of using conditional checkboxes and ARIA disabled to improve the UI. Additionally, the talk explores the role of JavaScript in web accessibility and provides recommendations for testing website accessibility.
I'm Sid, a front-end developer on the design systems team at GitHub. Today, I want to talk about building accessible React components.
2. Making Accessible Experiences
To make accessible experiences, using the correct HTML element is important. However, there's more to it. Tabs are a good pattern for showing controls in a small space. The implementation involves buttons and changing states. When using a screen reader, the focus on a button is announced, along with its label and associated actions.
3. Using ARIA Roles for Accessibility
The use of the correct HTML element is important, but in cases where it's not feasible, the ARIA roles can be used to convey accessibility semantics. By assigning the role 'tab list' to a div and 'tab' to buttons, the semantics are added to indicate their purpose. The element type, such as a button, becomes less relevant, and the focus can still be achieved by setting a tabindex. Panels with content should have the role 'tab panel'.
4. Using ARIA States and Properties
The screen reader announces the selected tab and provides information about the number of tabs available. However, there is a quirk where all tabs are incorrectly announced as selected. To address this, the ARIA states and properties are used. By adding the 'aria-selected' property to the relevant elements, the correct selected tab is announced. Testing confirms that the screen reader now correctly identifies the selected tab and allows for tab switching.
5. Implementing Arrow Key Navigation within Tab List
To navigate within a tab list, arrow keys can be used instead of tab keys. By resetting the tab index and adding event listeners for arrow key navigation, the user can easily move between tabs within the widget. This functionality is not provided by ARIA roles or properties, so it needs to be implemented manually. A hook called use focus zone is available to handle this common pattern in React applications.
6. Improving Tab Navigation and Notification Settings
Changing tabs on focus instead of click can provide a nicer user experience. While the ARIA spec doesn't mention when to change tabs, it does emphasize updating ARIA selected when the tab changes. The ARIA authoring practice guide (APG) provides useful patterns for tabs and other accessibility practices. It's important to use elements, rules, ARIA properties, and keyboard navigation to make interfaces accessible. An example of changing notification settings on GitHub demonstrates the importance of semantically correct code and screen reader announcements.
7. Navigating and Selecting Options in a Form
The speaker demonstrates how to select notification channels using accessible checkboxes and provides a step-by-step guide on navigating and selecting options within a form.
8. Using Conditional Checkboxes and Aria Disabled
The speaker discusses the use of conditional checkboxes in React, highlights the importance of not hiding important elements from users, and explains the use of Aria disabled to make elements accessible yet disabled. They also mention the need to update the on change event for Aria disabled elements.
9. Adding Supplementary Text and Demo
The speaker explains how to add supplementary text using Aria described by. They discuss the option to show or hide descriptions based on user preferences and emphasize that website authors do not have control over this feature. The speaker then provides a quick demo of the entire process, highlighting the importance of selecting at least one channel for the 'Only notify for failed workflows' option.
10. Using Conditional Descriptions and ARIA Disabled
The speaker discusses the benefits of using conditional descriptions and ARIA disabled to improve the UI for both visually impaired and sighted users. They highlight the clarity and functionality of the design, which provides clear announcements and explanations for disabled elements.
11. Designing with Accessibility in Mind
The speaker discusses the importance of designing with accessibility in mind and the use of ARIA disabled to disable elements. They mention the limitations of using buttons for tabs and how it can override styles and the tab order.
12. The Importance of Semantic Elements
The speaker discusses the importance of starting with a more semantic element, even though it may be overridden later. They mention the possibility of missing important states when using non-semantic elements and highlight that there is ultimately no difference in the end.
13. The Role of JavaScript in Web Accessibility
The speaker discusses the use of JavaScript for adding accessibility to components. They explain that while some basic accessibility features are already baked into browsers, JavaScript is necessary for customizing keyboard navigation and creating dynamic widgets. The speaker highlights the importance of carefully considering which JavaScript functions are necessary immediately versus which can be deferred. They mention the Primer React component library as an example of the decision-making process. Ultimately, JavaScript is required for web accessibility.
14. Testing Website Accessibility and Public Speaking
The speaker discusses tools for testing website accessibility, recommending the Axe family of tools. They highlight the limitations of automated testing and emphasize the importance of manual testing. The speaker also addresses the challenges of disabled states in browsers, expressing a desire for more advanced accessibility controls. Lastly, they share their approach to public speaking, which involves treating the audience as friends and focusing on improving their content with each presentation.
Today we will discuss React server components with AI and how to build a better search experience using them. We will learn how to make a Next.js app AI-enabled using the Vercel AI SDK. The Vercel AI SDK's streamUI function with the GPT 4.0 model will be used to make suggestions interactive. We will explore the use of history and conversation in AI and how to continue the conversation and read the result. The concept of generative UI with the vector database will be introduced, along with querying the database for movies. We will process user queries and return movies based on them. The power of React server components in enhancing UI will be demonstrated. In summary, the Talk covers vector embeddings, natural language search, and generative UI.
Today's Talk discusses building flexible, resilient, and future-proof React components using composition and configuration approaches. The composition approach allows for flexibility without excessive conditional logic by using multiple components and passing props. The context API can be used for variant styling, allowing for appropriate styling and class specification. Adding variants and icons is made easy by consuming the variant context. The composition and configuration approaches can be combined for the best of both worlds.
Today's Talk discusses expensive React components and API design, with a focus on the cost of coordination and overcoming imposter syndrome. The speaker shares a story about a cat trying to fix salted coffee, highlighting the importance of finding simple solutions. The billion dollar component on ReactJS.org is examined as an example of an expensive component. Techniques for customizing messages, improving accessibility, and using polymorphic props are discussed. The Talk concludes by emphasizing the cost of communication and the need to evaluate if props and components are the right tools for the job.
Building a design system without adoption is a waste of time. Grafana UI's adoption is growing consistently over time. The factors affecting design system adoption include the source mix changing, displacement of Homebrew components by Grafana UI, and the limitations of Grafana UI's current state. Measuring adoption is important to determine the success of a design system. The analysis of code through static code analysis tools is valuable in detecting and tracking component usage.
This talk discusses achieving layout composition in React using Bedrock Layout Primitives. By componentizing CSS layout, complex layouts can be achieved and reused across different components. The talk also covers the challenges of achieving complex layouts, such as card lineups, and provides solutions for maintaining alignment and responsiveness. The BedrockLayout primitive library simplifies web layouts and offers flexibility in composing layouts.
Cypress component test-driven design can take front-end engineers to the next level by covering TDD examples, component testing, endpoint testing, and recommended best practices. The TDD flow involves starting with failing tests, making them work, and then improving them. Component tests can be written incrementally, using custom wrappers and props. The differences between React Testing Library and Cypress Component Test lie in the API style. Code coverage can be achieved with Cypress component tests, and the Pack.js Cypress Adapter can be used to avoid test duplication between the backend and frontend.
Get started with AG Grid React Data Grid with a hands-on tutorial from the core team that will take you through the steps of creating your first grid, including how to configure the grid with simple properties and custom components. AG Grid community edition is completely free to use in commercial applications, so you'll learn a powerful tool that you can immediately add to your projects. You'll also discover how to load data into the grid and different ways to add custom rendering to the grid. By the end of the workshop, you will have created an AG Grid React Data Grid and customized with functional React components.- Getting started and installing AG Grid- Configuring sorting, filtering, pagination- Loading data into the grid- The grid API- Using hooks and functional components with AG Grid- Capabilities of the free community edition of AG Grid- Customizing the grid with React Components
In this hands-on workshop, Maurice will personally guide you through a series of exercises designed to empower you with a deep understanding of React Server Components and the power of TypeScript. Discover how to optimize your applications, improve performance, and unlock new possibilities.
During the workshop, you will: - Maximize code maintainability and scalability with advanced TypeScript practices - Unleash the performance benefits of React Server Components, surpassing traditional approaches - Turbocharge your TypeScript with the power of Mapped Types - Make your TypeScript types more secure with Opaque Types - Explore the power of Template Literal Types when using Mapped Types
Maurice will virtually be by your side, offering comprehensive guidance and answering your questions as you navigate each exercise. By the end of the workshop, you'll have mastered React Server Components, armed with a newfound arsenal of TypeScript knowledge to supercharge your React applications.
Don't miss this opportunity to elevate your React expertise to new heights. Join our workshop and unlock the potential of React Server Components with TypeScript. Your apps will thank you.
Join us for a 3-hour workshop that dives into the world of creative React development using Codux. Participants will explore how a visually-driven approach can unlock creativity, streamline workflows, and enhance their development velocity. Dive into the features that make Codux a game-changer for React developers. The session will include hands-on exercises that demonstrate the power of real-time rendering, visual code manipulation, and component isolation all in your source code. Table of the contents: - Download & Setup: Getting Codux Ready for the Workshop- Project Picker: Cloning and Installing a Demo Project- Introduction to Codux Core Concepts and Its UI- Exercise 1: Finding our Feet- Break- Exercise 2: Making Changes While Staying Effective- Exercise 3: Reusability and Edge Case Validation- Summary, Wrap-Up, and Q&A
In this workshop, I’ll first show you how to create a new project in a headless CMS, fill it with data, and use the content in your project. Then, we’ll spend the rest of time in code, we will:- Generate strongly typed models and structure for the fetched content.- Use the content in components- Resolve content from rich text fields into React components- Touch on deployment pipelines and possibilities for discovering content-related issues before hitting production You will learn:- How to work with content from headless CMS- How content model can be leveraged to generate TS types and what benefits it brings to your project- How not to use string literals for content in code anymore- How to do rich text resolution into React components- How to minimize or avoid content-related issues before hitting production
Comments