Developing a universal checkout experience requires the checkout to be truly available for everyone. From vision impairment to motor limitability to photosensitivity, it’s critical that content online can work for everyone. Accessibility is more than just a list of checkboxes, but a paradigm of thinking on how to design proper human-facing software that makes the experience easier for all.
Making an accessible front-end, it’s important to consider what accessibility (often abbreviated to a11y) means. The first place to start is the Web Content Accessibility Guidelines (WCAG). Currently on 2.1, it covers what is recommended to make context more accommodating for a range of people with disabilities. Complying with WCAG 2.1 is often a legal requirement in many countries as well. WCAG provides a list of recommendations and examples on how to make many components accessible in terms of style, operations, and uniformity. It breaks recommendations into three ratings, A, AA, and AAA. The minimum achievement should be AA, with as many AAA compliances as possible, though that isn’t always possible.
To be accessible means to cover a wide range of web usages. The first thought may be to check that context works for people with blindness. But consideration should also be given to people with low vision, or limited movement, or cognitive limitations. Although it may be difficult to accommodate the needs of every user, working to expand content availability to as many as possible helps all users. Creating strong contrast between text and background for users with color blindness, for instance, makes it easier for all sighted people to read. And adding better keyboard control for people with limited movement allows all users to navigate context more easily.
Looking at the WCAG recommendations can be daunting to just get started. It’s useful to start with focusing on one aspect at a time, especially if there is already a large existing codebase. Start with automated tools. For developing front-end typescript code, the best tool is easily tslint-react-a11y. Adding this to a repository and running the linting tool goes a long way of cleaning some basic a11y issues, and more importantly, enforcing better quality in the future. Some highlights that tslint-react-a11y checks for is ensuring that all images have alt text and elements have proper ARIA roles and properties (indicators to text-to-speech readers on how to interpret an element).
The next step to focus on would be color contrast. Color contrast largely falls under Design, but it is important for front-end engineers as well to check for at least a 4.5:1 contrast ratio between text and background. The easiest tool to check the contrast ratio is webaim’s Color Contrast Checker.
But another tool that has proved very useful is Color Oracle, which provides an overlay of different color-blindness simulated filters to check live displays.
The best way to set up content to be accessible is to not attempt to reinvent everything. Particularly for text-to-speech, there are many cases that are easily missed when using a custom component. Using standard components like <input type=”radio”> already have a lot of support built in natively. It is especially tempting to create a custom component when making a uniquely designed radio button. But doing so often breaks a11y functionality. It is far better to use good css knowledge to turn a standard radio button to look unique than to build a unique functionally similar component from the ground up. This also has the benefit of keeping tech debt much lower, as this paradigm forces code bases to stay lean.
Along the same mentality, keeping the code base consistent goes a long way. For having proper color contrast ratios, keeping a central place of colors used can help check track. This also led to a reduction of colors maintained, instead of having many slightly different colors used in different services. So not only did simplifying lead to better a11y, it lead to a more crisp, clean product.
This is only meant to serve as an introduction and first steps look at how to improve a11y for content. There are many other aspects to consider such as making sure dynamic changes are reported properly using ARIA-live regions or ensuring any flashing content minimizes the risk of provoking seizures. It is important to continuously learn new ways to be more accessible. The best resource would be The A11Y Project, as it has a lot of great information. Another great resource is webaim, as it provides a lot of examples on how to properly use common components. And finally, it is good to check across several screen readers, as they may have slightly different behaviors. The most popular are Mac’s VoiceOver and NVDA for Windows.