The last section I want to talk about from this year's Web Almanac on accessibility is the section covering JavaScript frontend frameworks.
Throughout the years, I've used quite a few of these. I started back in the day with BackboneJS then moved on to AngularJS. You know, the one before Angular. I dabbled a bit in Vue, before I settled on React. But there's no shortage of frameworks. Barely anyone builds anything vanilla anymore. As common as they now are on the web, what you choose apparently has some impact on accessibility.
The data does show this correlation, I just don't trust it. Again, correlation does not mean causation.
Yes, JavaScript (JS) frameworks can be made accessible, but the truth is many sites still ship serious crap when using them. Accessibility problems often come from how teams use said frameworks, not from the frameworks alone.
The most frequent issues come in the form of custom widgets without proper roles, names or keyboard support. They have poor focus handling and broken semantics since devs thought using divs and spans instead of native HTML elements was just as good.
And they were wrong.
The Qwik framework came out as the "most accessible" in the almanac mainly because of how it deals with JavaScript and page load. I don't think it has anything to do with Qwik magically fixing ARIA or HTML issues. Its resumable architecture sends complete HTML first and only loads small bits of JS when users interact. This makes content and basic controls work even on slow devices or, more importantly, when scripts fail.
This lines up well with core accessibility ideas like progressive enhancement, fast first paint and keeping pages usable for keyboard and assistive tech users under weak conditions.
The other frameworks often need heavy hydration, rely on virtual Document Object Models (DOMs) before pages become fully interactive. This can block or delay accessible behaviour if something goes wrong. That div with all the right ARIA sprinkles to make it a button works no longer.
You might think that this means that wherever JS is required, accessibility issues come out to play. Not really. JS being required for basic use usually makes a site more fragile, yes. But it does not mean JS itself makes pages inaccessible. Many serious barriers come from how people use it. Remember those custom widgets without semantics, broken keyboard support and logic that assumes a mouse or perfect network.
We keep coming back to this good pattern of progressive enhancement. So what does that mean?
In plain terms, a site that uses progressive enhancement will have the core content and tasks work in plain HTML and rely on JS only to add nicer and more natural behaviour on top. It's important to say again. Plain HTML works fully on its own. Basic tasks, like navigation or forms, load first and work without scripts.
So if progressive enhancement means start small and build up, could you do it the other way around and get the same result?
Yes, you could. That's called graceful degradation. You begin with a full-featured site using the latest tech, disregarding actual user browser usage and network conditions. And the idea is that if a browser can't handle it, the site falls back to simpler options, like hiding fancy effects or showing basic links.
That makes accessibility become an extra step, because now you need to make sure that what you take away isn't what was making something accessible.
Bottom line, frameworks don't matter. It's how you use them and whether you start with the basics right first.
But what about meta-frameworks? Those things that give you lots of extras out of the box? Things like routing, server rendering and code splitting built on top of frameworks.
Surely they can enforce or make good patterns the default, right? Patterns like accessible focus management, announcements for screen readers, all progressively enhanced.
Yes and no.
According to the almanac, RedwoodJS topped the list of most accessible meta-frameworks, despite being built on React and not Qwik. This seems to support the idea that meta-frameworks can and do enforce patterns. RedwoodJS includes automatic route announcements for screen readers, skip links, focus resets on navigation and visual-hidden helpers. All these are handy for single page applications where standard React apps often fail.
So if meta-frameworks enforce good accessibility behaviours, should they be the default way of building with a JS framework?
No, definitely not.
Meta-frameworks tie you to their rules, making it hard to switch or reuse code elsewhere. If their accessibility tools lag, you're stuck hacking around them instead of fixing directly. The bigger problem is that these built-in features hide gaps. Developers skip learning semantics and assume the framework handles it. And as these frameworks evolve, teams have to relearn or rewrite instead of mastering timeless web standards like HTML and progressive enhancement.
What are we to do then?
Prioritise learning core web accessibility principles. Learn semantic HTML, read the WCAG, use your keyboard more often to move around a website. And before relying on any framework or meta-framework, consider progressive enhancement. While tools like RedwoodJS offers helpful accessibility defaults, they can't replace understanding how assistive technologies work or why certain patterns matter.
Lastly, no two projects are alike. So choose frameworks that align with your project's actual needs rather than defaulting to opinionated meta-frameworks that may lock you in or obscure gaps in your knowledge.
Accessibility isn't something you install from a code repository.