I try
My /accessibility pages are usually quite technical but this is a combination company/personal website so I will just be really simple and talk about my experience with accessibility. I'm not great at it - truth is, I never know whether I'm just really bad at using NVDA or whether the web is really that hard to use with a keyboard and with my monitor turned off. I am such an expert Voice Over user that I have to open my eyes to turn it off, answer calls, check Slack, change tabs, answer my email or fill in forms. It's not from lack of effort - I really genuinely try.
For me accessibility starts at colour schemes - I calculate contrast ratios for every colour combination that I use and keep note of which combinations are safe. In fact, I think I'll build a tool that works the way I want one to work. Hopefully soon.
Then it gets into system setup. One of the biggest joys of having founded Siteimp is that I have a really cool engine to run automated tests and collect accessibility metrics as I develop. It's so nice being able to run it constantly while I work that I am rebuilding Siteimp as a desktop application.
Lighthouse audits are a constant part of my work flow, but whereas I run Siteimp tests on every commit, I run full Lighthouse audits at least once or twice a day.
When I work with React, I use the ESLint a11y plugin because linting is an excellent way to catch problems before they ship. I don't collect frontend frameworks so that's 100% of my frontend development.
Screen readers and keyboard navigation (both visual and non) are a constant part of my testing flow. At some point I will automate keyboard navigation testing (somehow) and build that into Siteimp but for now I or someone else on a project team does it manually.
Rationale
Sometimes clients get upset when they find out that accessibility testing is part of my regular combo. It seems like a large line item because it is. It is expensive.
I started doing it for my own projects because I have formed some close relationships with blind/sight impaired users through the years. Watching them struggle with projects I worked on convinced me it was the right thing to do. Everyone should be able to use software.
Then a really weird thing happened and it started saving me a lot of frantic 4am debugging sessions. Accessibilty testing catches a lot of really weird edge cases and flows that just don't make sense. It results in better structured websites and applications that render in a variety of devices without any problems by default.
Accessibility testing is the right thing to do. But it also results in better software delivered faster and cheaper. Marketing wise, on average more users who experience some form of colour blindnss will use your application than Edge users. So if you're worried about the cost, I am convinced that once our project is complete you will consider it one of the best investments you have ever made.