CMS Accessibility Guides: WordPress, Shopify, and Other Platforms

Your choice of content management system has a significant impact on how accessible your website can be. Some platforms provide strong accessibility foundations out of the box, while others require substantial manual effort. Understanding the accessibility strengths and limitations of your CMS helps you make informed decisions — from initial platform selection to daily content management.

This guide covers practical accessibility considerations for the most popular CMS platforms, including specific features, common pitfalls, and actionable steps you can take regardless of which platform you use.

Why CMS Choice Matters for Accessibility

A CMS influences your website's accessibility in three fundamental ways: the quality of its core output (the HTML it generates by default), the ecosystem of themes and plugins available, and the content editing experience it provides to your team.

• Core HTML output — Some platforms generate clean, semantic HTML with proper heading structures, landmark regions, and ARIA attributes. Others produce div-heavy markup that lacks meaningful structure.
• Theme and template ecosystem — The availability of accessibility-tested themes determines your starting point. A platform with strict theme review standards gives you a stronger baseline than one where themes are unreviewed.
• Plugin and extension ecosystem — Third-party plugins can either enhance or break accessibility. Platforms with larger ecosystems tend to have more accessibility-focused extensions, but also more plugins that introduce barriers.
• Content editing experience — The editor interface itself determines how easily content creators can add alt text, set heading levels, create descriptive links, and follow other accessibility best practices.
• Built-in accessibility features — Some CMS platforms include accessibility tools like skip links, focus management, and keyboard navigation as core features. Others leave these entirely to theme developers.

No CMS can guarantee an accessible website on its own — content quality and design decisions always matter. But starting with a platform that prioritizes accessibility reduces the effort required to reach and maintain WCAG compliance.

WordPress Core Accessibility Features

WordPress powers a significant share of the web and has made meaningful strides in accessibility. The WordPress Accessibility Team actively works to improve the core platform, and several built-in features support WCAG compliance.

• Skip links — WordPress themes that follow the accessibility-ready standards include skip-to-content links that allow keyboard users to bypass repetitive navigation and jump directly to the main content.
• ARIA landmarks — Core WordPress templates use ARIA landmark roles and HTML5 semantic elements (header, nav, main, footer) to define page regions for assistive technology users.
• Focus management — WordPress manages focus states for interactive elements in the admin interface and encourages theme developers to implement visible focus indicators on the front end.
• Admin accessibility — The WordPress admin dashboard is designed to be keyboard navigable and screen reader compatible, so content editors with disabilities can manage their sites.
• Media library alt text — The media library includes a dedicated field for alt text on images, making it straightforward for content creators to add descriptive text when uploading media.

Choosing Accessible WordPress Themes

Not all WordPress themes are created equal when it comes to accessibility. The WordPress theme directory includes an "accessibility-ready" tag that indicates a theme has passed specific accessibility review criteria. These criteria include:

• Skip links present and functional
• Keyboard navigation support for all interactive elements
• Correct use of heading hierarchy (no skipped levels)
• Sufficient color contrast ratios (minimum 4.5:1 for normal text)
• Visible focus indicators on all focusable elements
• Proper form labeling with associated label elements
• No content conveyed through color alone
• Responsive design that works across viewport sizes
• Proper use of ARIA attributes where needed

When evaluating a theme, look beyond the accessibility-ready tag. Test the theme demo with a keyboard to verify that all interactive elements are reachable and operable. Use a screen reader to check that content is announced in a logical order. Inspect the generated HTML to confirm semantic structure.

Premium themes from third-party marketplaces do not go through the same review process. If you purchase a theme outside the WordPress directory, you will need to conduct your own accessibility testing or rely on the developer's documentation and claims.

Block Editor (Gutenberg) Accessibility

The WordPress block editor (Gutenberg) provides several built-in mechanisms that support accessible content creation, but it also requires awareness from content editors to use them effectively.

