Accessibility is a hot topic, and everyone is pushing to make their products more accessible. Whether you’re looking at it through a design, technical, or managerial lens, the task of taking a product from zero to accessible can be very daunting. We have recently gone through this process on the Inbox team at Hootsuite and want to share some of the knowledge we’ve gained.
Defining Accessibility
The first step is understanding what accessibility means in the context of the web. When people talk about making the web accessible, they are referring to the act of making it more inclusive for those with disabilities. Accessible web content enables everyone to perceive, understand, navigate and interact with it. Web accessibility must take into account a wide range of various disabilities which fall into five categories:
- Motor
- Cognition
- Vision
- Hearing
- Speech
Disabilities may also be temporary or permanent. Permanent disabilities are conditions that impact you for the rest of your life, such as colour blindness, amputation, or hearing loss. Temporary disabilities impact fully-abled people causing them to become impaired for a period of time. Common situations, such as working in a bright environment or having a temporary injury, can impact the way people use our product. The work we do to improve our product’s accessibility has the potential to make everyone’s experience better.
Understanding Who You’re Building For
Now that we understand what accessibility is, we need to dig into how it may impact our users. After all, a key part to building high-quality products is understanding who’s using them. It’s safe to assume that some portion of the user base includes individuals with disabilities.
According to a study in the USA from 2012, 18.7% of the population in America has some form of disability that can impact their experience on the internet. A survey from Princeton in 2011 says that 54% of adults with a disability go online. So, of our ~15 million users at Hootsuite, over 10% (1.5 million) may have some form of disability which could impact their experience with our product. This number grows even more if you consider the number of people that may have temporary disabilities. It’s our job to ensure we know how these disabilities may impact our users, and how we can ensure our product is still usable for them.
Motor Disabilities
Motor disabilities can impact individuals in many different ways so it makes sense that there is a wide range of assistive technology available to help them navigate their computers. Specialized keyboards, eye trackers, and switches are just a few of the possible technologies our users may be leveraging. To ensure our product will work for people with motor disabilities, we must consider how tab and keyboard navigation works. Do all interactive elements have an appropriate focus state? Can disabled users perform the same set of actions with a keyboard that non-disabled users can? Making sure you can answer yes to these questions is a good start.
Cognitive Disabilities
Next there are cognitive disabilities. Cognitive disabilities typically result in difficulties processing information. Building a product with this type of disability in mind is challenging because there is no simple “it has it or it doesn’t” test. The product needs to be easy for users to understand, including the information it provides and how users interact with it. But how do you define easy? Different people find different things “easy”. Simplifying a product too much may result in loss of functionality. Finding a balance between a product that is easy to use but is also useful is difficult. A few of the things we look for is whether the user interaction is simple and consistent across all product areas. We also need to ensure the language we use is plain and concise. Lastly, the UI should be clear of clutter, so as to not overwhelm the user with too many options all at once.
Vision Disabilities
There are several types of vision disabilities. A user with a vision disability may be non-sighted, have low vision, obstructed vision, or vision sensitivities to things such as light and movement. These types of users may rely on assistive technology to describe and interact with the page, or it may be sufficient for them to adjust certain visual settings to increase the size or contrast ratios of the product. When testing our products, we make sure to use a screen reader to ensure all the information and functionality works. We also use a browser extension, such as NoCoffe, to simulate various forms of colour blindness and confirm our products have sufficient colour contrast. Lastly, we test to make sure that the user can enlarge the text on the page by zooming in or a page setting if it’s available.
Hearing Disabilities
Hearing disabilities impact a person’s ability to understand auditory information. Any media which uses sound to convey information must also have a secondary way to get that information across to the user that uses a sense other than hearing. The most common way to accomplish this is with captions. These captions may then be read by the user directly or with the help of other assistive devices.
Speech Disabilities
Lastly, we need to consider speech disabilities. Speech disabilities include the inability to produce speech that is recognizable by other people or software due to things such as volume or clarity. In Hootsuite’s case, users don’t talk to our product unless using some form of assistive technology that recognizes voice commands. This means all we need to ensure our product will work with these assistive technologies. If your product does involve a person talking to it, make sure there’s an alternative form of input available to them, such as text or video.
Tips for Building an Accessible Product
At this point, we understand what accessibility means, the different ways it can impact our users, and different ways we can test our product to make sure it works for them. Even with this knowledge though, the task of building an accessible product can be intimidating if you haven’t done it before. There’s just so many things to consider, where do you even start? We’ve put together seven tips we keep in mind when making our products accessible.
1. Give Yourself Lots of Time
Making complex applications accessible is no easy task. Don’t be fooled into thinking it can be done by fixing a few UI pieces and updating some colors. It takes time to audit each aspect of your website and determine if there are issues. Once you do find some, it takes time to fix them, even more so if it’s an existing product that was built without accessibility in mind. It’s also important to familiarize yourself with how assistive technology is used so that you can check your work. Rushing to make a product accessible inevitably leads to things being missed. Make sure you budget enough time for yourself, especially if you have not done this before.
2. Bake-In Accessibility
Thinking about accessibility right from the start of a product is simpler and less costly than trying to make a product accessible after it has been built. If accessibility issues are caught early, designs can be modified or code can be changed while it is still fresh in people’s minds. If it’s not caught until the product has been released, not only does it take people time to remember why certain decisions were made, but the risk associated with making a change to a live product is greater. Baking accessibility into the early stages of your software development lifecycle can save you time and money down the road.
3. Draw a Line
The work required to make a product accessible never stops. As new features are added, they must be tested to ensure they meet accessibility criteria. If you’re attempting to make an existing product accessible, having to worry about whether or not new features are accessible can cause the task to drag on. This is why it’s important to draw a line. A point in time must be set, after which all new features must be accessible and it is the responsibility of the team creating those features to ensure it. This enables teams to clearly define what the end state is and know when the original task is done.
4. Focus on Focus Order
It’s important to define how the user should navigate around the product. This flow should be intuitive and provide access to all the information and features contained within the product. For non-impaired users, this is pretty easy to do, but it becomes less obvious when you begin to consider users that use assistive technologies. We’ve found that putting together a document which clearly indicates the focus order within the product, and what a screen reader may say, is tremendously valuable. This takes time, but detailed documentation helps ensure consistent understanding of what is expected in the final product. We’ve also found that reviewing this document as a group helped us catch issues with the flow sooner, saving us time in the long run.
5. Work Landmark-By-Landmark
Making an entire product accessible is a huge task. Working landmark-by-landmark is an effective way to break up the work. Landmarks are regions within your product that assistive technology can leverage, allowing users to quickly jump between them. Start by defining the landmarks within your product, then work from one landmark to the next making each accessible. This allows you to have smaller, fully accessible deliverables which can be tested and iterated on quickly.
6. Use Proper HTML Semantics
There are many tools that can be used when making a product accessible. Complex UI components may require the use of aria attributes, custom key event handlers, and hidden DOM elements. Whenever possible, the use of defined HTML elements should be preferred as it gives you many accessibility features for free and allows you to focus on the more complex pieces of your UI.
7. Test with a Screen Reader and Keyboard
When testing your product, make sure to test with both a screen reader and keyboard. Using a screen reader will allow you to verify the various labels and descriptions used in your product, thus testing that the product is still usable by those who are unable to see it clearly. Going through with a keyboard will ensure your product has reasonable focus states and can be used by those that can see, but may just have a hard time navigating by conventional means. Both scenarios are equally important to test as they emulate how users will be using your product in the real world, and help you build empathy for these types of users.
Conclusion
I hope reading this has been informative, either by clearing up what web accessibility is, types of disabilities your users may be impacted by, or providing useful tips for how to make your product accessible. These tips are what we found worked well for us up to this point, but we still have work to do. If you have any tips or tricks that work well for you, please reach out to us on Twitter at @HootsuiteEng or leave a comment.
