Joomla accessibility is more achievable than most site builders assume, because Joomla 4 and 5 ship with accessibility baked into the core. The default Cassiopeia template, the Atum admin, and the Accessible Media plugin all give you a head start. But "head start" is not "done": your template tweaks, image handling, color palette, and form extensions decide whether your site actually meets WCAG 2.2 Level AA, the baseline the European Accessibility Act now requires.
This guide walks Joomla builders through the parts you control: choosing or overriding templates, using the built-in accessibility features properly, vetting extensions, getting alt text and forms right, and the specific success criteria to verify before you call a site compliant.
Start with the template: Cassiopeia and overrides
Your template determines most of your accessibility outcomes because it produces the page structure, focus styles, and color tokens. Joomla's default front-end template, Cassiopeia, was built with accessibility in mind: it includes a skip-to-content link (satisfying 2.4.1 Bypass Blocks), ARIA landmark roles, a keyboard-operable navigation menu, and visible focus outlines. The Atum administrator template is similarly accessible, which matters if non-technical editors will manage content.
Where teams go wrong is overriding those defaults. If you swap Cassiopeia for a flashy third-party template, verify it still ships a skip link, real heading order, and focus indicators. When you need to fix markup a template generates, use Joomla's template override system (copy the layout into /templates/yourtemplate/html/) rather than hacking core files, so updates don't wipe your fixes. Common overrides: restoring a visible focus style so it meets 2.4.7 Focus Visible and is not hidden behind a sticky header (2.4.11 Focus Not Obscured, Minimum), or correcting a heading that a module outputs as a div.
Audit your palette against the contrast thresholds early: 4.5:1 for normal text, 3:1 for large text (18pt, or 14pt bold) and for UI components and focus indicators. Brand colors that look fine on a mockup often fail. Run swatches through a tool like the contrast checker before you commit them to template variables.
Use Joomla's built-in accessibility features
Joomla core gives you more than the template. Knowing where these settings live saves you from reaching for extensions you don't need.
- Accessible Media plugin: enabled by default, it adds the alt and figure caption fields to the image insert dialog and lets you mark images as decorative (empty alt), directly supporting WCAG 1.1.1.
- Language tags: set the site language in Global Configuration so every page carries a correct lang attribute (3.1.1 Language of Page). For multilingual sites, Joomla's built-in language associations let you mark content language so screen readers switch pronunciation (3.1.2 Language of Parts).
- Menu and module structure: Joomla outputs nav menus as real lists with links, and module positions map to landmarks in Cassiopeia, giving screen reader and keyboard users a navigable structure.
- Editor choice: the bundled editors expose heading levels and a list of inserted images, so editors can keep a logical heading hierarchy instead of styling text to look like a heading.
None of these are automatic. The plugin gives you the alt field; you still have to fill it in. The lang attribute is only correct if Global Configuration matches your actual content language.
Vetting extensions (and avoiding overlay traps)
Every extension you install can add inaccessible markup: a slider module with no keyboard support, an unlabeled search field, a cookie banner that traps focus, or a gallery that fires on hover only. Before installing, check whether the extension renders keyboard-operable controls, real labels, and ARIA only where needed. Test it with the Tab key and a screen reader, not just a mouse.
Be skeptical of "accessibility" extensions that inject an overlay toolbar promising one-click compliance. These add contrast and font-size toggles on top of your site but do not fix the underlying HTML, so they leave real barriers (missing labels, low-contrast components, broken keyboard order) in place, and they can create new problems. Genuine Joomla accessibility comes from accessible templates and correct content, not a widget. For forms specifically, prefer extensions that output a programmatically associated label for every field and accessible error messages.
Alt text and forms: where Joomla sites usually fail
Two areas account for a large share of Joomla accessibility failures: images and forms.
Alt text
Joomla's Media Manager and image dialog include an alt field, but it's optional, so it's frequently left empty. Write alt text that conveys the image's purpose in context, not the filename. A product photo on a shop page needs descriptive alt; a purely decorative divider should use an explicit empty alt (alt="") so assistive tech skips it (1.1.1 Non-text Content). Joomla article intro/full images have their own alt option in the article's Images and Links tab, which editors often miss.
Forms
Whether you use the core Contact component or a form extension, verify each field has a real, programmatically associated label (not just placeholder text), required fields are indicated in text, and errors are identified clearly with suggestions for fixing them (3.3.1 Error Identification, 3.3.3 Error Suggestion). WCAG 2.2 adds two criteria forms must respect: 3.3.7 Redundant Entry (don't force users to re-enter info they already gave) and 3.3.8 Accessible Authentication (Minimum) (don't rely on a cognitive function test, like solving a puzzle or transcribing characters, to log in).
What to verify for WCAG 2.2 AA and the EAA
The European Accessibility Act (Directive (EU) 2019/882) applies from 28 June 2025, and its technical baseline via EN 301 549 is WCAG 2.2 Level A and AA. If your Joomla site sells products or services to EU consumers, this is your target. The same WCAG 2.2 AA bar is the de-facto reference for ADA expectations in the US (the ADA itself names no WCAG version), while Section 508 and Ontario's AODA are tied to WCAG 2.0 AA. Here is a focused checklist for a Joomla build:
- Keyboard: every menu, slider, modal, and form control is operable with Tab/Enter/Escape, focus is always visible (2.4.7), and not hidden behind sticky headers (2.4.11).
- Target size: interactive controls (menu toggles, pagination, social icons) are at least 24x24 CSS pixels or have adequate spacing (2.5.8).
- Dragging: any drag interaction (sliders, sortable galleries) has a single-pointer alternative (2.5.7).
- Contrast: text and UI components meet 4.5:1 / 3:1 across every template color state, including hover and focus.
- Headings and landmarks: one logical heading order per page; landmarks come through from your template, not faked with styled text.
- Status messages: AJAX results (search, cart updates, form submission confirmations) are announced to screen readers (4.1.3).
- Help and consistency: support links, contact info, and help are in a consistent place (3.2.6 Consistent Help).
- Language: correct lang on the page (3.1.1) and on any content in another language (3.1.2).
Note WCAG 2.2 removed 4.1.1 Parsing, so minor markup validation quirks no longer count against you, but the new criteria above do. Automated tools catch contrast, missing alt, and label problems quickly; keyboard order, focus visibility, and screen reader announcements need manual testing. Run a free scan with the AccessScan checker, work through a full accessibility checklist, and when you're ready to publish, generate a starting accessibility statement that documents your conformance and contact route, something the EAA expects. For the legal landscape across regions, see the overview of the EAA, EN 301 549, and related laws.