• Heading hierarchy — The heading block allows you to select heading levels (H2 through H6). Content creators must ensure they maintain a logical hierarchy — starting with H2 for main sections (since H1 is typically the post title) and nesting subsequent levels without skipping. The block editor does not enforce this automatically.
• Image alt text — When inserting an image block, the editor prompts for alt text in the block settings panel. Content creators should write descriptions that convey the purpose and content of the image, not just its filename.
• Link text — When creating links, the block editor allows you to set meaningful link text. Avoid generic phrases like "click here" or "read more" — instead, use text that describes the destination or purpose of the link.
• List blocks — Using proper list blocks (ordered and unordered) instead of manually typing bullet characters ensures that screen readers announce list structures correctly.
• Table accessibility — The table block allows you to designate a header row, which is essential for screen reader users to understand table data relationships.

The block editor itself has received significant accessibility improvements for authors who use assistive technology. Keyboard navigation between blocks, screen reader announcements for block operations, and accessible toolbar controls have all been enhanced in recent releases.

WordPress Accessibility Plugins

Several plugins can help improve the accessibility of your WordPress site. These should complement — not replace — a well-built accessible theme and good content practices.

• WP Accessibility — Adds various accessibility fixes including skip link insertion, removal of tab index from elements, enforcement of alt text on images, and toolbar options for font size and contrast adjustments. Useful as a quick improvement layer for themes that lack built-in accessibility features.
• Jenga Accessibility — Provides an accessibility overlay with adjustable text size, contrast modes, and other user-facing adjustments. Note that accessibility overlays are not a substitute for building accessibility into the site's code and design.
• Accessibility Checker plugins — Several plugins provide on-page accessibility auditing within the WordPress editor, flagging issues like missing alt text, empty headings, or insufficient contrast as you create content.

When evaluating accessibility plugins, be cautious of tools that promise to make your site fully compliant through a single installation. Genuine accessibility requires structural and content-level work that no plugin can fully automate. Use plugins as tools that assist your accessibility efforts, not as replacements for proper implementation.

Common WordPress Accessibility Issues

Despite WordPress's accessibility efforts, several common patterns frequently introduce barriers:

• Slider and carousel plugins — Most slider plugins produce inaccessible content: auto-advancing slides that cannot be paused, missing keyboard controls, no screen reader announcements for slide changes, and content that is invisible to assistive technology. If you must use a slider, choose one that explicitly supports WCAG requirements, and always provide a pause button.
• Page builder plugins — Visual page builders often generate deeply nested, non-semantic HTML with excessive div elements and inline styles. This can break heading hierarchy, obscure content structure, and create keyboard navigation difficulties. Test any page builder output thoroughly with assistive technology.
• Contact form plugins — Some form plugins generate forms without proper label associations, missing error messaging, or inaccessible CAPTCHA implementations. Verify that your chosen form plugin associates labels with inputs using the for/id pattern and provides clear, programmatically connected error messages.
• Lightbox and modal plugins — Many lightbox implementations fail to manage focus properly, trap keyboard users, or provide close mechanisms accessible via keyboard and screen reader.
• Social media widgets — Embedded social feeds and sharing buttons frequently lack alt text, keyboard access, and proper ARIA labels.

WordPress Accessibility Settings

WordPress includes several settings that support accessibility, though they are not always prominently featured in the interface:

• Reduced motion — WordPress respects the prefers-reduced-motion media query in its admin interface, reducing animations for users who have enabled this preference in their operating system settings. Themes should also honor this preference on the front end.
• Screen reader text classes — WordPress provides the screen-reader-text CSS class for visually hiding content while keeping it available to screen readers. This is used for skip links and other assistive text throughout WordPress core.
• Admin color schemes — The admin interface offers multiple color schemes. While these are primarily aesthetic, they can help administrators with visual preferences or needs find a comfortable working contrast level.

Shopify Built-in Accessibility Features

Shopify has increasingly invested in accessibility for its e-commerce platform. The platform provides a foundation that includes several accessibility-relevant features, though merchants still need to make conscious choices to maintain accessibility throughout their stores.

