Test early, test often
When projects follow a waterfall pattern, you might gather requirements, create design mockups, build the functionality, and finally test the results. During testing, Quality Assurance (QA) files bugs for rest of the team to fix errors that could have been solved much earlier on if there had been more collaboration throughout these ‘phases’. This is highly inefficient and can extend the lifetime of a project. Using an agile process can provide quicker feedback loops. But even if you’re working under a waterfall model, it’s more efficient to involve QA at the start of your project rather than waiting until the end. This allows you to bring accessibility bugs to your developers to fix while the functionality is being written. It’s much faster for a programmer to fix a bug the same week they wrote the code rather than months later. If you wait until the end of a project to address accessibility, you risk causing costly re-builds at the 11th hour.
How to include accessibility early
Planning for accessibility should begin as soon as the requirements and discovery phase of a project gets underway — long before the graphic design is completed and before the first line of code is written. We suggest these easy steps to begin addressing accessibility: When a project begins, assign an Accessibility Champion for the project. That person should help the team identify standards and create a testing plan. The testing plan should include the people who will do the testing and the tools they will use. If you don’t know where to begin, we suggest adopting the Web Content Accessibility Guidelines (WCAG) 2.0 as your web accessibility standard. Check out the AInspector Firefox plug-in to help evaluate accessibility. And use resources like WebAIM.org to learn about accessibility or search for answers to problems you encounter. As soon as graphic design and user experience/user interface activities are underway, talk with the designers and developers about whether they have a clear understanding of how they will implement that design in an accessible way. Seek help if the team is unclear. As soon as coding and development begins, hold demo sessions where the developers give a tour of their latest work every 1-2 weeks. Conduct accessibility testing on that draft version and report issues right away. The developers may not always be happy if you find problems, but they would rather hear about it now and get a chance to fix their work now rather than having to re-do their work months later.
Educate developers about accessibility
At Pixo, our developers have training on accessibility. We maintain a list of common violations and developers use accessibility tools to run their code through before their code is accepted. They feel more empowered when they can check their own code themselves rather than having to wait for someone else. Even so, it’s important for an independent person — other than the developer her/himself — to help review accessibility periodically and make sure it gets addressed along the way.
Accessibility boils down to two very important concepts: Structure and Interactivity. These two concepts are related to POUR:
- Perceivable – Is the content perceivable to all of a user’s senses?
- Operable – Can the user perform all of the User Interface (UI) interactions, either on their own or with Assistive Technology (AT)?
- Understandable – Is the content within the user’s understanding?
- Robust – Can the content be interpreted with different user agents and AT, and be extensible to work with future technologies?
POUR comes from the WCAG 2.0, which are the most widely-accepted guidelines for building an accessible website or application. There are numerous automated accessibility tools that will check your site for violations against the WCAG 2.0 guidelines and give you feedback on what violations exist within your code base. It’s important to prepare your developers to understand common violations and the approaches to fixing them, but by doing this, you’re only addressing half of the challenge. Just because your code doesn’t have any accessibility issues doesn’t mean it is accessible. Accessibility is very much about planning and mapping out the user’s experience. When we bring accessibility concerns to our user experience experts at the beginning of a project, we design with accessibility in mind.
Historically, accessibility has been seen as an after thought — something to “fix” right before go-live. That approach causes frustration and makes the cause of accessibility seem antagonistic. It also causes extra cost to rush and repair something late in the game. Incorporating accessibility from Day 1 helps everything fall into place with less pain.