FE.ARIA-Audit the accessibility of the design system (translation)

Since starting my career in 2012, the knowledge about inclusive design has been hampered by obstacles and teaching gaps. My ambition is to help designers remove obstacles. Developers and technicians want to build a better and more inclusive experience. In this blog post, I want to specifically inform my fellow designers about places that need to be entered for accessibility reasons.

I will focus on the most critical accessibility work I think designers can do: creating a design system with inherent accessibility compliance. In particular, we will focus on learning how to find accessibility issues in existing design systems and document them in a way that makes them feasible for ourselves and our team.

You can broadcast the video version of this article YouTube

Design system and auxiliary functions

What exactly is a design system? The design system is the single source of truth for a product, site or experience. These include the common goals and set of values ​​of the design/development organization, as well as brand elements and components. The design system combines related implementation elements, defines their purpose and clarifies their delivery.

If done correctly, the design system should evolve and expand with the organization. These systems are important because they allow us to do large-scale work, do something and then apply it everywhere and build a more consistent brand. But the most important thing is that designing a system is essential because it can also help us expand accessibility.

Every atom, molecule and organism we create in the system affects our ability to scale up and meet the needs of people with disabilities. My mention of atoms, molecules and organisms directly quoted Brad Frost's "Atomic Design" (if you are interested in thinking about design systems, I suggest you read it).

When "Atomic Design" was released in 2016, it marked an important shift in digital design thinking. Although many teams have begun to use pattern libraries and frameworks, such as Bootstrap, "Atomic Design" recognizes what we are all beginning to see: digital design requires better systems.

Four years later, when the design team defended the design system, it still regularly quoted Brad Frost's book. We can also use this method to help inform how to design for accessibility at scale and how to audit our systems to ensure accessibility compliance. In " Atomic Design ", Brad Frost uses atomic methods to decompose the scale of the design system. Our system essentially overlaps each other, starting with elements (such as atoms), which can be combined to create molecules, and can be further combined to form organisms.

These creatures inform and create templates, which can then be applied to specific pages in our platform. At this scale, everyone and each team has a different understanding or jargon, but the basic elements of these principles tend to exist consistently in most digital design systems.

We don't have to have a robust or "perfect" design system to use this method or audit accessibility. Whether our team is just getting started, already has a well-documented system available, or somewhere in between, we can apply the content described in this blog post at any time during the development of our design system.

Subatomic particles

Let's start by breaking down the scale of atomic design. But before discussing atoms, let's talk about our "subatomic particles", the basic elements that make up our design systems.

They are not our atoms, but they can inform the generation of atoms. These subatomic particles are often brand colors or fonts. Although these elements alone do not seem to be the most important for our system, they affect all the elements we create, from the smallest scale to the full page.

atom

Atoms shows all our basic styles at a glance, which is a very helpful reference for us to keep looking back when we develop and maintain the design system. Some systems have a greater granularity than others, so please note that in this case, words such as "atomic" may sometimes have different meanings in different teams.

For our purposes, atoms are such as 160a7618783bd7 form tags, inputs and buttons , elements that cannot be decomposed without stopping functioning. The example below is a label, a drop-down selector, and a button, each of which acts as a unique atom. However, just like atoms in nature, interface atoms do not exist in a vacuum, and can only be realized in applications.

molecular

In the next step of atomic expansion, we have molecules: Molecules are relatively simple groups of elements or atoms, which together function as a unit.

For example, form tags, drop-down selectors and save buttons can now be functional form field units. When combined, these abstract atoms suddenly have a purpose. Before we had labels, drop-down menus and buttons, but now we can combine these elements

Now, selecting the button atom saves the drop-down inputs, and the label indicates the purpose of these inputs. The result: a simple, portable, and reusable component that can be placed wherever you need to drop down input or save forms.

organism

Expand the scale again: Organisms are relatively complex components composed of molecules and/or groups of atoms or even other organisms. These organisms form different parts of the interface.

From molecular accumulation to finer organisms, it provides designers and developers with basic environmental awareness. Organisms exhibit smaller, simpler action components and act as unique patterns that can be reused.