• Semantic HTML in core themes — Shopify's first-party themes use semantic HTML5 elements and proper ARIA roles to structure page content.
• Skip links — Official Shopify themes include skip-to-content links for keyboard users.
• Focus management — Cart interactions, modal dialogs, and other dynamic elements in modern Shopify themes include focus management to maintain keyboard operability.
• Responsive images — Shopify's image handling supports responsive images with lazy loading, and the theme editor exposes alt text fields for all image uploads.
• Structured product data — Product pages include structured data markup that supports both search engines and assistive technology in understanding product information.

Choosing Accessible Shopify Themes

Shopify's theme store includes both free and paid themes with varying levels of accessibility. The Dawn theme, Shopify's default free theme, serves as a strong accessibility baseline and is worth evaluating before considering alternatives.

• Dawn theme — Built with accessibility as a priority, Dawn uses semantic HTML, includes skip links, supports keyboard navigation throughout, and maintains proper heading hierarchy. It serves as a reference implementation for how Shopify themes should handle accessibility.
• Theme store evaluation — When evaluating themes, test the demo store with keyboard-only navigation. Check that product filtering, variant selection, and the cart workflow are all keyboard operable. Verify that the theme maintains heading hierarchy across different page types.
• Custom themes — If you commission a custom Shopify theme, include WCAG 2.1 AA compliance as a requirement in your brief. Provide specific acceptance criteria including keyboard navigation, screen reader compatibility, and color contrast requirements.

Product Page Accessibility on Shopify

Product pages are the core of any e-commerce site and require particular attention to accessibility:

• Product images and alt text — Every product image should have descriptive alt text that conveys what the image shows. For product photos, describe the product's appearance, color, and any relevant details. Shopify's admin makes it straightforward to add alt text when uploading product images.
• Variant selectors — Size, color, and other variant selectors must be keyboard operable and properly labeled. Screen reader users need to understand which variant they are selecting and receive confirmation of their selection. Custom variant selectors built with JavaScript must include appropriate ARIA attributes.
• Add to cart functionality — The add-to-cart button and any quantity selectors must be keyboard accessible. After adding an item to the cart, provide clear feedback — either through a visible confirmation message or by moving focus to a cart summary notification.
• Price and availability — Sale prices should be structured so screen readers announce both the original and discounted price, with proper labeling. Out-of-stock status should be conveyed programmatically, not just through visual styling.
• Product descriptions — Use proper heading hierarchy within product descriptions and avoid embedding critical information in images without corresponding text.

Shopify Checkout Accessibility

Shopify's hosted checkout is managed by Shopify itself and is generally accessible. This is actually an advantage — because Shopify controls the checkout experience, merchants benefit from accessibility improvements made by Shopify's team without needing to implement changes themselves.

Key aspects of Shopify's checkout accessibility include form field labeling, error messaging with clear descriptions, keyboard navigability through all checkout steps, and support for autofill to reduce manual input. Shopify Plus merchants who customize checkout should be especially careful to maintain these accessibility features when modifying the checkout flow.

Shopify App Accessibility Concerns

Shopify apps are a common source of accessibility issues because they inject third-party code into your storefront:

• Review widgets — Product review apps often render with inaccessible star rating components, missing form labels, and keyboard traps in review modals.
• Live chat widgets — Chat popups frequently lack proper focus management, ARIA roles, and keyboard close mechanisms.
• Upsell and recommendation widgets — Product recommendation carousels and upsell popups often fail keyboard accessibility and screen reader compatibility.
• Pop-up and notification apps — Email signup popups, notification bars, and promotional overlays are frequent accessibility offenders with missing focus management and dismiss controls.

Before installing any Shopify app, test it on a development store with keyboard navigation and a screen reader. Ask app developers about their WCAG compliance status. Prioritize apps from developers who explicitly document their accessibility support.

Liquid Template Tips for Accessibility

If you are developing or customizing Shopify themes using Liquid templates, several practices will improve accessibility:

