Shift Left: Keeping Accessibility in Mind Early in the Process

While the software development lifecycle is a familiar concept for developers, portions of the cycle are also part of a designer's process:

1. Plan how the product or creative will look and behave, in different sprints where applicable
2. Design the look and feel of the product or creative
3. Develop or implement the product or creative
4. Test the product or creative with users
5. Maintain the product or creative

Based on the steps in the cycle, testing seems to only be done at the fourth stage. Doing the testing at only this stage creates a lot of additional work to fix elements of the product or creative that could have been caught earlier. This is often costly for the IT provider, including personnel and time resources.

When the testing or quality assessing the product or creative is shifted left, many important elements can be caught and corrected before resources are allocated to that stage. 

This site provides some examples of where digital accessibility can be shifted left.

Useful resources for keeping accessibility in mind

This site will be referencing the following digital accessibility resources. IT providers are encouraged to involve people with disabilities in testing and quality assessment. Oftentimes, their point of view provides innovative solutions that can improve the quality and performance of products and creatives for everyone.

• Web Content Accessibility Guidelines (WCAG)
  What success criteria would need to be addressed?
• Voluntary Product Accessibility Template (VPAT)
  The Information Technology Industry Council maintains the rubrics affecting US, European, and international interests when procuring IT.
• IBM Equal Access Toolkit
  IBM provides a great example of how to implement best practices throughout the process. You can modify it for your own organization or team.

Plan

Whether the product or creative is already designed/developed, you can look at what changes need to be planned out at different intervals. What might take more time to be adjusted? For example, if you are converting a desktop version of the layout to a mobile version, what concerns will need to be raised with the designers/developers? Also, what feedback have people given in surveys, focus groups, or individual testing? More time, or sprints, are planned out for specific elements as needed.

See how IBM sets up projects, releases, and sprints.

Design

Some visual or usability aspects can be reviewed during the design process. These accessibility concerns include color choice, font size/choice, and layout spacing. Checking these now reduces the time to correct colors, fonts, etc. afterward.

Example success criteria from WCAG:

• 1.3.3 Sensory Characteristics: None of the instructions or notifications require a specific sense
• 1.4.3 Contrast (Minimum): Foreground and background colors contrast to improve legibility
• 1.4.5 Images of Text: No text is on images, or complex images are described in full nearby or in a link for more information
• 3.2.3 Consistent Navigation: People know what navigation to expect throughout the use of the IT

See how IBM reviews content, user experiences, and visuals to create an inclusive product or service.

Develop

Some interactivity may need to be addressed. For example, how can a keyboard access all the options? How can a user tell where they are on an application? How can a user stop some interactive element from becoming too distracting?

Example success criteria from WCAG:

• 1.3.1 Info and Relationships: Proper semantics are used to identify headings, lists, tables, etc.
• 2.1.1 Keyboard: All operations can be done with a keyboard
• 3.1.1 Language of Page: Assistive technology can read digital content in the proper language
• 4.1.2 Name, Role, Value: Assistive technology knows what each input control is, what it does, and its status

See how IBM reviews keyboard-only access, error messages, text and non-text equivalents for visuals, and accessible forms and labels.

Test

Shifting left does not mean testing ends at the development stage. It does reduce a considerable amount of resources that are needed at the testing stage. Since several success criteria can be addressed through best practices, the testing stage can focus on the user experience and other elements not typically caught.

Example success criteria from WCAG:

• 1.1.1 Non-text Content: Does the visual's text equivalent make sense in context?
• 1.4.1 Use of Color: Does the alternative to color provide equivalent meaning?
• 1.4.4 Resize Text: Is it still legible if the text has to be adjusted?
• 2.1.2 No Keyboard Trap: Is navigation simple and expected?
• 2.2.1 Timing Adjustable: Do people have enough time or the ability to adjust time?
• 2.4.2 Page Titled: Do people know where they are?
• 2.4.4 Link Purpose (In Context): Do people know where they are going?
• 2.4.7 Focus Visible: Do people know where they are on any screen?
• 3.2.4 Consistent Identification: Does everything make expected sense?
• 3.3.2 Labels or Instructions: Do people know how to respond?
• 3.3.4 Error Prevention (Legal, Financial, Data): Are major mistakes avoidable?

See how IBM reviews its products using automated and manual tests.

Maintain

Even when shifting left, not all issues can be addressed immediately. This is why planning is and progress are important. Organizations should review their products and creatives using appropriate success criteria on the VPAT as well as work with people with disabilities. Then create a roadmap that includes those elements that could not be completed at this time or during this sprint. Note that even when everything is accessible, technology can change. So these should be reviewed regularly.

Information technology is like plants. They need regular maintenance to grow and improve. You don't feed plants once and expect them to reach their full height.

Completed VPATs are Accessibility Conformance Reports (ACRs). Use these regularly.