With the Web Accessibility National Transition Strategy now well underway, a common question that comes up when speaking with clients is when and how to factor accessibility into the redevelopment or design of a website.
It can be hard to think about accessibility when still in the planning or scoping stage, but it is crucial that all team members are conscious of accessibility and how it will impact the final product. As we have said before, it is more difficult to retro-fit accessible solutions once a website has progressed too far down the development path. To reduce these difficulties and provide guidance, we have put together the following tips for when and how to best factor accessibility in to the redevelopment or design of a website:
Ensure in all initial planning, budgeting and scheduling that accessibility is considered.
Key questions to think about include:
- Is there time between production and launch for a final accessibility review to be conducted? And, more importantly, is there time allowed for any changes to be made?
- If the project is to be built in phases, is there sufficient time and budget for an accessibility review to be conducted in-between phases?
- How will the learnings from any accessibility reviews be applied? Who will be responsible for following up any review results?
- Is the selected developer up-to-date with WCAG 2.0 accessibility standards and techniques? If you’re not sure, ask them for examples of work and proof of accessible products they have created recently.
- Will the developer perform any revisions to the site as part of the initial contract? We are seeing a rise in agreements where developers will make changes if the finished product is not accessible. This saves the hassle and cost blow-outs that can occur if changes are required (and they probably will be).
Think about accessibility when designing basic interactions and strategy.
Some areas for caution and research include:
- Complex site layouts. These are frequently cited as one of the biggest pain points for users with accessibility requirements. Try, where possible, to keep your layout and structure as simple as possible. This is something that can prove difficult to retrofit.
- Large drop-down mega menus. These are not typically accessible by default and require some additional planning and implementation in order to be fully navigable by keyboard.
- Sound site structure. Having a clear, logical HTML structure is integral to accessibility and also difficult to retro-fit, so it is best to define any site maps and structure in the most logical way possible, and ensure that the CMS or development process supports this structure. This leads on to the point below…
- Will your selected CMS support accessibility. How does it create alt text for images? Does it generate valid code? Does it apply correct heading levels?
- How much complexity? Be conscious of complex interactions, forms or dynamic elements that may require heavy use of JavaScript; whilst most users with accessibility requirements don’t turn JavaScript off, JavaScript can negatively interact with screen readers and other assistive technologies. The simpler the page functions, the easier it is to be accessible. If complex interactions are required, ensure your developer has a sound understanding of the WAI-ARIA principles.
- Colour contrast. This is often the biggest barrier to the practical implementation of accessibility, particularly in branding palettes and visual style guides. This could be avoided by testing colour contrast levels when any visual design rules are created or updated. Use the Vision Australia Colour Contrast Analyser to check your colour combinations.
Begin formalised accessibility testing at the earliest possible stage.
- Typically, this is once actual production and development has started. A thorough accessibility review requires actual code to inspect, so it is not effective to test wireframes or most prototypes. By testing early and often in the development process, accessibility problems are easier to solve and are much more manageable.
By keeping these points in mind, implementing an accessible solution can be made much simpler. To sum up, scoping accessibility in to initial planning, scheduling, strategy and development, and testing at an appropriate time can be the key differentiator between a project running smoothly, and a project meeting large hurdles.