• Always output image alt text: {{ image.alt | escape }} and ensure empty alt (alt="") is used for decorative images.
• Use Shopify's section and block architecture to maintain consistent heading hierarchy across customizable sections.
• Include aria-label attributes on navigation elements and icon-only buttons that lack visible text.
• Use Liquid's translation system ({{ 'general.accessibility.skip_to_content' | t }}) to provide translatable accessibility strings.
• Implement proper aria-live regions for cart count updates, filtering results, and other dynamic content changes.
• Use the prefers-reduced-motion media query to respect user animation preferences in CSS transitions and JavaScript animations.

Wix Accessibility

Wix has made significant efforts to improve accessibility, most notably through its Accessibility Wizard — a built-in tool that guides site owners through key accessibility settings and fixes.

• Wix Accessibility Wizard — This tool walks you through adding alt text to images, setting heading hierarchy, adding descriptive link text, and configuring other accessibility features. It provides a structured workflow that makes accessibility more approachable for non-technical users.
• Accessible templates — Wix has updated many of its templates to include semantic structure, skip links, and keyboard navigation support.
• Alt text management — The Wix editor includes alt text fields for all image elements and provides reminders when alt text is missing.

However, Wix has notable limitations. The platform generates complex DOM structures with deeply nested elements, which can confuse assistive technology. Custom animations and interactions built with the Wix editor may not respect reduced motion preferences. Third-party Wix apps face the same accessibility concerns as Shopify apps — they inject code that may not meet accessibility standards.

Additionally, because Wix controls the underlying HTML output, you have limited ability to fix structural accessibility issues. If the platform generates inaccessible markup for a particular component, your options for remediation are restricted compared to platforms that give you full code access.

Squarespace Accessibility Considerations

Squarespace provides a polished, design-focused website building experience with moderate accessibility support:

• Template structure — Squarespace templates use semantic HTML and include basic accessibility features like skip links and ARIA landmarks in their newer template versions (7.1).
• Image handling — Alt text fields are available for all images, though the editing interface does not prominently encourage their use. Content creators need to actively navigate to image settings to add alt text.
• Built-in forms — Squarespace's native form blocks generally include proper label associations, though custom styling can sometimes obscure visual labels.
• Limited customization — Like Wix, Squarespace limits your control over the generated HTML. You can inject custom code through code blocks and the header/footer injection areas, but you cannot modify the core template markup. This means structural accessibility issues at the template level are largely out of your control.
• Navigation — Squarespace's navigation components support keyboard access and include proper ARIA attributes in version 7.1 templates. Dropdown menus are generally keyboard operable.

Squarespace is a reasonable choice for simpler websites where you need a professional appearance and are willing to work within the platform's constraints. For complex sites with extensive interactive features or strict compliance requirements, the limited customization options may become a barrier to achieving full WCAG conformance.

Webflow and Custom Code Control

Webflow occupies a unique position among visual website builders because it gives designers direct control over the HTML structure, CSS, and interactions — while still providing a visual design interface.

• Semantic HTML control — Webflow allows you to choose which HTML element to use for each component (div, section, article, nav, etc.), giving you the ability to create properly structured, semantic markup.
• ARIA attribute support — You can add custom ARIA attributes to any element through the element settings panel, enabling proper labeling of interactive components.
• Custom interactions — Webflow's interaction system lets you build animations and transitions, but you must manually implement reduced motion support and ensure that interactions do not create keyboard traps or disorienting effects.
• Focus states — You can design custom focus states for interactive elements using Webflow's state-based styling, ensuring visible focus indicators that match your design system.
• Clean code output — Webflow generates relatively clean HTML compared to other visual builders, which benefits both accessibility and performance.

Webflow's strength is that it gives you the tools to build accessibly — but it does not enforce accessibility. Unlike a CMS that generates semantic markup automatically, Webflow requires deliberate choices at every step. A Webflow site built without accessibility awareness can be just as inaccessible as any other poorly built site. The platform provides the capability, not the guarantee.

Headless CMS and Frontend Responsibility

