Hello fellow accessibility practitioners 👋
I’m wondering if anyone could confirm (or the other way around) my hunch that a project built with a JS framework requires more heavy lifting to be accessible (even when you don’t forget it at the start) #a11y #accessibility

@gyomb Why ask this question? (in an attempt to answer it better) 😅

From what I can see, whether a project is built with Angular, VueJS, React, or something else, it’s often highly inaccessible because the ability to “simply” add click events everywhere hasn’t helped (even though you could obviously do that before). But let’s just say it has made it easier to make a component inaccessible, yes.

@skyounet hello. I’m trying to evaluate if the idea of a new framework built with accessibility in mind is worth researching or if it is juste based on my own biases.
For instance I think that framework devs are not learning HTML/CSS basics because of the way the frameworks works and are taught. I’m also thinking that framework add a lot of inaccessible non-standard stuff that the devs have to painfully make accessible again. 1/2
@skyounet But that just me thinking in my little corner : I never had the (bad) luck to directly work on a project relying on a framework 2/2
@gyomb While I can point to lots of anecdata and specific examples of all of them being trash, you may want to wade into something like the WebAIM Million to find more:
https://webaim.org/projects/million/#frameworks
WebAIM: The WebAIM Million - The 2026 report on the accessibility of the top 1,000,000 home pages

@aardrian thanks for the tips ! Seems like there is a lot of useful details here. If you have some stories illustrating the systemic issues with framework, the peoples using them and accessibility, I would love to read them ! (If it doesn’t take too much of your time, of course)

@aardrian PS : I’m trying to ascertain if there is ground for trying to “fix” frameworks by building a minimalistic framework that start with accessibility concerns and try not to override standards.

But as I never worked on a big project using those I want to verify I’m not imagining a problem that doesn’t exist (something we love to do in the tech world 😅)

@gyomb I typically don’t write big diatribes on specific frameworks since it becomes free consulting.

I’ll point out obvious failures:
https://adrianroselli.com/2023/09/the-children-are-driving-the-bus.html

Or offer general guidance after shitty patterns almost become standardized:
https://adrianroselli.com/2020/01/defining-toast-messages.html

But largely I write general accessibility guidance posts aimed at framework folks (who never read them):
https://adrianroselli.com/2019/08/basic-custom-control-requirements.html
https://adrianroselli.com/2022/11/your-accessibility-claims-are-wrong-unless.html
https://adrianroselli.com/2024/09/semi-annual-reminder-to-learn-and-hire-for-web-standards.html

Also, NDAs.

@aardrian thanks for the interesting reading list ! 😄
@gyomb Not necessarily, depending on the framework. If it's "just" React, Vue, or the like, it may allure you to solve things via custom JavaScript because of framework magic. If its a component framework like Vuetify, it can make a11y complicated, however, PrimeVue lately got "decent" in terms of a11y. If its not, it's hard to work around that. But I'm not an expert

@shaedrich @shaedrich thanks for the feedback.
I had the same feeling that a lot of issues comes from how easy it seems to do everything JS rather than using the standard element.
Regarding component libraries, it’s cool that there is now some that take it into account.

Now I wonder : could we build a framework that tells us to “not use it” when standard element exists, or at least explains how to interact responsibly with it? 1/2

@shaedrich
That would be a framework that promotes multipage sites with hydrated islands first. Should it also promotes SSG over SSR ? I don’t know.

I may be biased (writing docs is my day to day job) but I think the most important is to structure the doc to promote HTML and recurring patterns that are based on the standard (with minimum use of the framework for state and reactivity) 2/2

@gyomb You're welcome.

I think, there are several issues:
– newcomers may have never learned how to do it properly → they would have to be educated (is that the job of the framework?)
– lazy people take shortcuts if the the framework lets them (this can be avoided, but that would depend on its specs)
– people who care get discouraged because they are told, they contribute code that is inconsistent with the codebase or doesn't use the tools of the framework

1/

@gyomb One approach to this is progressive enhancement: Rather than building your component design system from ground up with that framework, you ship your MVP entirely with HTML and CSS and only then refactor with "enhancements" if needed. Also, most of these enhancements are to be implemented in a way that they are optional. Deactivate the JS in your browser on websites that use React or Vue and you know what I mean.

2/

@gyomb Another interesting thing is the changes in the web landscape over time, meaning what was available when you started with your project and what made it into the baseline, except for when you may had polyfills or the like. That begs the question if and when you should retroactively/proactively refactor your components whose JS becomes obsolete AFTER they have already been implemented. Many companies deem that not worth the effort. Maybe, the effort needs to be less.

3/

@gyomb What frameworks *could* do is taking the first step rather than the companies using said frameworks and refactor *their* components so that they are a) merely a wrapper for the native element b) become compatible with current web standards. This might make the decision to ditch the wrapper entirely, easier as it is more clear that there aren't many benefits to the current state of the web anymore.

4/