This one is a bit different from the others.
User-led sprints.
Maybe "sprints" feels like a loaded word. Call them sessions if you want.
No matter. The idea is this. On a schedule you set, you bring in users with disabilities and ask them one question.
Where are you stuck in our product right now?
Then you fix it.
Their frustration drives the priority instead of your audit findings or what some automated tool flagged last time you ran it.
Herein is the difference from a backlog and it really is fundamental. You build your backlog on what you think matters. You build this on what users actually experience. Those two things are rarely the same.
I've done these sessions before and I must say there's something that happens in your mind when a real person shows you where they're stuck. The impact is just not the same when compared to some fictional user or a bunch of text on a ticket somewhere. It's definitely harder to ignore and to say "we'll get to it." That level of accountability is useful if you're having problems prioritising accessibility.
The frequency of these sessions is up to you. You set a schedule, maybe it's once a quarter, maybe it's once a month. The point is the commitment to let users set the direction.
There's a catch.
It's damn hard to recruit users. Finding and fairly compensating people for their time will take real effort on your part. It's definitely not something you can do on a whim cheaply, and it shouldn't be. If it were, you'd just treat it as everything else. Check the box and move on.
But if you do it well, this is the most honest prioritisation system on the list of alternatives for a backlog.
Still, it's not the one I would reach out for if I had my way.