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.
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 blocking 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 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.
Don’t be afraid to escalate this kind of feedback. Good dev managers want to know where their teams need additional help and will welcome the feedback when one of their team members is lacking basics.
Warning signs a developer needs dev coaching rather than accessibility coaching
- No understanding of or appreciation for semantic markup
- Flawed implementation of elements from your component library
- Adding code and attributes without bothering to learn what they mean
- Using JavaScript when the solution is better suited to CSS
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 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 ignoring obvious acceptance criteria or previous accessibility coaching guidance already delivered.
Another common occurrence is a developer who continually asks you to test their work. Remind them 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.