Avoid fire drills

Build processes for change, not overdependence on coaching

Why this matters

Fire drills are indicative of an organization that cannot independently operate without the accessibility team.

Relying on accessibility coaching to “fix things fast” will cause coaches to burn out without achieving lasting results.

Pitfalls to avoid

A good accessibility coach has the heart of a teacher but doesn’t steer people into dependence on coaching to complete daily tasks.

Don’t do the last second accessibility check

This comes in an urgent request, “We’re about to launch something and just need a quick accessibility check.”

When a team has ignored accessibility guidance to this point, it’s practically guaranteed the feature is full of issues to be remediated.

If you teach the team it’s okay to do this, you’ll be locked in this cycle.

What to do instead: ask questions and escalate

Resist the urge to immediately jump in and engage in another fire drill. Instead, take control of the conversation, and help transform processes.

Ask questions

  • Have you worked with anyone else from an accessibility team?
  • When is this feature being deployed?
  • What has your accessibility process looked like in design, development and testing?
  • What is your plan if there are severe issues that will block your launch?

Escalate to leadership

Document what’s happening, and then follow escalation procedures. If your leadership has business reasons to ship this feature before it’s ready, be prepared to negotiate a timeframe for remediation with stakeholders according to your remediation policy.

Don’t be the dev coach

If you find that you’re coaching developers through code basics (outside of accessibility specifics), escalate this to their manager so the team can get the help they need and your time can be spent on accessibility.

Warning signs a developer needs dev coaching rather than accessibility coaching

  • No understanding of or appreciation for semantic markup
  • Adding code and attributes without bothering to learn what they mean
  • Using JavaScript when the solution is better suited to CSS
  • Flawed implementation of existing UI components from your library

Don’t do people’s work for them

Respond to genuine questions

When people ask questions while actively trying to solve a problem early in the process, definitely dive in and help.

Maybe they have a question about adding ARIA attributes or placement of a label. Their questions are thoughtful and come from a place of exploration.

Someone who asks about meeting acceptance criteria or finer points of the differences between screen reader output is genuinely trying to learn and be a better designer or developer.

Be wary of dependent needs

There are also designers and developers that are looking for someone else to think and solve the problem for them without any effort on their part or change in their processes.

Be wary of requests that ignore obvious acceptance criteria or previous accessibility coaching guidance already delivered.

For example, if you’ve already delivered a recorded coaching session on remediation for a feature, but the product owner is returning to ask the same questions, refer them to the meeting recording.

Another common occurance is a developer who continually asks you to test their work. Remind them that you’re not a QA tester, but you will teach them how to use acceptance criteria to test their own work.

If this doesn’t work

As always, don’t be the police.

If a team continues to cause fire drills, follow your team’s escalation procedures and leverage leadership to define priorities.

Your checklist

Download checklist
Pitfalls to avoid
If this doesn't work
Download checklist