The following is a sample drop-down/save form that we applied to a specific environment, in this case, the shipping information form. The organism is also composed of other atoms and molecules, with more specific purposes.

Templates and pages

Getting rid of the analogy, we can use our atoms, molecules and organisms to create templates and pages. template is a page-level object that can place components in the layout and clarify the design under the content structure.

If we reuse the structure of the page for many different applications, we can use the template for other pages. The template shows that all the necessary page components work together, thus providing context for our relatively abstract molecules and organisms.

By defining page templates, we can create a system that illustrates different dynamic content, while providing the necessary guardrails for content types that fill certain design patterns.

Finally, the page is a specific instance of templates that show what an experience with actual representative content looks like . In addition to presenting the final interface to the user, the page is also the key to testing the effectiveness of the underlying design system elements. We can see how all these patterns are maintained when the actual content is applied to the design system at the page level.

In the example below, we take a shipping information form and apply it to a specific page in a website or application.

What happens when the design system forgets accessibility?

Therefore, we have brought atoms into a molecule, bundled that molecule with other atoms and molecules to create an organism, and then applied it to pages and/or templates. These are the basic design principles that make our design system flourish in design and development. A design system with a reasonable scale can make it infinitely easy to think around user needs and make our workflow more efficient. It's simple, right?

But please wait a moment!

Atomic design is very good, but when we created this sample interface, we did not consider accessibility. We are just thinking about designing the system. Doing so may have an impact on the entire system, so let's take a step back and understand some of these effects.

In the sample interface, we have created a page that contains but is not limited to the following questions:

• Use hamburger menus without visual labels and unclear surrounding programmatic labels. The hamburger menu cannot provide a clear context, and it is difficult for users to understand its purpose without adding visual and programmatic labels.
• None of the form fields have mandatory indicators, so users will not know what is required or optional.
• The boundary contrast of the form fields is very poor, which means that it may be difficult for users to know where to select the form field to enter data (current contrast ratio is 1.48:1).
• The form field labels are placed next to each other. Can users zoom in by 200% on this interface without losing content or functionality?
• No input instructions are provided. If the input does not match the required format, does the user know how to prevent the error from occurring?
• The color contrast on the save button is not high enough. As a result, it may be difficult for users to read it (the current contrast ratio is 2.38:1).

Design should consider accessibility

There may be more problems than this, but we can start to understand that only a few events will quickly make things inaccessible quickly. If we use atoms, molecules, and organisms without considering accessibility, then even in our entire experience, we will encounter elements involving accessibility issues and problems throughout the page. Reviewing the entire page can be a bit cumbersome, especially when the problem is related to the inherent design of the component or the construction of the component.

For the sake of simplicity, let's go back to the beginning. Before we make organisms or molecules, we already have atoms. We can check the accessibility of this page from an atom (ie our button). Our example button design may have some shortcomings, but for the sake of simplicity, let's focus on the case where it does not meet the color contrast standard.

This error is not only related to our atoms, but also to the subatoms in our text style and color options. Earlier in this article, we discussed these basic elements and how they affect these designs. Now we can see the use of these foundations to create atoms without considering the consequences of accessibility.

Our button uses sky blue in its background and white text at the top. Our text is 14 pixels, uppercase and semi-bold. When we use the color contrast checker to test this button, we can know that this button does not meet the color contrast requirements. When the contrast ratio needs to reach 4.51 to pass the minimum required level, the ratio of this color/type combination is 2.39:1.

The contrast checker shown here is Figma's Stark plug-in .
However, as I mentioned before, this color combination will not only affect this component, it will affect more. We know that there is a problem with a component, and we know that it is likely to affect others because its problem is fundamental. This is where our audit really comes into play.

Design should consider accessibility

Questions such as color contrast examples are why design needs to consider accessibility, especially in design systems. There is a misunderstanding in the design community that accessibility is usually the developer's responsibility, but when developers are design-centric, they cannot solve design system problems.

In fact, last year's Deque case study found that 67% of the accessibility problems of

