Accessibility Question

Support
#1

We’re currently reviewing 2 of our websites for accessibility compliance, and a vendor suggested that we may need to replace the theme entirely. Since the site is built on X Theme Pro, I wanted to check with you first.

Is there anything about X Theme Pro/Cornerstone that would prevent a site from meeting WCAG standards? Or are accessibility issues typically more related to the site’s content, PDFs, forms, third-party tools, and how everything is implemented?

I’m trying to understand whether replacing the theme is really necessary, or if accessibility issues can generally be addressed while staying on X Theme.

Thanks in advance for any insight!

#2

Hey @Jennine,

No, you do not need to replace X Theme Pro entirely to achieve WCAG accessibility compliance.

Why Replacing the Theme is Not Necessary

X and its Cornerstone page builder / Pro are fully capable of meeting WCAG compliance standards. While some older themes or page builders historically struggled with generating clean HTML, X/Cornerstone and Pro are continuously updated to output semantic markup, support keyboard navigation, and allow fine-grained control over accessibility attributes.

Replacing a theme is a major, costly undertaking that is rarely necessary for accessibility reasons alone. Almost all common accessibility failures can be remediated while staying on X Theme / Cornerstone or Pro.

Where Accessibility Issues Actually Lie

Accessibility compliance is a shared responsibility between the underlying platform and how the site is designed, implemented, and maintained. The vast majority of WCAG violations on X / Cornerstone / Pro sites are implementation-specific, rather than inherent flaws in the theme code. These include:

  1. Content & Semantic Structure: Missing image alt text, poor contrast ratios between text and backgrounds, and incorrect heading hierarchies (e.g., jumping from an H1 to an H4 or using heading tags for styling rather than structure).
  2. Interactive Elements: Buttons and links built in Cornerstone that lack appropriate keyboard focus states, or custom buttons that are missing descriptive label attributes.
  3. Forms: Contact forms (often built via third-party plugins like Contact Form 7 or Gravity Forms) that lack proper label tags or accessible validation error announcements.
  4. Documents: Non-compliant PDFs and downloads hosted on the site.
  5. Third-Party Tools: Integrated chat widgets, slider plugins, iframe video embeds, and booking systems that fail to support keyboard navigation or screen readers.
#3

How to Achieve Compliance in X /Cornerstone / Pro

Cornerstone provides the precise tools needed to remediate these issues:

  • Custom Attributes: Cornerstone elements allow you to add custom HTML attributes, enabling you to apply custom ARIA roles and labels (e.g., aria-label , role="navigation" , aria-expanded ) directly onto elements without writing custom PHP.
  • Semantic HTML Control: You can manually set the HTML tag for almost all elements in Cornerstone (e.g., switching a div to a section, article, or aside tag).
  • Focus Styles: You can configure keyboard focus indicators (outlines) globally or via custom CSS to ensure keyboard-only users can navigate the site.

Recommendation: Instead of rebuilt-from-scratch migration, request a detailed accessibility audit from your vendor specifying the exact URLs and code-level violations. In almost every case, a developer can fix those specific violations directly within your current X / Cornerstone / Pro setup.

Lastly , you can let us know the violations and we are open to improve the code of X / Cornerstone / Pro.

#4

The vendor has a couple of questions that would help us to figure out next steps. Thank you:

On their interactive components (menus, accordions, tabs, modals, off-canvas), does your JavaScript manage dynamic ARIA state for us? Specifically, do aria-expanded, aria-selected, and aria-hidden update on interaction, or do we only get to set them as static attributes?

For those same components, does your JavaScript handle keyboard behavior: focus trapping in modals, returning focus on close, ESC to close, arrow-key navigation in menus?

When Cornerstone or Pro ships an update, do your built-in components change their DOM structure or class names between releases? If we apply ARIA via custom attributes or target your markup with CSS, will those keep working across updates?

If a fix needs a child-theme template override, how often do those templates change between releases, and is there a changelog or hook system so we know when an override has gone stale?

can you point me to another customer that has similar complex functionality: the site in question is: https://www.snpnyc.org/

#5

Hey Jennine,

1. JavaScript & Dynamic ARIA States

  • Dynamic Management: Yes, X/Cornerstone and Pro’s core JavaScript dynamically manages the ARIA states of its built-in interactive elements (Accordions, Modals, Off-Canvas, and Tabs).
  • State Updates: Attributes such as aria-expanded (on toggle triggers), aria-hidden (on modals/drawers), and aria-selected (on tabs) update dynamically on click or activation.
  • Custom Attributes: If you apply custom aria-* attributes using the Cornerstone Element Settings (under Customize > Attributes), they will output as static attributes. The theme’s core JS will only dynamically update the specific ARIA attributes it natively manages. If you build fully custom components from scratch using HTML blocks, you will need to handle dynamic state updates via custom JS.

2. Keyboard Behavior (Focus Trapping & Escape Key)

  • Focus Trapping & Returning Focus: Yes. Built-in Modals and Off-Canvas elements feature keyboard focus management. When activated, focus is trapped within the active container, and when closed, focus is returned to the triggering element.
  • Escape to Close: Yes, the ESC key is natively supported to close Modals and Off-Canvas panels.
    image
  • Menu Navigation: Core menu elements (Dropdowns, Modals, Collapsed) support standard keyboard sequential tab navigation (Tab and Shift + Tab), and Enter/Space keys to activate buttons/toggles.
  • Arrow-key Menu Navigation: The built-in menus do not natively implement WAI-ARIA arrow-key navigation (moving focus up/down/left/right using arrow keys) by default. If your compliance standards strictly require physical arrow-key menu navigation, you will need to add a supplementary custom JavaScript listener to the menu containers.

3. DOM Stability and Custom Markup Preservation

  • DOM and Class Stability: We are highly committed to backward compatibility. The DOM structure and system class names (e.g., .x-modal, .x-acc, .x-tabs, .x-active) are extremely stable and do not change between minor or patch releases.
  • Major Releases: In major releases where elements are structurally refactored, we keep existing layouts intact by keeping the old elements active as “Legacy Elements” so they do not break.
  • Custom Attributes Persistence: Any custom ARIA attributes or custom CSS classes applied through the Cornerstone interface are saved directly in the page builder’s element database schema. They are fully upgrade-safe and will persist across updates.

4. Template Overrides, Changelogs, and Hooks

  • Template Overrides: Files located in /pro/framework/views/ change very rarely. They remain consistent across minor and patch updates and are only modified in major version upgrades.
  • Stale Overrides: Unlike WooCommerce, Pro does not have a built-in “stale template alert” dashboard. To track stale overrides, developers must review the official Pro Version Release Notes / Changelog, which detail structural modifications.
  • Hook System: Pro features an extensive action and filter hook system. Using WordPress filters and actions in your child theme’s functions.php to adjust markup is highly recommended over copying /framework/views/ template files, as it completely bypasses the risk of template overrides going stale.

Regretfully, we have no data for that because we do not monitor what websites use Pro.