Today is Global Accessibility Awareness Day (GAAD), a day to raise awareness about accessibility and encourage development teams to make accessibility part of their practice. At Rangle, this is something that we are striving to do. We have helped several of our clients build accessibly, but it still represents a competing priority for many software projects. What developers, scrum masters and product owners should know is that like any other new practice, the initial cost incurred while ramping up ultimately saves time and leads to a more robust outcome.
While accessibility has become a higher profile consideration over the years, and even law in parts of the world, many development teams still aren't sure what they need to do to make their app accessible. The web is also a much different landscape than it was in 2011 when GAAD was founded. More things are possible, complex JavaScript applications are everywhere, and the dark side of the flexibility the modern web provides is that it's very easy to break the standards that were designed with accessibility in mind. For that reason, it's even more important to consider accessibility before diving into building an Angular or React project.
To get you started, we've put together some accessibility considerations for building single page JavaScript applications.
Tips for Devs
Don't Reinvent HTML
Building components are a core part of Angular and React development, and your options for creating custom components are vast. Because everything is built in JavaScript, any part of your component can be interactive and respond to a variety of user events. One important piece of accessible component design is using natively interactive HTML elements wherever possible. <div> tags are not meant to respond to click events, but both <a> tags and <button> tags are. Going further, <a> tags are meant for navigation, whereas <button> are meant for actions.
Since you can use CSS to override browser-default styles for both of these elements, you should use them whenever possible to ensure that your page behaves predictably to users who rely on assistive technology. If you find that what you're building looks more like a <div>, talk to your designer about making interactive design elements more clear while you're at it!
Augment Your State Changes
By design, single page applications change views, data, and whole pages seamlessly. This is fine for users who rely on their eyes and their mouse to see and interact with changes, but it can be disruptive to users who rely on a keyboard and assistive technology. When developing, think about changes in your application state and ask yourself two things: Is the user's focus where it needs to be after this change occurs, and can the user perceive that change has occurred?
Forms are a great test case for these considerations. Consider using WAI-ARIA with your inline validation messages so all users know about the validity of your form when they fill it out, and think about where the keyboard focus should be set once a form has been submitted successfully or unsuccessfully. Your state changes are integral to the functioning of your application, and they should be perceivable to as many users as possible.
Tips for Design
Design Explicitly
There are a variety of specific design rules for accessibility, but a good general principle is to design explicitly. Minimalist approaches can produce beautiful pages, but design shorthand can sometimes compromise the clarity and accessibility of a design. Designing explicitly is often a usability win for all users. For instance, research shows that forms which are designed for clarity and scanability are actually more likely to convert. Many of the patterns you should use to improve clarity - persistent form labels, using more than color to convey information, and providing hints where needed - are all accessibility wins.
Test Inclusively
User-validated design is the best design, and it's entirely possible to test your designs for accessibility with real users. If you can't find colorblind users, consider putting your designs through a colorblindness filter and then testing them. Likewise, you can check the size and clarity of your font choice by asking users to look at a page with and without their glasses. Microsoft's Inclusive Design toolkit is a great resource that points out that "users with disabilities" is a much broader category than people who rely on assistive technology 100% of the time.
Tips for Everyone
Everyone should advocate for accessibility as a smart business practice. You may have heard the statistic that people with disabilities would represent the largest minority in the United States if they were formally recognized, but accessible practices can benefit all users. Applications that don't auto-play videos are easier to use for people with cognitive disabilities, but they'll also be more friendly to users on slow connections or old mobile devices. Video transcripts help the hearing impaired, but also anyone in a public place without headphones. In this way, accessible development practices are about ensuring the best possible user experience for the broadest number of people. Everyone wins, and it’s the right thing to do.
This Accessibility Awareness Day, talk to your team about building accessibility into your process, as part of your definition of done. The whole web will thank you for it.