WCAG in RoseaThemes.

WCAG is a set of rules that helps build accessible websites. In short, it follows the POUR model: the interface should be perceivable, operable, understandable, and robust. In most projects, AA is the practical target. A theme alone cannot solve all WCAG requirements, but it can help a lot.

What the theme actually controls in Moodle

The theme controls the interface layer: layout, navigation, typography, colors, focus states, and part of the system templates. I decide whether users can quickly skip to content and whether the heading structure is logical.

What the theme will not solve

I do not control everything. Course content, video captions, PDF quality, custom plugins, and extra scripts are outside the theme itself. The same goes for client configuration, for example brand colors with poor contrast.

What this page is — and what it is not

This page is a description of my approach to accessibility. It is not a certificate and not a legal guarantee of full platform compliance. In the end, testing on a real setup and real content is always required.

There are widgets that promise “quick WCAG compliance”. They may help in isolated cases, but they do not fix the root cause: weak HTML, broken labels, and keyboard issues.

Typical limits of widgets

• Semantics Semantics remain unchanged — empty alt text and wrong headings do not disappear after enabling a widget.
• Focus Focus can break — extra layers can create focus traps and confusion for screen readers.
• Script It is extra script weight — it can slow down the page and require additional consent.
• Risk It creates a false sense of completion — without testing and process, issues remain.

Why a solid theme comes first

That is why I first build a strong foundation in the theme itself: clear HTML, clear labels, visible focus, and predictable navigation. A widget can be an addition, but not a replacement for code and content quality.

This is how I apply WCAG principles in day-to-day work on Moodle and IOMAD themes.

Landmarks and regions

I use semantic containers (<header>, <nav>, <main>, <footer>) and clear region labels. This helps screen reader users navigate faster.

Headings and content order

I keep heading hierarchy consistent and content order logical. This significantly improves navigation in NVDA, JAWS, and VoiceOver.

Skip link and first focus target

I make sure “Skip to main content” is the first meaningful keyboard target. It saves time and reduces friction.

Keyboard, focus, and sliders

I test interactive components with keyboard controls: Escape closes layers, focus never disappears, and :focus-visible remains clear. I keep aria-live messages short and precise.

ARIA: support, not a replacement

I treat ARIA as support. I use it for dynamic states and label relationships, but I do not add ARIA where proper HTML is enough.

Images, icons, hidden text

I hide decorative icons from assistive tech. Icon-only buttons get clear names. For links that open new tabs, I add explicit information.

A screen reader does not “see” layout the way people do. It reads HTML structure and roles. That is why correct HTML matters more than visuals alone.

Typical user flow

1. After landing on a page, the first Tab usually reaches the skip link.
2. Then users move to main or jump by headings.
3. Then they navigate content in source order.
4. Dynamic announcements (aria-live) should be short.

Moodle: a second layer of complexity

In Moodle, modules, blocks, and plugins add extra complexity. The theme improves consistency, but it does not control all HTML generated by every activity. That is why I always test both the theme and a real course.

Symptoms of weak structure (what users actually hear)

• Regions Multiple “navigation” regions with no distinction.
• Images Empty or misleading image descriptions (alt).
• Links “Click here” links with no context.
• Focus Focus disappears after opening a menu.

In my themes, I reduce these issues where I have control. I cannot automatically remove them from content and third-party plugins.