Agile is the most widely used methodology, improving project quality and reducing development costs. With the goal of delivering high quality products efficiently, it’s surprising to learn that many organisations still adopt a Waterfall approach to accessibility testing, leaving it to the end of the project lifecycle.
Considering accessibility late in development can lead to an unnecessary waste of time, money, effort and resources to retroactively fix issues and achieve compliance. This time could be spent improving the product and implementing new features instead.
Let’s explore some reasons why accessibility is often not started early enough in Agile development:
- Lack of understanding about why it is necessary. If the phrases “blind people aren’t going to use my mobile app”, “bright yellow text on my white background looks great” or “nobody needs a keyboard to browse my website when they have a mouse” are familiar to you, there may be a few things you can learn from this article.
- Misconception that inclusive features will ‘hold up’ higher priority items. Accessibility can and should be integrated into every stage of your development process. This is especially true when working in Agile sprints that involve everyone on the team.
- It is seen as a ‘nice to have’ or ‘easy fix’ at the end of the project. The reality is much different and often surprising for the entire Agile team when the amount of work involved in remediating accessibility defects becomes clear.
The good news is Agile and accessibility go hand-in-hand. Whilst it’s highly recommended to review your project against all of the Web Content Accessibility Guidelines (WCAG) 2.0 to Level AA at minimum, here are some quick tips to save time and money by ensuring your Agile accessibility processes are optimised from the start.
Agile teams have accessibility responsibility
Everyone on your Agile team needs to play their part to develop an accessible experience for the end user. Alongside the moral and ethical reasons for making your product inclusive, there are clear corporate and legal reasons, such as avoiding brand damage and potentially expensive lawsuits due to inaccessibility. Web Accessibility Consultant, Karl Groves, has put together an extensive list of Web Accessibility-Related Litigation and Settlements from 2000-2015, including high profile cases with the NBA, Reebok, Harvard, MIT, Bank of America and Toys R Us.
For product owners, developers, designers, content authors and testers, there are a few accessibility techniques to keep in mind whilst working in an Agile mindset:
Product owners
- Accessibility requirements start with you. It is your role as the product owner to understand your company’s responsibilities and accessibility compliance requirements, which needs significant buy-in from the start. This requires research around accessibility guidelines and clear communication of your expectations to teams working on producing an inclusive product.
- Create user stories for diverse personas. User stories should include customer journeys with diverse web users in mind. This may include (and is not limited to) users with auditory, cognitive, physical, speech and visual disabilities using with your product, as well as people with age-related impairment, situational limitations or temporary impairment. It’s important to have testable acceptance criteria included as part of this step.
- Embed accessibility into your acceptance criteria. It is unlikely these days that any website or app doesn’t need some form of accessibility testing. Work with your team to ensure inclusive design is embedded in your showcases for acceptance before any set of stories are marked as done.
Developers
- Use WCAG 2.0-compliant code. In web-based projects, using scripting, structure, labels, roles and values in line with WCAG 2.0 requirements ensures assistive technology users can effectively browse your platform without experiencing issues. This approach is based on using simple semantics and is likely to produce cleaner code, leading to fewer defects in later sprints. In a pair programming scenario, drivers can utilise compliant coding techniques, whilst observers can review the code to ensure accessibility compliance. WCAG 2.0 Guideline 4.1 Compatible provides more information on maximising compatibility with assistive technology.
- Ensure your product is navigable for non-mouse users. Not everyone is going to browse your digital platform using a mouse. Screen reader users or people with mobility-related disabilities may use keyboard controls on their desktop, specific gestures on mobile devices, or an input device as their preferred navigation tool. Save yourself a lot of rework by ensuring non-pointer specific controls are considered from the start. WCAG 2.0 Guideline 2.1 Keyboard Accessible covers navigational accessibility in more detail.
Designers
- Use accessible colour contrast combinations. If your style guide isn’t accessible from the get-go, it can be extremely difficult to fix later in development. This becomes a serious problem when your product has gone live with menu items which are hard to see, buttons which are difficult to activate, and text-based content which is hard to read because your users can’t perceive it. Agile designers should use colours which allow people with colour blindness or visual impairment to easily use the platform. WCAG 2.0 Guideline 1.4 Distinguishable outlines how to achieve accessibility between background and foreground elements.
- Avoid images of text. Using an image file like a JPG or GIF containing text content can make it difficult or impossible for users to customise the presentation of text according to their preferences. Save yourself (and your team) time better spent on other aspects of your platform by applying plain-text as a foreground element, with your image applied in the background. Check out WCAG 2.0 Guideline 1.4 Distinguishable for more on separating background and foreground elements.
Content authors
- Provide alternative text on images. Screen reader users require access to visual content, particularly images, on your digital platform. This is usually implemented via an alternative text attribute, an ARIA label or long description attribute to describe image content for non-visual users. If you forget to implement this from the start, it can be a time-consuming process to go back and fix it in later sprints. WCAG 2.0 Guideline 1.1 Text Alternatives provides further direction on creating accessible non-text content.
- Ensure that links have meaningful names. People who are blind or visually impaired may use a screen reader to navigate your platform in a way that is comfortable for them. Sometimes this involves jumping between links using the tab key, or using an input device which performs a similar function. If your links are labelled “click here” or “read more”, screen reader users will be presented with a long list of meaningless information. Agile content creators should ensure meaningful link text is used to help everyone understand where links will take them based on their name alone. WCAG 2.0 Guideline 2.4 Navigable further outlines why accessible link names are necessary.
Accessibility testers
- Gain a solid understanding of accessibility guidelines. It’s essential for testers to understand WCAG 2.0 across Level A, AA and AAA compliance, which includes integration into your session sheets and test plan. Knowing how to spot defects is just the beginning, whilst understanding and articulating how inaccessibility directly impacts the experience of people with disabilities is an entirely different skillset which can be mastered.
- Be part of the team from day one. Accessibility testers and consultants should be available from the start of the project to guide Agile developers, designers and content authors on inclusive best practices. Continuous testing can provide accessibility assessments across each phase of the project using different browser and device combinations. This in turn can be used to produce more accurate user stories, tests and features over the project lifecycle.
Conclusion
Using the above tips, it should be clear that accessibility isn’t a barrier to Agile development – it’s an opportunity to make your platform usable and inclusive for as many people as possible, increasing your potential customer base.
Using complex, highly customised, over-engineered solutions to problems which can otherwise be solved in a simple manner can lead to accessibility issues, as well as costing and timing implications on your Agile workflow.
Quality assurance should be used to validate features you know have been implemented correctly from the start. Why scramble to fix accessibility defects post-launch after people complain, or when you’re facing a lawsuit for inaccessibility? It’s a much more rewarding process for Agile teams to learn how their work has enhanced the lives of people with disabilities after testing, rather than discovering their hard work needs to be re-done to achieve WCAG 2.0 compliance.
Planit can assist at any point during your product journey with our accessibility consultancy, testing expertise and provision of a formalised statement. We also have extensive Agile expertise to mitigate risks and ensure your functional and non-functional requirements are addressed within each iteration.
Check out our Accessibility Testing and Agile Testing pages to learn how we can help you.