Shifting Left with Accessibility

When accessibility isn’t considered in planning, design, or engineering, it can become difficult and costly to redo. Even more so when decisions are core to a product’s DNA, such as brand colors or creating your whole app in HTML5 Canvas.

We will have the most success when accessibility is shifted left in the Software Development Life Cycle (SDLC), to earlier parts of the process. From implementation (engineering), to design. From design, to planning.

The Agile diagram of the SDLC is circular as we iterate much faster on product development. But in a classic Waterfall system, it does typically resemble more of a left-to-right flow from beginning of a project to launch.

What kinds of things need to be addressed in design?

Engineers can only fix accessibility issues so much. We can fiddle with colors to subtly meet contrast ratios or come up with alt text for some image assets.

But we can only go so far. We might be assigned a drag & drop component that needs a design overhaul to have a chance at being accessible. Or QA or Product Management might ask, ”why is this orange not our brand color?”

We would be better off working with our design and content strategy colleagues earlier in the process to highlight these missing requirements and include them from the start next time.

How do you convince stakeholders?

There’s an art to persuading stakeholders to care about accessibility. You first have to understand your audience and what motivates them. Do they care about legal risk and compliance? Lost revenue? Brand reputation?

My strategy is to tackle large tasks in phases, including accessibility efforts. If you can break tasks down into smaller, achievable steps and cross them off the list, things will get done. When combined with a strategy of an accessible MVP and iterative subsequent phases, you could keep things accessible along the way.

A reality in many organizations, however, is to implement accessibility long after an inaccessible version has already launched.

Tips for prioritization

How would I go about convincing leadership or my team of how to tackle it? Some heuristics for prioritization could include:

• Accessibility impact of issues, including WCAG success criteria and level. Does this significantly block users?
• Analytics and metrics. Are core user flows impacted? Which browsers and platforms?
• Identify areas needing more help. Do we need design thinking or content strategy to get this right?
• The cost of not doing it. I’m no MBA but I could take a pass on estimating the cost of a retrofit vs. doing something right from the start if I broke it down into parts.

We will discuss a whole lot more on organizational skill building for accessibility later in the workshop!