This week reminded me why working with legacy code can be such a pain in the arse, especially when accessibility is involved.
I came up against an old AngularJS application that used a drag-and-drop sorting library. The library hadn't been maintained in years and worse still, it relied on an even older JavaScript sorting solution underneath that was also around since time immemorial.
You couldn't sort anything with a keyboard. This completely breaks WCAG guidelines around dragging movements and keyboard accessibility. The issue came out of an audit.
My first move was checking the library's GitHub issues. Sure enough, someone had raised accessibility concerns years ago. I wasn't all that shocked to read that "such a feature will increase the complexity of the entire solution by about a third." Issue closed.
Three years later, there was only one comment on that closed issue. It's "a lame excuse for dismissing accessibility altogether." Harsh. Fair. Didn't yield any results.
So I rolled up my sleeves. I spent a full week cobbling together a keyboard-accessible solution within the AngularJS layer. The underlying library was simply too complex to change directly, so I had to work around it. It wasn't elegant, but it worked reasonably well.
Here's the thing.
Legacy code forces you into compromises. Sometimes you can't fix the root cause. All you can do is build clever workarounds. And maybe that's okay in most cases. After all, the end user could care less about the code or library used. They just want to order things with their keyboard.
But when maintainers dismiss accessibility as "too complex," you're often stuck implementing your own solutions. The truth is, accessibility shouldn't be an afterthought, but with legacy systems, that's often exactly what it becomes.
Sometimes you just have to make shit work with what you've got.