Website Accessibility

Introduction

I still remember when I first entered the workforce, I often saw many foreign experts on X sharing that their products had met accessibility standards, or that their design systems fully supported A11y and other keywords.

At the time, I thought, "Another new thing!! I really can't keep up..." and wondered if this was just a fleeting trend that wouldn't last more than a season.

It wasn't until I joined a U.S. startup that I realized the importance of accessibility. Initially, the tasks I received were mostly simple, but what surprised me was that almost all of them were related to accessibility fixes or optimizations, such as enabling keyboard operation or ensuring screen readers could correctly vocalize content.

That's when I discovered that the company was in the process of comprehensively promoting website accessibility support. I also began to understand that U.S. law has certain requirements for website accessibility, and if a website is not well-made, there is a risk of being sued by users.

According to 2021 data, there are approximately 42.5 million people with disabilities in the U.S., accounting for 13% of the total population. This group includes people with difficulties in hearing, vision, cognition, mobility, self-care, or independent living. Looking back at Taiwan, according to Ministry of Health and Welfare statistics, there are nearly 1.2 million people with disabilities, accounting for 4.2% of the total population.

From the perspective of people with disabilities, if a product cannot be used smoothly by them, is that not a form of unfairness? From a business perspective, a product lacking accessibility means directly losing this group of potential users. That's when I realized how important accessibility is and began to seriously learn about it.

What is Accessibility?

"

'Web Accessibility' refers to the design and development of websites, tools, and technologies that can be used by people with disabilities. More specifically, this means users can: perceive, understand, navigate, and interact with the web, and contribute to web content.

Many accessibility features not only benefit users with disabilities but also bring better usability and inclusivity to all users. Taking 'high contrast colors' as an example, it not only helps users with poor vision but is also beneficial in other scenarios, such as using a phone in bright sunlight or operating a device in a dimly lit room, improving readability and visibility, reducing eye strain, and thereby enhancing overall clarity and efficiency.

Key Principles

1. Perceivable

   Information and user interfaces must be perceivable in some form by all users. That is, regardless of the sensory or assistive tools used, users should be able to receive the content.

2. Operable

   All users should be able to operate the interface and navigate. For example, websites must support keyboard operation, not just rely on a mouse, ensuring everyone can use the functions smoothly.

3. Understandable

   Information content and interface interaction methods should be easy to understand. For example, the system should assist in reading content, providing summaries to help users with cognitive disabilities understand the page.

4. Robust

   Content must have good compatibility, be correctly parsed and presented by various user agents and assistive technologies, ensuring the system has cross-platform and future scalability.

Four Best Practices for Accessibility

The following are four key points to pay special attention to during the implementation phase, all referencing the WCAG (Web Content Accessibility Guidelines) standards. We will also focus on strengthening and implementing these aspects in the subsequent development of design system components.

Color Contrast

Providing sufficient contrast ensures users can clearly see text and image content. Especially when text is placed on images, it's essential to ensure enough contrast between the two to maintain good readability.

Take the following image as an example, the color contrast at the top is 1.61:1, while the bottom meets WCAG's 8.39:1, clearly showing that the text at the bottom is easier to read.

Semantic Tags

Semantic tags refer to using HTML tags to describe webpage content, allowing browsers and screen readers to better understand the webpage's content. For accessible design, try to use <header>, <nav>, <main>, <footer> to wrap content, mainly because if <div> or <span> is used to wrap content, screen readers cannot determine the meaning of these elements.

Accessibility Tree

In the general browser rendering process, the browser first parses the webpage markup language (e.g., HTML), builds a DOM tree (Document Object Model), which contains all elements, attributes, and text nodes on the page. At the same time, the browser also parses CSS to generate CSSOM. The DOM and CSSOM combine to produce the Render Tree for layout, then go through the layout and paint steps, finally displaying on the screen.

Running "parallel" to this process is the Accessibility Tree: the browser builds this tree based on the DOM structure, ARIA attributes, and computed styles, providing it to assistive technologies like screen readers. Through the Accessibility Tree, people with disabilities can perceive, understand, and operate our website content.

Accessibility API

When we want to expose the semantics, name, and state of a component to the Accessibility Tree, we need to use the Accessibility API provided by the browser/operating system. Each exposed node is wrapped into an Accessible Object, with the four most common attributes as follows:

Example Code

1. Custom Button Component Role (Role)

   <!-- div originally has no semantics, need to add role and tabindex -->
   <div role="button" tabindex="0">Click me</div>

2. Provide Name (Name)

   <!-- Through label binding -->
   <label for="search">Search:</label>
   <input id="search" type="text" />
   
   <!-- Or use aria-label to specify directly -->
   <input type="text" aria-label="Search keywords" />

3. Custom Checkbox State (State)

   <div role="checkbox"
       aria-checked="false"
       tabindex="0">
     Subscribe to newsletter
   </div>

   Note: The native <input type="checkbox"> already has built-in accessibility information, generally no need to add aria-checked.

4. Additional Description (Description)

   <label for="username">Username:</label>
   <input id="username"
         type="text"
         aria-describedby="usernameHelp" />
   
   <p id="usernameHelp">
     Username must contain 6–12 characters and cannot contain special symbols.
   </p>

If you want to learn more about the Accessibility API, you can refer to WICG AOM Explainer.

Keyboard Focus

Keyboard focus is the element currently receiving keyboard input in the browser. When users navigate a website with a keyboard, focus is like their cursor; all interactive components must be accessible via keyboard operations (e.g., Enter, Space, Tab keys). Additionally, the focus movement order should follow the DOM order from top to bottom, left to right, ensuring a smooth user experience.

Another point to note: when a user clicks a button to open a Modal window, the keyboard focus should immediately move into the Modal; when closing the Modal, the focus should return to the original button. Subsequent articles will implement related components to perfect this focus management process.

Accessibility Testing Tools

1. VoiceOver - macOS built-in screen reader
2. NVDA - Windows-supported screen reader
3. TalkBack - Android-supported screen reader

Further Reading

1. W3
2. Saleforce
3. WebAIM
4. MDN
5. Cloudscape.design
6. Accessibility Tree
7. WICG