As shown above, if it is not resolved early and often, resolving accessibility issues may increase the time and money spent. Since designing systems is our most effective way to scale, prioritizing accessibility in these systems can save a lot of time and money. When widely used in our design system, fixing issues such as color contrast will result in an improvement in the overall accessibility of our products.

Review design system

View the contents of an existing file

Before development, the easiest time to check whether our design meets accessibility. However, many of us use real-time components in design systems, in-flight components, and even combinations of real-time but undocumented components. The first step of the accessibility review of the design system looks like a standard component review. We want to check our components, which are most actively used to create designs and document existing content.

We don't have to start thinking about accessibility yet. Instead, the purpose here is to record what exists and collect elements with similar purposes together. Before making our work more accessible, we need to understand the current accessibility of the system and the distance we need to travel. We can audit individual components, related components or the entire component system. We can even review a button, but still get viable results. This has to do with how we are going to deal with it and the resources we have over a period of time.

We may find that existing design components include atoms, molecules, and organisms. It is important to capture all of these and pay attention to their intended purpose. We don’t have to write a complete document or the like, just take notes.

Capture all real-time components

Similarly, we should capture all real-time components. We can do this by referencing our design files, development libraries, real-time experience, or anything in between, as long as we capture what exists or what we intend to make. We should also include things like different interaction states such as hover or focus.

To this end, we can capture each pattern library and real-time component through a screen shot, and then upload the file with its upload date, time and location to the manifest file. Then, each captured item can be placed on a page named after its purpose. It is very useful to capture components in this way when recording the content that currently exists, because the content that currently exists can easily be changed in the real-time product. This ensures that we can remember when and where they existed.

Remember, the purpose of capturing these components is to first audit the system itself and what it exists. This part of your process is simply about understanding what our users are interacting with and ensuring that we can understand the impact of a certain component on the system as a whole.

