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.
@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.
@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/