Headless CMS platforms (Contentful, Sanity, Strapi, and others) separate content management from presentation entirely. The CMS stores and delivers content through an API, while a separate frontend application (often built with React, Next.js, Gatsby, or similar frameworks) handles rendering.

This architecture shifts accessibility responsibility almost entirely to the frontend implementation:

• Content structure — The headless CMS defines content models and fields. Including dedicated fields for alt text, heading levels, and ARIA labels in your content models ensures that content editors can provide the accessibility data your frontend needs.
• Frontend rendering — The frontend framework is responsible for generating semantic HTML, managing focus, handling keyboard interactions, and implementing ARIA patterns. None of this comes from the CMS.
• Client-side routing — Single-page applications built with React or similar frameworks must manage focus when navigating between routes, announce page changes to screen readers, and ensure that dynamically loaded content is accessible.
• Static site generation — Frameworks like Next.js and Gatsby can generate static HTML, which generally benefits accessibility by providing content that is available without JavaScript. However, interactive components still require careful accessibility implementation.

With a headless CMS approach, your development team must have accessibility expertise. There is no theme or template to provide a baseline — every accessibility feature must be intentionally built. This gives you maximum control but also maximum responsibility.

General CMS Accessibility Checklist

Regardless of which CMS you use, the following checklist covers the essential accessibility considerations that apply across all platforms.

Theme and Template Selection

• Verify the theme uses semantic HTML5 elements (header, nav, main, footer, article, section)
• Check for a logical heading hierarchy that does not skip levels
• Test all interactive elements with keyboard-only navigation
• Confirm visible focus indicators are present on all focusable elements
• Verify color contrast meets WCAG AA minimums (4.5:1 for normal text, 3:1 for large text)
• Check that the theme includes skip-to-content links
• Test the theme with a screen reader to verify content is announced logically
• Confirm the theme is responsive and content reflows properly at 320px width
• Verify that the theme does not auto-play audio or video

Content Entry Best Practices

• Add descriptive alt text to every informative image — describe what the image shows and why it matters
• Use empty alt attributes (alt="") for purely decorative images
• Maintain heading hierarchy — do not use headings for visual styling
• Write descriptive link text that makes sense out of context
• Use proper list markup instead of manually formatted bullet points
• Provide captions and transcripts for video and audio content
• Use tables only for tabular data and include header rows
• Write in plain language appropriate for your audience
• Ensure sufficient contrast when choosing text and background colors in the editor

Plugin and Extension Evaluation

• Test any plugin's front-end output with keyboard navigation before installing on your live site
• Check that plugin-generated forms have proper label associations
• Verify that modals and popups include focus management and keyboard-accessible close controls
• Confirm that dynamic content updates are announced to screen readers via ARIA live regions
• Review the plugin developer's accessibility documentation or compliance statements
• Test plugin output across different screen readers (NVDA, JAWS, VoiceOver) when possible
• Avoid plugins that inject accessibility overlay widgets as a compliance strategy

Regular Auditing Workflow

• Run automated accessibility scans after every major content or design update
• Conduct keyboard-only navigation testing of key user flows monthly
• Perform screen reader testing of critical pages quarterly
• Review new content for alt text, heading structure, and link text quality as part of your editorial workflow
• Test with real users who have disabilities when possible, especially before major launches
• Document known issues and track remediation progress
• Monitor CMS updates and plugin changelogs for accessibility-related changes
• Re-audit after CMS version upgrades, theme updates, or significant plugin changes

How Passiro Helps Regardless of CMS

No matter which CMS or platform you use to build your website, Passiro scans your live pages against WCAG criteria and identifies accessibility issues in the rendered output — the HTML that your visitors and assistive technology actually encounter. This means Passiro catches issues introduced by your theme, your plugins, your content, and your custom code, all in one scan.

Passiro pinpoints exactly where issues occur on each page with visual highlighting, making it straightforward to trace problems back to the responsible theme component, plugin, or content block in your CMS. Whether you are managing a WordPress blog, a Shopify store, a Squarespace portfolio, or a custom-built application, regular scanning helps you maintain accessibility as your site evolves and content changes over time.