For example, our buttons will have a greater impact on our users because they are the core components used in our experience. If other components are related to necessary interactions (such as the user's ability to log in), they may still have a significant impact.

Cross-reference and start drawing questions

In the last part of the system review, we want to ensure that the content we capture is consistent across all our experiences and record all independent or unique instances. We need to ensure that these buttons in the design are consistent with the buttons in the development library, and also consistent with the actual buttons used.

While capturing the live, we can cross-reference with our design team, and then we can start to see what gaps exist. Now you may be thinking: "Just reviewing our design system will not help accessibility!" But remember that accessibility should be included in our existing design system strategy . We need to review and expand our design system to enable it to expand its accessibility. These practices should go hand in hand.

Now that we have reviewed the system, we can now discuss what needs to be checked to ensure accessibility compliance and how to proceed.

Incorporate accessibility into our audit

Common accessibility issues in design

What should we review in terms of design? As we mentioned before, 67% of accessibility issues start with design, so it may be more than we realize! Many items are outlined in the Web Content Accessibility Guidelines, many of which involve design as much as design. Although our previous examples focused on typical examples of accessibility in digital design, we need to keep in mind more than just color contrast.

Some other standard accessibility requirements that need to be outlined in the design include:

• Color usage
• Content strategy
• Title structure
• Link behavior
• Hover state and focus state
• Forms (errors, labels, etc.)
• Layout (consistency, responsiveness)
• Media (subtitles, alternate text, etc.)
• Tab order and bypass blocks
• timing
• format
• And more!

WCAG's "Quick Reference Guide" is a good place to refer to what we need to consider, which includes all of this and more, and ways to meet these guidelines. This quick reference is also very convenient when reviewing and running components through review.

When we have a set of components outlined by purpose, we can more easily navigate the UI and understand other accessibility requirements. Now, we can study atoms, molecules and organisms according to their patterns and uses, which will help us solve more surface problems.

In addition to color contrast, there is more to the accessible design.

You may be thinking, is WCAG really only applicable to color contrast or UI? However, the accessibility review in our design system involves more than color contrast or UI. Review the accessibility of our design system is as important as UX and UI . As we discussed, accessibility is mostly located in other parts of the system, including content, hierarchy, images, and so on. Although UI accessibility is indeed important, designers tend to think that our responsibility for accessibility is mainly focused on color and type, because we do not realize the close connection between UX and accessibility.

So let's review the components together.

This example alarm is designed to have a set of different types of messages: information, success, warning, and error. We can investigate several user experience items through this alert. For example, we can ask ourselves, should these icons have alternate text? Suppose these icons currently have no alternate text, but we think they should be displayed because we want the icon to convey a warning sound to users who may not see the icon.

Therefore, in the accessibility review, we can notice that these icons do not use alternate text and associate them with WCAG 1.1.1 non-text content. If we use these icons for similar purposes elsewhere, this note in the audit will help us extend the UX element to many different instances.

Or, suppose our false alarm shows multiple errors in an alarm container. We will need to ask if the alert identifies errors that need to be fixed, where the errors are and how to fix them. If our alert does not perform these actions, we can log the problem and associate it with the WCAG 3.3.1 error ID .

These are just questions we as designers can and should ask ourselves when considering existing components and building new ones. If we put these components together and provide contextual references for them, it will be easier for us to understand the potential accessibility gaps and add them to our review.

Before we learn how to record audits, there is one last thing: our design system audit should review both the design and the accessibility code. If our components are in the component library or in a running state, we will also want to view their code. Because although we can solve 67% of the problems in the design (such as all accessibility), our work will not start or stop in a team.

I know that some designers may be a little afraid of the accessibility of audit code, but we don’t have to be developers to audit code. To view the code, we can work directly with the developer, or even use a tool that allows us to review the code on a page or specific component. Many tools allow us to review the code on a page or specific component.

I would call Chrome developers use Axe DevTools plug-in , which is a good choice for designers to try when reviewing the design system. When you select more information, related WCAG standards and user impact, Axe DevTools will tell you where the problem is. Using this tool, we can run automated tests and guided manual tests to thoroughly review our design and code.

Use ax DevTools:

1. In Chrome, I will right-click and select "Inspect" and then select the "ax DevTools" tab.
2. For component review, you can choose " scan part of my page ". Then, select the part of the page you want to review, and click "Scan" .
3. Use highlight tools to focus on the design projects you want to focus on
4. save result or question export as CSV or JSON file

How to record an audit

So far, I have discussed what a design system is and what to look for in a design system accessibility review, but let's discuss how to record the review. I know I have already hinted at adding something to the audit, but what does it look like?

Include background details

Please refer to this background example and other details in Accessibility Audit Template
Any accessibility review (whether it's our design system, code or pages, etc.) requires you to start with the background of the construction. We should mention who is reviewing, the summary we are reviewing, and the level of accessibility we wish to meet. We also want to include the scope of the review, a timetable and an overview of the review process.

This background is important because our review will always be quoted after the review is completed, and we need to make sure that the person who is reviewing has the background to conduct the review. If our review is older, whoever views it may know that it is no longer relevant. Including these details will help us and our peers make the most of the audit. It will also create an excellent benchmark for comparison for future reviews.

Build your review

Now that we have discussed the audit itself, I will only briefly describe the process of constructing an audit. Making a list of the items we captured will help us understand the existing problems, their severity and how to solve them.

If we are using axe DevTools Pro , we can export the results and fine-tune the details according to the needs of the organization. By default, Axe always contains a lot of detailed information, so I find it easy to customize it to my audience and review requirements. We can also manually add items to the CSV or JSON axe file we are using when we encounter more problems or when/whether to review in the design tool instead of the code.

Generally, I recommend at least including:

• Project/Component – ​​What is the component related to this issue? Links to screenshots are valuable here because they can help someone understand what we are referring to.
• WCAG Guidelines-What issues in WCAG are related to this? Use WCAG's quick reference guide link to related WCAG items can be very helpful for setting the context.
• Impact – How much impact will this have on users or businesses? How often is the project used (more = more impact)? Is this item used for necessary operations (such as logging in)? AxenDevTools Pro will recommend influence, which is very helpful as a benchmark.
• Description-a detailed description of the problem found
• Recommendations-Explain how your team solves the problem. In many cases, the problem can be solved in multiple ways. We can describe possible fixes to help our team understand the options.

I encourage you to customize your method to find the best method for you and your team. Most importantly, you are trying to document the problem in a way that makes it actionable so that your organization or team can act accordingly.

Group topics and common items

In addition, when conducting and recording audits, I recommend grouping frequently occurring items together. Again, this touches our atomic scale: if contrast issues occur on many different projects, they can be grouped together. Grouping and theming, especially for your design system review, is very important, because it means you will have a greater impact without having to make a lot of fine-tuning in many different places. The power of the design system is that with a little effort, a change can have a considerable impact.

Pay attention to intent and application

Another important thing to remember: You may find that when you review the design system individually, you don’t capture everything you need to make everything more accessible. This is because designers tend to work in complex systems, and design systems are all related to intent. Therefore, in some cases, the content you captured in the review and repair may not be suitable for the application of your design system.

Your atoms may be great and easy to access, but your organisms need more attention because they are more unique in specific situations. Maybe you can’t access the implementation of your design system components due to things like the copy you end up using.

This is one of the reasons why I experienced atomic scales: to help us understand the difference between intent and application. It will go a long way from designing the system, but due to different applications, it is not necessary to fix everything on the real-time site.

How should you handle the review?

Once the review is completed, what should I do next? First, you need to use the findings in the spreadsheet you created to authorize your team. Getting a spreadsheet with hundreds of items can help solve the problem, but if you just give a spreadsheet to your stakeholders and say "you go!", it will be daunting.

Instead, this is the audit work you should perform to make it more useful:

• Summarize the impact area and determine the number of critical, serious, moderate, minor, and best practice items.
• Identify key themes, which are the most common items in the entire system.
• Create an impact framework to determine which issues have the most impact and the least amount of work.
• Share results with your team and organization in a digestible and positive way.
• Work with stakeholders to prioritize improvements.

Make your review work for the audience

The most important thing about the accessibility audit itself is to make it actionable and share the results with the team, making it easy for them to learn and take action.

Below is an example of a client-specific audit sharing, in which I have outlined the most common issues, themes, and the most influential projects. After the review is over, we need to ensure that everything we have discovered is presented at a high level. In other words, we need to outline the most critical parts of identifying and determining the theme, and share an impact framework to help determine which issues can be resolved the fastest and have the greatest impact.

Together with our full review, we can share the results in an easy-to-digest way and work with stakeholders to prioritize improvements, while also having detailed information on actions to be taken on each issue.

Design not suitable for people with disabilities

Finally, remember that accessibility is only a form of design, and all design methods need to be discussed and tested. The difference is that accessibility is to ensure that the needs of people with disabilities can access our design.

One of the most important aspects of barrier-free design is to work with the disabled instead of designing for the disabled. WCAG is written by and by the disabled, so it is very suitable for use in audits. But is that everything? No, like all designs, accessibility requires us to talk to people and understand their unique situation, especially when using our website and products.

Audits cannot replace disabled users for testing and design. Although I won’t suggest a perfect inclusive research strategy in this blog post (maybe another post), I still want to point this out because I don’t want anyone to think that audits are about accessible design all. This is a key component, but we need to constantly hear and respect the needs of users and people with disabilities. I encourage you to gain insights from audits, find ways to ask users’ ideas, test your ideas with them, and pay special attention to marginalized users.

Generalize

No matter how satisfied you are with accessibility, starting to review the accessibility of a design system is a daunting task. However, I want to encourage you to be curious. Many designers have not received accessibility training, and this is done in educational institutions, not on you. The fact that you are interested in learning is a very important step.

If you do not familiar review the design or code of accessibility, please try to use DevTools Pro ax , open WCAG quick reference , then casually recorded content discovery. Ask yourself questions. Ask your team questions. Just play with these tools, skip these guidelines, and curiosity will take you far. To be honest, a lot of my accessibility knowledge comes from these practices.

Tools to start the review:

1. Axe DevTools Pro
2. Quick reference for WCAG
3. Watch how to use the axe-con presentation I gave for review
4. Atomic Design, Brad Frost
5. A11y Project Accessibility List

original

https://www.deque.com/blog/auditing-design-systems-for-accessibility/