Install guides
For every CMS and framework you use.
24 platforms covered. Specific failure modes, install steps, and accessibility FAQ per CMS.
WordPress
Automattic / WordPress Foundation · 43% of all websites
WordPress accessibility means making the world's most-used CMS (43% of all websites) conform to WCAG 2.2 AA — through accessible theme selection, core-supported gutenberg blocks, plugin discipline, and disciplined editorial workflow on alt text and headings.
Shopify
Shopify Inc. · ~10% of e-commerce
Shopify accessibility ensures that themes, custom apps, and the merchant-managed catalogue and content layer conform to WCAG 2.2 AA — a critical requirement given that e-commerce (where Shopify holds ~10% market share) is the highest-litigation ADA Title III vertical in the US.
Webflow
Webflow Inc.
Webflow accessibility requires the designer to use semantic HTML (heading hierarchy, landmarks, form labels) and Webflow's built-in accessibility audit panel — Webflow generates the markup the designer instructs, so visual-first builders frequently introduce semantic gaps a screen reader cannot resolve.
Wix
Wix.com
Wix accessibility relies on the platform's accessibility wizard, semantic ADI templates, and merchant discipline on alt text and structure — Wix sites can meet WCAG 2.2 AA but only when the merchant uses the platform's built-in tools and avoids visual-only template choices.
Squarespace
Squarespace Inc.
Squarespace accessibility means selecting accessibility-aware templates, maintaining proper heading and link structure, and supplementing the platform's defaults with alt text discipline — Squarespace publishes an accessibility statement but expressly does not warrant individual sites are compliant.
Drupal
Drupal Association
Drupal accessibility is among the strongest of any CMS — accessibility is a core gating criterion for Drupal releases and the platform ships with WCAG-aligned defaults — but custom modules, themes, and contributed projects still require auditing to maintain WCAG 2.2 AA compliance.
Joomla
Open Source Matters
Joomla accessibility leverages the platform's WCAG-aware Cassiopeia default template and Joomla's accessibility initiative — but the platform's smaller extension ecosystem means accessibility maintenance is more manual than WordPress or Drupal.
Magento / Adobe Commerce
Adobe
Magento (Adobe Commerce) accessibility requires the merchant or systems integrator to layer WCAG 2.2 AA compliance on top of a flexible-but-complex e-commerce platform — Adobe publishes accessibility documentation but the merchant configuration, theme, and customisations determine the rendered conformance.
BigCommerce
BigCommerce Inc.
BigCommerce accessibility relies on accessibility-conscious Stencil themes (Cornerstone is the most-accessible reference), accessible app selection, and merchant discipline on content — the platform supports WCAG 2.2 AA conformance but does not enforce it.
HubSpot CMS
HubSpot Inc.
HubSpot CMS accessibility requires marketers and developers to configure themes, modules, and editorial workflows to meet WCAG 2.2 AA — HubSpot provides accessibility tooling but the marketer-driven, drag-and-drop nature of the CMS introduces specific failure points around custom modules and CTA components.
Sitecore
Sitecore
Sitecore accessibility requires enterprise development teams to implement WCAG 2.2 AA at the rendering and component layer — Sitecore is widely deployed in regulated industries (finance, healthcare, public sector) where EAA, ADA, and Section 508 compliance is mandatory.
Contentful
Contentful
Contentful accessibility is largely a function of the front-end framework consuming the API — Contentful provides accessible authoring tools (Rich Text Editor with semantic markup) but accessibility is delivered by the Next.js, Nuxt, or other consuming app and by editorial discipline around alt text in the Asset library.
Sanity
Sanity.io
Sanity accessibility depends on Studio schema design (required alt text on image fields), Portable Text renderers in the consuming front-end, and editorial discipline — the platform itself is headless and accessibility is a function of how the consuming app maps Sanity content to semantic HTML.
Strapi
Strapi Inc.
Strapi accessibility is primarily a function of the front-end framework consuming Strapi's REST or GraphQL API — Strapi itself provides admin UI for content editors with reasonable accessibility, and the consuming app determines rendered conformance to WCAG 2.2 AA.
Ghost
Ghost Foundation
Ghost accessibility depends on theme choice — Ghost's default Casper theme targets WCAG 2.1 AA; custom themes vary widely. The platform itself supports semantic markup, alt text, and accessible editorial workflow but does not enforce it.
Next.js
Vercel
Next.js accessibility is React-app accessibility — semantic HTML, ARIA where necessary, route announcements for SPA navigation, focus management, and SSR-rendered initial markup that screen readers can immediately parse before hydration completes.
Nuxt
NuxtLabs
Nuxt accessibility — like Next.js — means combining semantic HTML, SSR-first rendering, route announcements on client navigation, and disciplined focus management to achieve WCAG 2.2 AA in a Vue application.
Gatsby
Netlify
Gatsby accessibility relies on accessible React component patterns, gatsby-plugin-image alt props, route-change announcements through @reach/router compat, and content-source discipline (especially around Contentful/Markdown alt text).
Astro
The Astro Project
Astro accessibility comes from its zero-JS-by-default island architecture — most pages ship as plain HTML which is inherently more accessible than client-rendered SPAs — combined with semantic markup in components and accessible interactive islands where used.
Angular
Google
Angular accessibility is supported by the @angular/cdk/a11y module (FocusTrap, LiveAnnouncer, FocusMonitor, AriaDescriber) and Angular Material components — but achieving WCAG 2.2 AA in a complex Angular app still requires deliberate work on routing announcements, modal focus management, and form validation messaging.
React
Meta
React accessibility relies on semantic JSX, library choice (react-aria from Adobe, Radix UI, Headless UI), focus management, and route-change announcements — React itself provides no a11y primitives, so library and pattern discipline determines WCAG 2.2 AA outcomes.
Vue
The Vue Project
Vue accessibility means writing semantic templates, using accessible component libraries (Vuetify, Quasar, Headless UI Vue), managing focus on route changes, and applying focus-trap composables for modals — Vue itself imposes nothing but its template-first approach makes semantic markup natural.
Svelte / SvelteKit
The Svelte Project
Svelte ships built-in accessibility warnings at compile time (missing alt, label-without-control, invalid ARIA) and SvelteKit produces SSR HTML that screen readers can parse immediately — making it among the more accessible-by-default JS frameworks.
Remix
Shopify
Remix accessibility leverages SSR-first React, nested routing (which can announce route changes more naturally), and standard React a11y libraries (react-aria, Radix) — making Remix apps inherit React's strengths and challenges around accessibility while benefiting from server-rendered initial markup.