The reporting below was a result of running the systemic analyzer against sets of websites that use the same development frameworks. In doing this, it highlighted shared issues across websites that were result of frameworks themselves. There are links to the results dashboard at the end of each section.
Laravel#
Laravel and the Boilerplate Focus Erasure.
Laravel is an absolute titan in the PHP world. It is beloved for its elegant syntax and incredibly fast developer experience. But when looking at the systemic accessibility data across production Laravel builds, a very specific barrier dominates the dashboard.
In my recent evaluations, Missing Visible Focus Indicators (WCAG 2.4.7) affected 15 different pages systemically.
How does this happen?
Laravel itself is a backend framework, but the ecosystem heavily pushes frontend boilerplates (like Laravel Jetstream or Breeze) to help teams move fast. These starter kits often ship with utility-driven CSS (Tailwind is the default) designed to look as sleek as possible out-of-the-box.
To achieve that “clean” aesthetic, default styles frequently strip out native browser focus rings using outline: none or fail to provide high-contrast :focus-visible states.
The Impact
When we inherit these boilerplates, we instantly lock out keyboard-only users. Without a focus ring, users relying on a keyboard or switch device have absolutely no idea where they are on the page.
The Fix
If you are spinning up a new Laravel project using a starter kit, do a quick Tab-key test on a fresh install. Adding a global :focus-visible { outline: 2px solid #yourBrandColor; } takes two seconds at the start of a project, but saves hours of remediation later.
Laravel Websites Test Results Dashboard
Astro#
Astro and the Fragmented Hierarchy.
Astro has taken the frontend world by storm. Its “Islands Architecture” allows teams to ship zero JavaScript by default, while letting developers mix and match React, Vue, and Svelte components on the exact same page.
It is a performance masterpiece. But the data reveals that this architectural freedom comes with a structural cost.
When running systemic analyzer tests across production Astro builds, two issues consistently clustered together: Fake Headings (WCAG 1.3.1) and Color-Only Indicators (WCAG 1.4.1), affecting up to 15 pages.
How does this happen?
When you build a site by stitching together components from three different ecosystems, you lose the safety net of a unified design system. A Vue component might use an <h2> for a title, while a React component sitting right next to it uses a bolded generic <div>.
Furthermore, these isolated components often rely solely on color to indicate links or states, forgetting to add underlines or icons because they weren’t tested against the global layout.
The Impact
Screen reader users rely on a logical, sequential heading structure to navigate a page. When the DOM is a fragmented mix of different component library standards, that structure completely breaks down.
The Fix
Astro’s flexibility is its superpower, but it requires strict global CSS governance. Ensure your typographic hierarchy (h1 through h6) and link styling are enforced globally at the layout level, not trapped inside individual component islands.
Astro Websites Test Results Dashboard
Qwik#
Qwik and the Missing Bypass Block.
Qwik is pushing the boundaries of web performance. By focusing on “resumability,” it delays loading JavaScript until the exact millisecond a user interacts with an element. It is incredibly fast.
But in the race for perfect Lighthouse performance scores, we are seeing a crucial piece of accessibility scaffolding get left behind.
Across the Qwik applications evaluated in my latest dataset, Missing “Skip to Main Content” Links (WCAG 2.4.1) was the dominant systemic failure, affecting 14 production pages.
How does this happen?
When optimizing for edge-rendering and minimal initial payload, developers often strip the HTML down to its absolute bare minimum. Because SPAs often load visually instantly, there is an assumption that structural bypass blocks aren’t needed.
The Impact
Load speed doesn’t change the fact that a keyboard user still has to manually hit the Tab key 40 times to get past a massive global navigation menu. Without a hidden “Skip to Content” link at the very top of the DOM, navigating complex applications becomes exhausting for motor-impaired users.
The Fix
Performance and accessibility are usually best friends, but not if you delete semantic structure to save a few bytes. Always include a .sr-only skip link as the very first focusable element in your root layout file.
Qwik Websites Test Results Dashboard
Ruby on Rails#
Ruby on Rails and the SPA Emulation Trap.
Ruby on Rails defined an entire generation of web development with its “convention over configuration” philosophy. But as the web evolved, Rails had to adapt to compete with the snappy, dynamic feel of modern Single Page Applications (SPAs).
When reviewing systemic analyzer data for production Rails apps, a unique combination of debt appears: Missing Skip Links (WCAG 2.4.1) and Focus Indicator Failures (WCAG 2.4.7).
How does this happen?
To make server-rendered HTML feel like a dynamic React app, the Rails ecosystem heavily utilizes tools like Hotwire and Turbo. These libraries intercept link clicks and inject new HTML into the page without a full browser reload.
The trap? Developers frequently forget that when the DOM silently updates, the browser’s native focus management is broken.
The Impact
When a user clicks a link and the page content updates via Turbo, the focus isn’t automatically moved to the new content. A screen reader user is left sitting in silence, unaware the page has changed, and keyboard users lose their place entirely.
The Fix
If you are retrofitting a legacy Rails app with modern dynamic HTML injection, you must manually manage focus. Utilize route announcers and ensure focus is programmatically shifted to the newly injected heading or container.
Ruby on Rails Websites Test Results Dashboard
NextJS#
` NextJS and the Headless UI Trap.
Next.js has become the gold standard for React frameworks, frequently paired with utility-first CSS and headless UI libraries. It allows teams to build incredibly fast, modern interfaces.
But when we rely on headless primitives and utility classes, we often inherit a specific flavor of accessibility debt.
Across 17 production Next.js builds, my systemic evaluations flagged “position: fixed” layout destruction (WCAG 1.4.10) across 16 sites, and systemic Target Size failures (WCAG 2.5.8) across 16 sites.
How does this happen?
Modern headless UI relies heavily on position: fixed for sleek drawer menus and sticky headers. Without careful responsive container constraints, these fixed elements overlap and trap users when the page is zoomed to 400%.
Simultaneously, default utility classes for buttons and navigation items often pad elements to look good visually, but leave the actual interactive click-target falling just short of the 24x24px minimum standard.
The Fix
When importing a headless component, do not assume it handles responsive zoom and touch-target sizes out-of-the-box. Always audit your global layout wrappers at 400% zoom before shipping.
NextJS Websites Test Results Dashboard
WordPress#
WordPress and the Theme Builder Illusion.
In the WordPress ecosystem, accessibility debt usually isn’t hand-coded by the development team—it is installed.
When evaluating systemic patterns across production WordPress builds, the failures rarely came from custom logic. Instead, they stemmed from premium themes and drag-and-drop visual builders.
The top structural failure? Fake Headings (WCAG 1.3.1) affecting 15 sites systemically, closely followed by Color-Only Links (WCAG 1.4.1) across 15 sites.
How does this happen?
Visual page builders prioritize aesthetics over semantics. They make it incredibly easy to style a generic paragraph block to look like a massive hero heading using font size and weight. Because it lacks a semantic <h2> or <h3> tag, the structural outline of the page is completely stripped away.
The Impact
Screen reader users navigate a page by tabbing through its heading structure. When headings are just visually styled paragraphs, those users are left without a reliable way to orient themselves.
The Fix
When you purchase a theme or install a visual builder, you are adopting the accessibility baseline of its author. Always verify that your visual builder is actually outputting semantic <h1> through <h6> tags before committing to the license.
WordPress Websites Test Results Dashboard
Angular#
Angular and the (click) Trap.
Angular is a powerhouse for massive, enterprise-scale web applications. But its highly modular component architecture and powerful templating syntax contain a very specific semantic blind spot.
When evaluating data across production Angular builds, one critical barrier dominated the dashboard: Event handlers tied to non-interactive elements (WCAG 2.1.1), affecting 19 different pages systemically.
How does this happen?
Angular makes it beautifully simple to attach an event to anything. Developers frequently drop (click)=“doSomething()” onto a generic <div>, style it like a button, and move on.
The Impact
You cannot simply bind JavaScript to a <div> and expect it to be accessible. Screen readers do not know it is interactive, and keyboard users cannot trigger it with the Enter or Space keys. This single habit scales instantly into thousands of keyboard failures across an enterprise application.
The Fix
Run a quick global search in your repository for (click). If it is sitting on a <div> or a <span>, swap it out for a native <button> to instantly restore native keyboard accessibility.
Angular Websites Test Results Dashboard
Hugo#
Hugo and the Template Multiplier.
Static Site Generators (SSGs) like Hugo have revolutionized web performance. But that raw compilation speed comes with a unique accessibility risk: the Template Multiplier.
Because SSGs compile static pages from a few central layout files, a single semantic flaw gets stamped across thousands of pages in milliseconds. Across the production Hugo sites evaluated, Color-Only Links (WCAG 1.4.1) and Orphaned Widget Headings (WCAG 1.3.1) dominated the clusters (affecting 13-14 pages).
How does this happen?
Static themes lean heavily into minimalist design, often stripping away link underlines. Meanwhile, generated footer columns and sidebar widgets frequently rely on visual styling instead of proper heading markup, breaking the document structure.
The Fix
The beauty of the SSG ecosystem is that fixing these issues is just as fast as creating them. You don’t have to patch 5,000 pages—you just have to add underlines and <h2> tags to a single footer.html file, and the compiler fixes the rest of the site for you.
Hugo Websites Test Results Dashboard
ReactJS#
ReactJS and the Isolation Assumption.
Component-driven development allows teams to build and test UI elements in perfect isolation. But the accessibility data tells a fascinating story about what happens when those isolated components are finally dropped into the wild.
Across the React builds evaluated, the most common systemic failures were tied to context shifts: Missing Skip Links for SPAs (WCAG 2.4.1) affecting 17 sites, and Inherited Contrast Failures (WCAG 1.4.3) across 17 sites.
How does this happen?
A reusable React component with a transparent background might pass a contrast check in isolation (like inside Storybook). But when deployed across multiple production layouts, those components frequently fail because they are placed over unpredictable, inherited parent backgrounds. Furthermore, the root <App> wrapper is frequently deployed without a structural Skip to Main Content link to help keyboard users bypass the global navigation.
The Fix
A component is not truly accessible until it survives the unpredictability of a global layout. Ensure background colors are explicitly defined, and verify your root application shell provides a valid keyboard bypass block.
ReactJS Websites Test Results Dashboard
VueJS#
VueJS and the “New Window” Blind Spot.
VueJS offers some of the most elegant component authoring experiences on the web. But just like React, Vue’s superpower—encapsulation—can become an accessibility blind spot when context suddenly changes.
When running systemic accessibility evaluations across Vue production sites, the leading issue was Links opening in a new window without warning (WCAG 3.2.5), scaling across 18 pages.
How does this happen?
Vue makes it incredibly easy to build a universal <ExternalLink> wrapper component to handle all outbound routing. However, developers consistently forget to pass visually hidden warning text (.sr-only) into these wrappers.
The Impact
When an encapsulated link component forces a new browser tab to open, users relying on assistive tech are thrown into a new environment with zero warning, completely breaking their navigational flow.
The Fix
If you abstract your routing into a global component, bake a visually hidden (opens in a new tab) string directly into the template anywhere target="_blank" is utilized.
VueJS Websites Test Results Dashboard
Svelte#
Svelte and the Scoped Sizing Trap.
Svelte is beloved for its compiler approach, performance, and built-in accessibility linting. But while the compiler catches missing alt tags, it cannot always catch layout and styling accessibility debt.
When evaluating production Svelte builds, the failures came from the framework’s biggest selling point: Scoped CSS. Absolute Font Sizing (WCAG 1.4.4) affected 15 sites, alongside Fixed Layout Reflows (WCAG 1.4.10) across 17 sites.
How does this happen?
Svelte makes writing component-level CSS a joy, preventing style leaks. However, developers frequently hardcode px values instead of rem inside those scoped <style> blocks.
The Impact
When font sizes are locked to hard pixel values, it globally breaks the ability for users with low vision to scale their text sizing in the browser.
The Fix
Strictly govern your scoped component styles. Ensure all typographic variables are utilizing rem or relative units, allowing the browser’s default user agent stylesheet to handle text scaling natively.
Svelte Websites Test Results Dashboard
Django#
Django and the Legacy Frontend Collision.
We have talked heavily about modern JavaScript architectures, but backend-heavy giants like Django power massive web applications. Django is rock-solid, but it often relies on older frontend templating patterns.
When evaluating systemic audits across production Django sites, the debt looks vastly different than modern SPAs. The dominant clusters? Legacy Event Handlers (WCAG 2.1.1) affecting 18 sites, and Touch Target Sizes (WCAG 2.5.8) across 19 sites.
How does this happen?
This is the result of retrofitting modern interactivity into legacy HTML. To make static templates feel dynamic, teams often sprinkle JavaScript onclick events onto <div> and <span> tags. Furthermore, form inputs and pagination links originally designed for desktop cursors consistently fail modern 24x24px mobile touch-target requirements.
The Fix
You cannot simply attach JavaScript to an older HTML structure and expect it to be accessible. Backend templates require active frontend modernization, ensuring all interactive elements utilize native buttons and proper mobile padding.
Django Websites Test Results Dashboard