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.
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.
> 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?
If you leave it late you will find it much more difficult to implement. And it is important to do. I created a free music app which by coincidence was easy for blind people to use. The gratitude I got has made me conscious to do this ever since.
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.
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.
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.
> 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?
If you leave it late you will find it much more difficult to implement. And it is important to do. I created a free music app which by coincidence was easy for blind people to use. The gratitude I got has made me conscious to do this ever since.
I think of that kind of accessibility just like other product feature dimensions.
There’s an opportunity cost, so you have to decide where you spend your time.
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.