Once you’ve developed skills at following WCAG guidelines and making accessible content, it may seem like you can rely on testing materials yourself. While testing skills are invaluable to developing accessible content, involving people with disabilities yields better results. This article will discuss why you should include people with disabilities in development and how best to do so.
Why include people with disabilities?
Developers need others to test their content. Having others test content allows them to see if their content is intuitive by seeing how easily others use it. Digital content often involves many choices and inputs from users. For this reason, developers are unlikely to think of all possible combinations of inputs. Having others test their content helps them find bugs.
The same concept applies to accessibility. While developers can learn about accessibility and how to use assistive technology, nothing beats an authentic experience. You built the site and so already understand how to navigate it. Someone who did not might find it more difficult, especially using assistive technology.
Even if a developer has accessibility needs, their content needs to be accessible to people with a wide range of needs. For example, the needs of people with low vision vary widely depending on the nature of their impairment. People with disabilities can also share if they feel welcome in your digital content based on how people with disabilities are represented.
When people with disabilities spend their time helping you develop and test your content, they provide skilled labor that benefits your organization. You should compensate them for their time and contributions. Due to the electronic curb cut effect, their input is helpful beyond users with disabilities and helps you avoid lawsuits. Your investment in their time will pay off, eventually.
Development
Incorporating accessibility into a project from the beginning is the most efficient approach. Rather than going back and fixing accessibility problems, developers make sure they are thinking about accessibility from the start. This also helps developers avoid going down a path that leads to a significant amount of work later.
The beginning of development is also a great time to involve people with disabilities. They can support developers in avoiding pitfalls. For example, suppose you are working on a strict deadline and want to make a drag-and-drop interaction into your content. Suppose you found out before building that drag-and-drop interactions pose accessibility challenges. In that case, you know to either choose an alternative or ensure you have time to address the accessibility of the feature before your deadline.
Users with disabilities can also help developers think of ideas for a universal design that goes beyond compliance to make your content intuitive and easy for everyone to use. Most accessibility guidelines make content easier for everyone to use.
The World Wide Web Consortium, which wrote and continues updating WCAG, has a guide on involving users with disabilities in development. Review the manual for more ideas and resources on including people with disabilities in development.
Initial testing
Once you’ve drafted content, do initial testing yourself. The internet is full of free testing tools for web content and apps. If creating documents, Word, PowerPoint, and Adobe Pro, all have built-in automated testing features.
Next, check things you know automated testing will not catch. For example, color contrast requires manual checking, as does reading order. Automated checkers cannot check for plain language or if your headings make logical sense.
While automated checking, you need to be careful about the shortcomings of automated checking. Word and PowerPoint only detect whether a photo has alt text or if the alt text makes sense. The software often puts the name of the image file in the alt text field. The file name likely will not make good alt text. Try navigating a site with only your keyboard and with a screen reader.
User testing
Once you’ve addressed all accessibility issues to the best of your knowledge, share your content with people with disabilities. Get your content as close to fully accessible as you can. This best uses your testers’ time and allows them to focus on the trickiest features. For safety reasons, one guideline you should make certain you meet before sharing with testers is avoiding features that can cause seizures.
For a site or an app, try watching people use it. Assure them if they get stuck or confused, that is not about them. It means the site needs improvement. Like most accessibility features, giving your site clear and intuitive navigation helps all users.
People who use a screen reader or navigate only with this keyboard will give you an authentic look at how easy your site is for them. People with a screen reader may report needing help to figure out what to do. Focus order should be clearer, or alt text should make sense. Keyboard-only users might report running into keyboard traps they did not encounter during your testing.
The World Wide Web Consortium has a guide on involving users in testing. You can find resources for different approaches in their guide.
Conclusion
Your organization, users with disabilities, and all others benefit from involving people with disabilities in developing and testing digital content. Involving people with disabilities in early development is more efficient than waiting to include them post-development. This investment, including compensation for their time and skills, will benefit your organization long-term.
Comments