Question for all the people claiming basic accessibility is low effort... Following your low effort implementations of basic accessibility have you actually te

Question for all the people claiming basic accessibility is low effort... Following your low effort implementations of basic accessibility have you actually tested your website/app with a screen reader or other accessibility tool? Or have you just used some semantic markup, scattered a few aria tags and called it a day? I have worked on a mobile phone app where the client dictated certain accessibility requirements up front. I can tell you right now if you aren't testing in a screenreader then you haven't achieved basic accessibility. And from my experience, once you start testing with a screenreader you will quickly discover that all those assumptions you have about "all you've got to do is add a few alt tags, pick sensible font colours and use semantic structure" fly right out the window. Every single app screen we did had an additional test pass by a tester who would use the screen via accessibility tools. The app as a whole had several accessibility test passes during the dev cycle. Both of these test stages would always throw up new bugs that would often require significant rework to get working right with the accessibility tools. I'll grant that my experience here is in mobile apps, and I accept that the available accessibility tools for mobile are limited and perhaps that was part of our challenge. And maybe the ecosystem is more mature for websites and desktop apps. So this is a genuine question for those claiming it's low effort. Have you actually tested it? If you haven't actually tested it, perhaps your websites/apps are part of the problem, you just don't know it. I personally think developing for accessibility is a good thing, and I always do it when I can. I try to follow best practises for accessibility even if the current project owners don't mandate it. But at some point you can't just follow best practise and hope it works, you've got to commit to testing it, and then commit to raising bugs against it, and triaging them through the bug process, and at some point you'll be at a standup 2 days before a release with 10 bugs on the board, 6 of them accessibility bugs, and only time to fix 4. Guess which ones are going to make it into the release. If my experience follows for other domains, to claim that it has zero or minimal cost is ludicrous. Developing and testing for working accessibility comes with significant cost and therefore of course it's a business decision.