Imagine, for a moment, that you are a computer user with a disability. You might have impaired vision or hearing, or limited motor control. How do you go about using your computer? How would the way that you use technology be affected if you didn’t see your laptop screen, or didn’t hear notification sounds?
Now, consider your website, product, app, et cetera. How would a blind user interact with it? Is it usable by someone working with a single-switch assistive device? How does it respond when someone increases their system font size by 200%, or inverts their display colors? These users aren’t uncommon- they represent a substantial share of the market. 19 percent of the population reports having a disability. When creating software, ensuring its accessibility isn’t just the right thing to do- it’s the smart thing to do.
What software stakeholders need to know
The first step to building any product, including accessible software, is being aware of your users’ requirements. User research is one of the best ways to gain an understanding of what accessibility means in your specific product space, but it can be expensive. An alternative to conducting a full user study is to take advantage of existing literature and guidelines for accessible software. Unless you represent a government organization (more on that case below), it’s unlikely that you’re required to comply with Section 508, the (limited and outdated) law around web accessibility for government organizations. However, there are more recent and broadly applicable resources that can give you an idea of what to look out for. I think that the Web Content Accessibility Guidelines do a great job of boiling down some of the core tenets that people building accessible software should consider:
- Perceivable – Information and user interface components must be presentable to users in ways they can perceive.
- Operable – User interface components and navigation must be operable.
- Understandable – Information and the operation of user interface must be understandable.
- Robust – Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.
So, is this going to be expensive?
It depends on your stage of development. Just getting started with design and planning? Probably not! The guidelines above should look familiar to anyone working in product development. Accessible design happens to have a large overlap with great design, which means that with a little bit of mindfulness in planning, building in accessibility shouldn’t add a great deal of expense to the development process. There are also existing accessibility toolkits for most of the major platforms that developers can leverage to make building accessible software even easier- stay tuned for a follow-up Spin post on tools for developers!
If your project is already deep in development, there may be some redesign and refactoring required to reach your accessibility goals. In this case, the best course of action is to take small steps toward general improvement (assuming that you are not working under a compliance deadline, in which case it may be time to consider hiring an external vendor that specializes in accessibility improvements). Maybe this iteration you can ensure that all of your images have alt-text, and next sprint you can start evaluating the product’s usability with keyboard input.
And if I need to comply with federal accessibility guidelines?
Federal government services are required to comply with the Rehabilitation Act of Section 508, Electronic and Information Technology Accessibility Standards. Section 508 is outdated and very limited in technology scope- consider it a bare minimum for government services, not something to strive for. The standards are likely to be updated in 2016, and the proposed update is currently available for public review. It is intended to be more technology-agnostic than the existing 508 standards, and covers a broader scope of new technologies. If you’re interested in staying ahead of the game, and in providing a better experience for your users, consider using the currently-in-development U.S. Web Design Standards, a collection of open-source UI components and styles that comply with both Section 508 and WCAG 2.0.
Where can I go for more information?
Talk to people! Check in with your team about their existing experience developing accessible applications. If you have access to usability specialists, leverage their knowledge as it applies to accessibility. As mentioned above, it’s always a good idea to consult with real users whenever possible- conduct user research and usability studies, and make a point to include diverse subjects. There also exist vendors who can perform external accessibility evaluations and recommendations as a service, which can be a good solution for organizations that are not able to dedicate internal resources to accessibility and for bringing products are already in development up to speed. Finally, consider dedicating development time to exploring the wealth of resources and toolkits available online, and remember that the knowledge your team gains will continue to be valuable in future projects. A little bit of study will go a long way in accessibility.
Further Reading
General Accessibility Guidelines and Resources
Government Services
- Section 508 Website
- Information for IT Vendors on 508 Compliance
- Guide to the Section 508 Standards
- Section 508 Electronic and Information Technology Accessibility Standards – Full Text