When I give presentations on accessibility, I often get one or two questions I’ve fielded before. I’ve collected a handful for an ongoing series of posts with my answers. I hope it helps you understand accessibility better.
Which accessibility problems do I fix first?
You’ve tested your site or application for accessibility and discovered you have a long list of problems. You have a set of priorities dictated by other forces, like a feature list, a revenue stream or company goals. How do you fit in accessibility? Maybe you should tack it on at the end? Focus on it in a separate sprint?
You don’t have to do any of that, or alter your goals or priorities. Of course, you do have to slot accessibility into your workflow. That’s where you should start – wherever it fits into your workflow. In a perfect world, you want to be testing code for accessibility problems before it’s committed and pushed to production. You want to involve people with disabilities in your design thinking and testing. But one thing at a time here.
Fix the problems you have in your design or code in the next swath of work you already plan on doing. Pick one area and focus on it. Fix it, and deploy those changes, even if you don’t fix all the problems. Repeat that process. Accessibility is a continuum, not just one step.
That area of focus could be keyboard accessibility, adding missing labels or whatever your testing reveals. The problems you should fix first should be a small selection of ones you have in front of you. And that selection should be related to the work you’re doing already. Make it a little better one section at a time.
Further reading: You Don’t have Accessibility Problems, You have Quality Problems
_Image by rawpixel.