Recently I’ve been working quite a few website accessibility reviews and I’ve often found myself thrown into the final testing stage of a web project – everyone is running around, testing the system to breaking point, reporting bugs, finishing content creation and frantically fixing things for launch. It’s a crazy, stressful time for teams and it’s not fun to be the one coming in and announcing “… and here’s the web accessibility problems I found.” thus adding to the workload before launch!

The output of web accessibility testing at this late stage is usually a set of recommendations which involves changing the way something has been implemented (code wise – the bricks and mortar of a site) or the way something has been designed (the interior design of a site). When at the testing phase, design and development is probably nearing its close; layout decisions made, core templates and controls built… but then along comes the web accessibility review and guess what… hold your horses we have some problems – time to revisit those earlier phases.

Whilst reviewing web accessibility is encouraged at any stage, if done too late it’s…

• not good for team morale – time has already been spent creating the site, only to be given a list of rework in order to meet accessibility compliance
• not efficient for the business – increased redesign and development times
• possible you could release a non-compliant site

Web accessibility should be considered at all stages so teams do not have to do complex retrofits and revisit work already considered complete. Make the most of the design and development phases and work iteratively; it isn’t a linear process. Designers and developers will most likely need to work together when a design cannot be completely realised in an accessible way. Get back to the drawing board and have a plan of action and most importantly, fail early so things can be fixed.

Most projects go through the following phases: design, build, test, deploy. We need to see web accessibility considerations happening throughout these processes (with feedback loops for iterations) and an additional phase of governance to ensure content authors are maintaining the level of accessibility on the site and not creating new problems.

Here are some ideas for each phase I would like to see teams consider when approaching web projects…

Design

• Colour and contrast
• Typography, font selection, line height
• Affordance, button design, labels
• Relationships, size, shape, position, direction
• Tone, language, feedback and prompting
• Consistency

Build & Test

• Progressive enhancement
• Flexible and responsive layouts
• Use native HTML behaviours and semantics
• Explicit relationships (WAI-ARIA and HTML5)
• Iterative approach to testing with WCAG 2.0 tools and assistive technologies, which involves the design team

Governance

• Author guides for writing new content to maintain integrity of accessibility attained

So that’s my few pence worth on how to take an integrated approach to accessibility and help minimise rework at the last hurdle. Our industry has done well at ensuring we consider usability along the design and development journey, but somehow web accessibility falls off the radar and we need to ensure it’s put back on our agendas. :)