Sadly, it gets put at the bottom of the stack like a 2nd class citizen. Budgets are not there, and many companies don’t understand how important it is to do it and get it right.
It needs to be prioritised like any other paid work your team does.
Building software, it’s always easier to do it right than to do it twice, and it’s always easier to do Accessibility when you’re building than after you release it to the world.
It then is considered technical debt and has even less chance of getting done.
So start today!
If you don’t already have one, create an Accessibility backlog and start doing browser testing and screenreader testing. There are many options but I like Axe by Deque for in the browser and NVDA on PC or Voice Over on Mac.
Technically speaking, you test your pages and start building a list of issues; link back to WCAG issues and give your developers the solution for fixing each in the HTML.
And don’t forget to tab through your pages; can you navigate your product or service without the mouse? Can you see where your tab focus is currently? Is the tab order correct or does it jump all over the place?
If you were blind would a screenreader be able to tell you what’s on the page? What to do next? Would it let you skip sections you don’t need to review?
Remember, “No aria label is better than a bad aria label”.
Remember too that 1/2 of a11y testing is objective, and 1/2 is subjective. It’s all about relationships between fields and labels, in a nutshell, and it takes a human to understand the combined picture that results in the browser from your code.
Deque offers Selenium tests which you can run on your application which covers the 1/2 of the objective part (plus manual testing using the browser and the Axe extension).
Most importantly GET STARTED!
From my experience, it feels daunting at first, then you start to see the patterns emerge: Are you using proper, semantic HTML?
Accessibility is a huge and vital part of Usability.