You probably know by now I'm not a big fan of audits.
I've seen what happens when a team gets a long report at the end of a project. The findings in there are real, but the people who made the decisions that caused the issues have already moved on. They're already on to the next release and nobody has set aside time for these fixes. So the audit becomes a report, which becomes a backlog the team feels bad about.
That's what frustrates me. The audit found problems people are probably facing right now. Finding them so late makes those problems that much harder to fix.
That being said, I don't debate the usefulness of an audit. It definitely has its place. It can show what we missed, especially if nobody tested the product before. But the report isn't enough. I want to know what happens when you get it.
I'm sure a well done audit can tell you the booking flow has an accessibility problem, what the problem is and how to fix it. But it won't help you much in prioritising it and much less in finding the time to fix it.
It's still up to you to work out which issues stop patients completing a task, which ones share a cause and where the fixes fit among everything else you've already committed to build.
I'd start with the patient and what they need to do. When someone can't find and confirm an appointment, I'd group those findings together. We can tackle those as a group, giving the team enough time to fix that flow and test it again, rather than closing whichever tickets happen to be quickest.
All that work needs a place in the product plan. Having a separate accessibility backlog is the dumbest thing I've heard. It only makes the fixes feel separate from the product. The patient doesn't experience a separate product!
All an audit is is evidence. Useful evidence, to be sure, but what I want know is what we'll do with it.
And the first question is whether you can point to a time in the plan to fix and retest what the audit told you was wrong.