Planning for Accessibility
Making the case for accessibility planning to everyone in the start:
- It increases its potential audience by making it easier to find, access, and use.
- It gives an edge over competitors, since people who struggled with an inaccessible experience will prefer you. This includes better translations.
- It can cut costs and resource drain otherwise spent dealing with difficulties customers may face. For example, can make more transactions without needing to talk to customer service.
- accessibility standards may be required be law for some sectors in certain countries. Not meeting them can get you sued.
Building Your Team #
Everyone whose decisions affect a site's design has a role to play in accessibility.
- Helps make accessibility a company-wide practice and requirement, so it's not just a few people working on it and dealing other bad decisions from others.
- Understand and measure the specific benefits - saved costs, legal issues, operational changes. Knows which ones to prioritize.
Professional Development #
- Outside experts can help, but there's many blog/book/research based resources to use too.
- Can get consulting work on it specifically for your company
- Will take time from other work, and time to get used to, but the improvement itself is rapid.
Scoping the Project #
Ask these questions early on, and keep a written (not in stone) record of their answers throughout development. Helps ensure the accessibility needs aren't forgotten over time - no ambiguity and shows their importance.
- Product's purpose?
- Target audience, and their needs/restrictions?
- What does the product help people do?
- What's your product's experience?
- How can accessibility be used in production?
- What platforms, browsers, OSs, and assistive technologies should be tested on?
Ally is a practice, not a budget item. Training for it may cost more time or money initially though. Consider all possible costs.
Limited budget? Aim for the cheapest options that can reach the widest audience. Sometimes a simpler interface without complex interactions is the better choice, in this regard.
Research helps uncover motivations and habits for using your site, looking into audience needs (such as impairments). Helps make more informed decisions on ally and what to prioritize.
Online research is good for tight budgets, and also makes including those with disabilities as part of the test groups. However face-to-face research lets you see reactions with the full context of environment, needs, and behavior. More accurate reporting and easier to follow up on important topics. It also catches things users might not mention since they're "normal," like how they hold/use their mobile device.
Good to have people in a range of different roles involved with the research, can notice a wider variety of important details.
It's harder to including people with disabilities into testing, but it's important to do it anyway. Brings important accessibility concerns to light much faster, makes them harder to ignore. Look at people with disabilities as individuals, don't assume their experiences are all the same - treat them the same as you would anyone else. Separate what the user needs from what technology is needed.
Make sure research data is quantitative, easier to get meaningful patterns from it.
Production and Development #
Your tech stack matters. Know what accessibility benefits and drawbacks any tool or framework brings with it - make sure they had accessibility as a priority. The Content Management System (CMS) also matters a lot, since it directly affects how accessible output content is.
Testing on Devices #
Remember that some assistive tech will be part of your budget. Most are inexpensive or even free.
Watch out for the "gotchas" of last-minute changes that can't be checked for accessibility before being launched. Test before and after to avoid last-minute mistakes like this popping up.
Good way to prevent these? Get an accessibility policy! These should be informed by (your) research. It can be a formal document, set of standards, or casual outline of intentions. As long as it:
- Helps the company understand accessibility importance
- Standardize accessibility approach
- Prioritize user groups when needed
- Are clear and easy to understand, for multiple roles
- Hierarchy of primary, secondary, etc needs
- Testable - how to test to meet all the above (such as Web Content Accessibility Guidelines 2.0 criteria)
Making this public is optional, but can show the public your commitment and what to expect.