Accessibility standards #

This page is for developers who build or review templates, and for administrators who must answer the question "is Exponential accessible?" for a procurement, an audit or their own users. It lists the accessibility standards that apply to a web content management system, says for each one what Exponential 6.0.x does, points to the files and tests that show it, and names the gaps honestly.

Note Exponential is software. Whether a site built with it is accessible also depends on its own design, its templates and the content its editors publish. The statements below are about the parts that ship with Exponential.

Summary #

WCAG 2.2 #

What it is #

The Web Content Accessibility Guidelines 2.2 are a W3C Recommendation (first published October 2023), published by the W3C Web Accessibility Initiative. Level AA is the level that laws and procurement rules usually require. WCAG 2.2 adds nine success criteria to WCAG 2.1, among them 2.4.11 Focus Not Obscured, 2.5.7 Dragging Movements and 2.5.8 Target Size (Minimum).

How Exponential complies #

The work concentrates on the admin4 administration design (design/admin4/) and its layout variant admin4l (design/admin4l/). It is described in the admin4 design and in the contributor reference admin4 styling. The design tests run without a database in the design test suite of phpunit.xml (tests/tests/design/), which the PHPUnit workflow (.github/workflows/phpunit.yml) runs with every suite of phpunit.xml.

The help system follows the same rules: one h1 per page, named navigation landmarks, labeled search fields, a visible focus ring, a note on links that open a new window, and search results announced to screen readers (Help system: Languages and accessibility).

A count of the ARIA attributes in design/admin4/templates/ (October 2026) gives an idea of the coverage: about 400 aria-labelledby, 390 aria-hidden, 380 aria-label, 215 aria-describedby, 110 aria-current and 65 aria-live uses.

Automated checks with the axe engine are run by hand during reviews, not in CI. Their results are recorded in the 6.0.15 changelog: for example "axe reports no serious finding in the page frame on 10 classic pages at 1440 px and at 960 px with 200 % zoom" (classic admin, #522), 13 serious findings on the standard content edit form fixed, a target-size failure and a forced-colors contrast failure fixed.

Status #

Partly complies. The admin4 and admin4l administration is designed and regression-tested against WCAG 2.2 AA criteria. That is not the same as a conformance claim: there is no full audit of every page, no assistive technology test log, and several parts of the product were not reviewed (see below).

Known gaps #

• Public site designs are not audited. design/standard, design/base, design/plain, design/mysite and the site designs that come as packages (ezwebin, the media themes, starter sites) have had only targeted fixes (the standard content edit form). Their accessibility is the site builder's responsibility.
• Classic administration (design/admin) and admin3 received label and narrow-window fixes, but they are not covered by the contrast, landmark and form-error tests that hold admin4.
• Online editor. The TinyMCE 8 and TinyMCE 3 integrations (extension/ezoe) were not audited for WCAG; the editor engine's own accessibility is that of the TinyMCE project. Unverified.
• Extensions shipped as separate packages (layouts editor, newsletter, shop) are reviewed one by one; some fixes are recorded in the changelog, there is no overall statement.
• No automated accessibility engine in CI. The tests read template and stylesheet sources; they do not render pages in a browser. axe runs are manual.
• No published conformance report (WCAG-EM evaluation, VPAT or Accessibility Conformance Report).
• Content. Alternative text, heading order and link text in published content depend on editors. The image datatypes offer an alternative text field; nothing forces editors to fill it.

WAI-ARIA 1.2 and the ARIA Authoring Practices #

What it is #

Accessible Rich Internet Applications (WAI-ARIA) 1.2 is a W3C Recommendation (June 2023) that defines roles, states and properties for assistive technologies. The ARIA Authoring Practices Guide (APG), a W3C WAI note, shows how to build common widgets (tabs, menus, disclosures, dialogs) with them.

How Exponential complies #

• Tabs pattern: node tabs in admin4 (design/admin4/javascript/node_tabs.js), held by tests/tests/design/AdminKeyboardTest.php.
• Disclosure navigation: the opt-in mega menu (menu.ini [TopAdminMenu] MegaMenuTabs[]) keeps the tab a link and adds a button with aria-expanded beside it (tests/tests/design/AdminMegaMenuTest.php).
• Menu: the context menus (ezpopupmenu.js) have roles and keyboard support (tests/tests/design/AdminContextMenuTest.php).
• Toggle buttons: aria-pressed for the editor engine switch and segmented controls (TinyMCE 8).
• Live regions: toasts and help search results (aria-live).
• First rule of ARIA: native elements are preferred. The form-label test does not accept a title as a name, and aria-label must not replace a visible label that has text (AdminFormLabelsTest.php).

Status #

Partly complies for admin4 and admin4l, where the patterns are tested on the template sources. Unverified elsewhere; classic designs still contain older JavaScript widgets.

Known gaps #

• The tests check markup and the hooks the scripts use, not the runtime behavior in a screen reader.
• No test lists every widget against its APG pattern.

EN 301 549 #

What it is #

EN 301 549 "Accessibility requirements for ICT products and services", v3.2.1 (2021-03), published by ETSI, CEN and CENELEC. It is the harmonized standard of the EU Web Accessibility Directive (2016/2102) and the reference for the European Accessibility Act (2019/882). Its clause 9 (web) incorporates WCAG 2.1 level AA; clause 11 (software) and clause 12 (documentation and support) apply to authoring tools as well.

How Exponential complies #

The WCAG 2.2 AA work on admin4 covers the WCAG 2.1 AA criteria that clause 9 requires (WCAG 2.2 is a superset, except for 4.1.1 Parsing, which 2.2 removed). The documentation of the help system follows the same rules.

Status #

Unverified. No evaluation against EN 301 549 has been made, and clause 11.8 (authoring tools, for example that the tool helps authors produce accessible content) has not been reviewed.

Known gaps #

• No accessibility statement template for sites, as the Web Accessibility Directive requires of public bodies.
• Clause 11.8 (authoring tool support: prompts for alternative text, accessible output of rich text) not assessed.

Section 508 #

What it is #

Section 508 of the US Rehabilitation Act requires federal agencies to procure accessible ICT. The Revised 508 Standards (US Access Board, 2017) incorporate WCAG 2.0 level AA by reference. Vendors usually document conformance in a VPAT (Voluntary Product Accessibility Template), which produces an Accessibility Conformance Report.

How Exponential complies #

In substance through the WCAG work above; WCAG 2.0 AA is a subset of what admin4 is tested against.

Status #

Unverified. There is no VPAT or Accessibility Conformance Report for Exponential.

For template authors #

• Follow admin4 styling: shared components (.a4-btn, .a4-card, .a4-sr-only), tokens only, a dark value for each new color token, no inline CSS.

• Run the design tests after a template change:

  php vendor/bin/phpunit --testsuite design

• Check a changed page in light and dark mode, at 1440 px and at 960 px with 200% zoom, and with the keyboard alone.

Related pages #

• Security standards, Privacy standards, Web platform standards
• The admin4 design
• Right-to-left languages
• Keyboard shortcuts