In this blog, Nathan Ortiz writes about what to do when the call to ship something inaccessible sits above your pay grade. Drawing on his time as a developer on a small team, he sets out what you can still do: log the issues, get the critical ones on the record, build a real workaround, and tell users about it.  

The call to ship something inaccessible often sits above your pay grade, which can be hard to accept when you care about doing things right. I’ve raised accessibility issues clearly, with receipts, and watched them get deprioritised anyway. It was disheartening and I found myself questioning whether it was even worth raising issues when I knew they were unlikely to be addressed. 

I was discouraged by leadership at a company that simply didn’t have the accessibility maturity in place.  “Sometimes it’s just not possible.” “This is a legacy codebase.” And the classic: “We can’t fix everything.”  What I’ve learned is that getting overruled doesn’t mean getting ignored forever. How you respond in those moments matters. So when it feels like you have no control, use what you can. 

Don’t Look Away 

While you shouldn’t ignore accessibility issues, you don’t have to act on them right away. When spotting an issue while working on something else, take note of what it is and where it is. Put it somewhere that makes sense for you and your team. Since I was a developer on a smaller team, I would flag it with “To Do” comments in the code. Then I would notify either the project manager or quality assurance (QA). They would then write up a ticket, set the priority, and put it in the issue backlog. The act of escalating issues to the team won’t ensure that they’ll get fixed, but it’ll at least give them a fighting chance. 

Focus On Process 

There will always be accessibility issues, hence the emphasis on treating accessibility as a process rather than a destination. Accessibility in digital products can be surprisingly easy to break.  I’d often see someone from marketing go into the content management system (CMS) for a website and add an image to the page without an image description. This would result in recurring cases of missing alternative text, even though as a development and design team, we did everything we could. Accessibility training for non-technical staff was simply…well, not in the budget. 

Focus instead on having a decent process in place to identify and remediate issues, such as regular testing or spot checks. An ongoing, iterative process helps you step back from nitpicking and make peace with minor issues you can return to later. 

Ship Within Reason 

You may not have the final say, but you can still influence the conversation. Before the ship date is locked in, bring these 3 questions to whoever does have control: 

  1. Are the issues critical – can they cause harm or prevent someone from completing a task or accessing a key user flow?  
  2. Are workarounds or alternative access missing? 
  3. Could this create technical, legal or reputational debt that ‘we’ll fix it later’ won’t actually solve? 

If any of the answers are “yes,” bring it up. Note it in the ticket, email, or meeting. You may still get overruled and that’s out of your hands, but make sure your concern is on record. If something goes wrong later, “I flagged this before launch” is a very different position to be in than silence. And if the answer to the first question is yes, push harder! Timelines can move and clients will live. Harm to a user is a much harder thing to walk back. 

Identify Workarounds & Inform Users 

I was recently working on a side project where I did have full control. I found myself out of time and staring down a known issue. Here’s what I did, and it’s the same approach I’d take if the call had been someone else’s.  

Although the HeroUI (previously NextUI) v2.8 library claims accessibility out of the box, their ‘NavbarMenu’ component that functions as a hamburger menu is inaccessible via keyboard tabbing or screen reader navigation. It places the menu items at the very end of the tab order, forcing users to tab through every interactive element on the page first. My options to fix it were: 

  1. Add an unnecessary amount of JavaScript to hijack focus, potentially creating a subpar experience. 
  2. Remove the component and rebuild it properly myself. 
  3. Document the issue, provide a temporary workaround, and revisit it later. 

I went with option 3 to avoid wasting time on unreliable band-aids. I quickly added a human-readable Site Map page as an accessible alternative, along with a skip link to it just before the navigation. I documented the issue and how to access the Site Map in the “Known Issues” section of the accessibility page. 

While not ideal, this provided a workaround and informed users of both the issue and the available alternative. The goal is to give users direction and access while you work toward a proper fix. Sometimes, it’s okay if the bar is just usable for now. 

Accept Feedback 

Allow a way for users to contact you and inform you of issues on the website or app. The feedback component itself must be accessible and findable. Otherwise, it’s basically performative, which may very well come back to bite you. Feedback can also help you identify what’s broken from the perspective of the people experiencing those barriers, giving you insight that automated testing and audits may not reveal. Taking that feedback seriously can help you prioritize meaningful fixes, improve the experience for users, and avoid many legal repercussions. 

Commit to the Fix 

Don’t banish issues to the backlog. Aside from carrying out the important duty of informing users, a “Known Issues” section on your site also helps with accountability. If the same issues have been burning a hole in the page for a while, people may start to notice, and that’s embarrassing and risky in terms of reputation and legality. Your list of “To Do’s” could mean the difference between someone having a pleasant user experience or a terribly frustrating one. Read more about the dangers of the backlog in Charlii Parker’s “Straight to the Pool Room”: The Risks and Pitfalls of Placing Accessibility Issues in the Backlog. 

Keep Going 

Nobody gets it perfect. What separates a good accessibility practitioner from a burnt-out one is knowing the difference between what you can fix now and what you can fix later. Just make sure neither list gets ignored forever.