Keyboard shortcuts and in-page sections

RoseaThemes
Space Moodle Theme

WCAG accessibility summary — Space Moodle Theme

How theme_space improves accessibility in theme-owned surfaces—and what still depends on Moodle Core, content, and plugins.

WCAG accessibility summary

This document is an English overview of how theme_space supports accessible Moodle experiences.

For the full, maintained inventory of overrides and features (including a WCAG 2.1 mapping table and changelog), see docs/wcag-features.md (currently mostly in Polish).

Positioning

theme_space is designed to improve accessibility, not to certify an entire Moodle site. WCAG conformance also depends on Moodle Core (forms, activities, modals, unoverridden templates), course content, third-party plugins, media, colour contrast of custom branding, and site configuration.

What the theme does control is a large set of deliberate markup and interaction fixes in theme-owned templates: real <button> controls instead of fake <a href="#"> triggers, clearer ARIA where overrides exist, skip links and keyboard flows for drawers, and reduced redundant accessible naming. These align with common WCAG 2.1 success criteria only where the theme replaces or extends Core/plugin markup.

Where a screen is still rendered by Moodle Core or a plugin without a theme override, the theme cannot change it. Those behaviours are documented below as Moodle Core dependencies.

Overall assessment

Theme contribution by accessibility aspect
AspectRating (theme contribution)Notes
Keyboard & focus Strong Theme: skip links, drawer toggles as buttons, coordination between nav drawer and fixed drawers. Moodle Core: FocusLock (core/local/aria/focuslock), modals and focus order on pages the theme does not override.
Semantics & roles Strong Theme: button + appropriate aria-* / role in overridden templates. Moodle Core / plugins: legacy anchors and roles on unoverridden activity and admin screens.
Bypass blocks Strong Theme: configurable skip links to main content, main navigation, block drawer, course index (when present), and footer (#s-page-footer). Targets follow theme layout—not every Core-only page variant.
Non-text content Good Theme: decorative SVGs marked aria-hidden in overridden templates; fixes for duplicate alt/title where the theme owns markup. Moodle Core / content: alt text and captions in courses and activities.
Forms & labels Mixed Theme: limited template-level improvements. Moodle Core: moodleform output, validation messages, required-field semantics, and activity-module forms—the theme cannot redefine these.
Contrast & typography Configurable Theme: tokens and SCSS for branding. Administrator / content: contrast of custom colours and text in course materials.

Ratings describe what theme_space adds in theme-owned surfaces, not a formal audit score. Items marked Moodle Core are outside direct theme control.

Depends on Moodle Core

The following behaviour is delivered or controlled by Moodle Core (and sometimes plugins). theme_space cannot change it unless Moodle provides a theme override point or the project documents a paired Core/plugin patch.

  • Activity and course screens — Quizzes, forums, workshops, the gradebook, and most activity UIs use Moodle Core templates and AMD. Unoverridden pages may keep Core markup (e.g. href="#" menu triggers, weak labels).
  • Forms (moodleform) — Login, enrolment, settings, filters, and admin forms are generated by Moodle Core. Label association, error text, and field semantics are Core-owned; the theme only styles surrounding layout where applicable.
  • Focus lock and modals — core/local/aria/focuslock and Core modal/dialog behaviour apply across the site. The theme coordinates drawer focus in navigation it overrides; nested Core or plugin modals remain Moodle Core–dependent.
  • JavaScript (AMD) on Core pages — Interactions on screens without a theme template still load Moodle Core and plugin modules. Theme AMD (theme_space/drawer, etc.) applies only where the theme replaces or extends those surfaces.
  • Language strings — Strings such as opensinnewwindow come from Moodle Core language packs. The theme references them in overridden templates but does not maintain Core translations.
  • Media and user-authored content — Headings, alt text, captions, and embedded media in courses are content responsibilities, not theme-owned.

Theme-owned improvements (WCAG-oriented)

These items apply where theme_space overrides Core or plugin templates. They do not automatically fix unoverridden Moodle Core screens.

  1. Bypass mechanisms (e.g. WCAG 2.4.1) — Theme skip links are conditional on layout (e.g. no misleading targets when #mainNav or the block drawer is absent). Footer targets use sensible tabindex where the theme controls focus hand-off.
  2. Focus order & predictable controls (e.g. 2.4.3, 4.1.2) — In overridden UI, dropdowns, "more" menus, grading navigation, message drawer rows, pagination, and many admin/tool surfaces use buttons instead of inert anchors, with stable data-* hooks for theme AMD.
  3. Name, role, value (4.1.2) — Toolbar triggers, language menus, and custom menus align labels, aria-controls, and id wiring in templates the theme replaces.
  4. Orientation & structure — The theme page outline feature respects landmarks and headings in theme layout; tab interfaces are patched where invalid attributes appeared in overridden markup (e.g. removing inappropriate type="button" from <a role="tab">).
  5. Reducing redundancy (1.1.1, 2.4.4) — Theme adjustments avoid duplicated "Course name" screen-reader prefixes when link text is already descriptive, and trim redundant title on images when alt suffices—in theme-owned templates only.
  6. New windows (3.2.2) — Theme-controlled templates use Moodle Core strings (opensinnewwindow and related) for target="_blank" links, keeping warning copy consistent with Core language packs.

Limitations and residual risk

  • Unoverridden templates = Moodle Core behaviour — Pages still rendered by Moodle Core or plugins without a theme override may retain legacy patterns. The theme does not patch the DOM on those screens.
  • Upstream merges — Some improvements need paired changes in Moodle Core or plugin AMD (see wcag-features.md). After upgrades, reconcile theme and Core versions.
  • Automated tools ≠ WCAG pass — axe, WAVE, or Lighthouse can flag Moodle Core markup the theme never touches; manual keyboard, screen reader, and contrast checks remain necessary.
  • Focus traps — Drawer focus interacts with core/local/aria/focuslock (Moodle Core). The theme adds coordination for its drawers; edge cases remain with deeply nested Core modals or third-party scripts.

For auditors and implementers

  1. Use docs/wcag-features.md as the authoritative checklist of theme-specific measures and changelog entries.
  2. Verify Theme settings → WCAG (skip links, optional copy, page index).
  3. Run keyboard-only passes on: global navigation, course index drawer, block drawer, messages drawer, grading UI, and representative activities.
  4. Re-test after Moodle version upgrades and after enabling new plugins.