> who aren't in a huge company with dedicated a11y or UX teams

Assuming you’re a small team and with a site / product that’s not big yet, can you share why you are thinking to implement accessibility at this stage?

The problem with accessibility is the need to think about it at all. It doesn't matter how easy it is to implement as the problem first and foremost is the mental and organizational bandwidth consumes.

Perfect accessibility on the web as it stands requires every dev to be working on it. Especially in a world of AI, efforts on this would be better spent on AI agents that replace screenreaders.

I would love some kind of accessibility library. Especially as a mostly solo dev working on a medium-size project, ensuring the application is accessible means having to constantly relearn standards whenever anything needs to be updated. Which means parts of the site just don’t meet accessibility standards.

Currently, making a site accessible is more like a strong linter and a few standard UX elements (skip to content, etc.) Typically your tasks are things like: Increase the contrast on these 11 fonts, add missing labels, ensure keyboard navigation works. It is more of a checklist-type set of actions than a framework or library.

But it was supposed to be evolving, at least from a regulatory perspective. The Office of Civil Rights in the DOJ owns enforcement of this, and that team is pretty friendly and reasonable. Or was a few years ago... I haven't talked to them since the current administration came in, so don't what what their current state is. In any case, their plan a couple years ago was to stop making it about checklists and accessibility checkers and work towards a broader goal of "Make the UX as good for people with limits as it is for people without limits." They wanted to get away from, for example, solutions that would meet the letter of the law by making a non-mouse user hit tab 117 times when a mouse user only had to do one click.

So if you are really trying to do accessibility well, that is the perspective to embrace - not "give me a tool that fulfills a checklist", but "Make UX equitable for all."

Web accessibility is generally super easy, but that comes with huge caveats. If you are comfortable with HTML and JavaScript you should be achieving 80% AA conformance immediately out of the box.

1) The more abstract and frameworky the code becomes the more challenging accessibility becomes. Vanilla JavaScript applications have an insanely huge advantage here.

2) Understanding web accessibility is as straightforward as reading the conformance criteria. This remains true for non developers.

3) Developers have one additional step to really understand accessibility: using HTML correctly to describe content.

4) Finally the most challenging part of accessibility from only looking at the code is color contrast and enough space between interactive controls.

I found it quite easy to slowly integrate it into my work. The tools got better and so did the documentation. It also has SEO and possibly LLM benefits, and it makes testing with Playwright much easier.

Not to be that guy (honestly idc) but a11y is cool but it’s just a tick box.

Maybe for a Netflix or some other widely used consumer app it is essential because the # of affected users might be significant.

For a 2ish million user SaaS I used to work on, nobody ever cared enough because the chance that someone is going to use a11y features to do their work was extraordinarily rare, in fact probably zero considering the domain. We did enough to cover our bases, maybe 80-90% of the way there, but that’s it.

I mean emotionally I get it. But it’s a business at the end of the day. For a popular consumer app it makes sense to invest the time and effort. For others, it really is not.

From my experience if you’re following web standards you’re already ahead of most developers and websites. Anytime people don’t follow the standards that’s when it gets really messy.

Beyond that tools like WebAIM and Lighthouse help a ton.