Many people use component-driven development using pattern style guides, component libraries, or full design systems in their                 development workflow process. Even if you have not used these tools formally, it's likely you use a similar process to break up a                 large design for a website, app, or other digital product into manageable pieces.

Like building a physical structure, it's important to build one piece at a time. First, the foundation, the structure, walls,                 windows, roof, and everything in between. Component-driven development tools allow us to do this for websites, apps, and other digital products.

Some perks to component-driven development include breaking things down into                 manageable pieces, so there is less development time with these reusable                 components. It allows designers, frontend and backend developers, and QA to                 work simultaneously. And clients, designers, PMs, and more, like it because                 they can preview the build process and use a living style guide as a reference                 after the website has launched.

However, when we look at patterns, components, and design systems with accessibility in mind, some questions arise. How do you know                 which patterns are best when it comes to accessibility? Should you use an established pattern/library or create new ones? How to do                 Do you know if these patterns will help your users?

With the myriad of choices available, it's easy to quickly become confused about this topic. This module aims to give you a general                 information on how to evaluate patterns, components, and design systems for accessibility and gives you a starting point to help you make                 more accessible choices.

Think critically

Choosing an accessible pattern, component, or design system is not a rocket                 science, but it does take time and critical thinking. There 's no such thing as "one perfect pattern," but there may potentially be many options that could work. It's about learning to choose the best option for your unique situation.

In the subsequent testing modules, you will learn more about the techniques and methods on how to evaluate patterns, components, and                 design systems for accessibility. But before that stage, you need to step back and ask yourself some fundamental questions, such as:

                
• Does an established accessible pattern, component, or design system already exist?
                
• What browsers and assistive technology (AT) am I supporting?
                
• Are there any code/framework limitations or other integrations/factors/user needs I need to consider?
                

Depending on your dev environment and user needs, you may have additional or different questions from these. Consider                 these questions as your starting point in your accessibility evaluation.

Established resources

Before building something brand new, do your due diligence and review what already exists in terms of accessible patterns,                 components, and design systems. With just a little research, you might be surprised to find a solution—or multiple—that fits your needs.

Some great resources for accessible patterns, components, and design systems include:

                
• Accessible Components
                
• Deque University ARIA library
                
• Gov.UK Design System
                
• Inclusive Components
                
• MagentaA11y
                
• U.S. Web Design System (USWDS), created for the U.S. federal government
                
• List of accessible patterns from Smashing Magazine
                

For JavaScript frameworks, the following resources are fairly accessible out of                 the box or are easy to customize for accessibility:

                
• When CSS Isn't Enough: JavaScript Requirements For Accessible Components
                
• React                 
                  
  • ReachUI
                  
  • Reakit
                  
  • Chakra
                  
                
• Angular: Material library
                
• Vue: Vuetensils
                

However—and this cannot be stressed enough—you should never just copy/paste                 code and assume it will fit within your environment and automatically meet your                 user needs. This is true of all patterns, components, and design systems, even                 if labelled as fully accessible.

All resources should be seen as a starting point. Be sure to test everything!

Browsers and assistive technology (AT) support

After researching a few base patterns, components, or a full design system that                 might work for your dev environment, you can move on to assistive technology                 support. One major type of AT you will want to focus on when evaluating                 patterns, components, and design systems are screen readers.

Screen readers were built with specific browsers in mind and will work best                 when paired with these browsers. We'll go into this topic in much more detail                 in the module on AT testing, but for pattern evaluation purposes, it is helpful                 to understand these combinations exist, so you know what you need in terms of                 support.

Browser support is generally complicated, and things get even trickier when you add AT devices and ARIA specifications to the mix.

But it's not all bad news. Thankfully, great resources such as HTML5 Accessibility,                 Accessibility Support, and WCAG's Custom Control Accessible Development Checklist                 help us to better understand current browser and AT device support, and even when to use ARIA in the first place.

These resources outline the different HTML and ARIA pattern sub-elements available, including open-source community tests.                 You can also review some pattern examples—for both desktop and mobile browsers/AT devices. As such, these resources can help                 you make a more accessible decision regarding patterns, components, and design systems that you may want to use.

Other considerations

Once you have chosen a few accessible base patterns or components, and factored                 in browser and AT device support, you can move on to more specific contextual                 questions about the pattern, component, design system, and dev environment.

For example, if you are working in a management system (CMS) or have a legacy                 code, there may be some limitations to which patterns you can use. Upon review,                 several pattern choices may quickly be cut to one or two options.

Many JavaScript frameworks allow developers to use almost any pattern they                 choose. In cases like these, you may have fewer restrictions and can choose the                 most accessible pattern option.

There are additional considerations to weigh when choosing a pattern,                 component, or design system, such as:

                
• Performance
                
• Security
                
• Search engine optimization
                
• Language translation support
                
• Third-party integrations
                

These factors will undoubtedly play into your pattern choice, but you should                 also, consider the people creating the content and code itself. The pattern you                 choose must be robust enough to handle any potential limitations around                 editor-generated or user-generated content, plus be built in a way that                 developers of all accessibility knowledge can use.