Accessibility

This page is guided by WCAG 2.1 Level AA, EN 301 549, and EU Directive 2019/882 (European Accessibility Act). As a research prototype, we are not legally required to — we do it because accessibility is part of what this project stands for.

The European Accessibility Act (Directive 2019/882) requires companies to make digital products and services accessible from June 2025. moiree.eu, as a non-commercial research prototype, does not fall within its scope — but we use its requirements as guidance nonetheless.

Accessibility is an ongoing process. If you encounter a barrier not documented here, or if one of the described features does not work as expected for you, let us know.

Contact: info@moiree.eu

What was tested

All text-background combinations were tested with the WebAIM Contrast Checker and axe DevTools — in both color modes (dark and light). Checked: body text, headings, links, badges, table text, and placeholders.

Why this matters for moiree.eu

The platform uses a dark primary palette with accent color #7A5AB5. Contrast is especially critical here because much of the text sits on a dark background — a combination where readability deteriorates quickly.

What state of the art requires

WCAG 2.1 AA requires a minimum ratio of 4.5:1 for body text and 3:1 for large text (18pt or 14pt bold). This threshold is based on research into readability for people with impaired vision.

Result

The primary color #7A5AB5 achieves 5.1:1 on white — deliberately above the minimum to remain readable under adverse conditions (sunlight, older displays). All other text combinations meet at least 4.5:1. Dark mode text colors have been adapted accordingly.

What was tested

All interactive elements — links, buttons, forms, dropdowns, modals, carousel, accordions — were tested using only the keyboard: Tab, Shift+Tab, Enter, Escape, arrow keys.

Why this matters for moiree.eu

The platform includes complex interaction patterns: collapsible sections, filter dropdowns on the dashboard, modal case views in the database. Each of these must be operable without a mouse.

What state of the art requires

WCAG 2.1.1 requires that all functionality is available via keyboard. WCAG 2.1.2 ensures that keyboard focus is not trapped in an element (except in modals, where focus trapping is intentional).

Result

All interactive elements are reachable via Tab, Enter, and Escape. Tab order follows the visual reading order. No element traps focus unintentionally.

What was tested

All focusable elements were checked for visible :focus-visible styles — links, buttons, form fields, accordion triggers, navigation.

Why this matters for moiree.eu

On dark backgrounds, default browser focus rings are often barely visible. moiree.eu uses custom focus styles that must work in both color modes.

What state of the art requires

WCAG 2.4.7 requires a visible focus indicator. WCAG 2.4.11 (Level AAA, downgraded to AA in 2.2) defines a minimum contrast for the focus ring itself.

Result

All interactive elements show a visible :focus-visible ring. The style uses outline with offset so the focus is clearly visible even on dark backgrounds.

What was tested

Every page was checked for a skip link that becomes visible on focus and jumps directly to the main content.

Why this matters for moiree.eu

The navigation contains multiple groups with dropdowns. Without a skip link, keyboard users would have to tab through all navigation items on every page before reaching the content.

What state of the art requires

WCAG 2.4.1 requires a mechanism to skip recurring content blocks. The skip link is the most common implementation.

Result

Present on every page. Visually hidden until the link receives focus — then positioned visibly. Jumps to #main.

What was tested

All pages were tested with VoiceOver (macOS/Safari): page structure, landmarks, ARIA labels, dynamic content (filter results, modal openings), tables, and forms.

Why this matters for moiree.eu

The platform contains dynamic content — filter results on the dashboard, modal case views, stat counters. These must be correctly announced to assistive technologies.

What state of the art requires

WCAG 4.1.2 requires that all controls have programmatically determinable name, role, and state. WCAG 4.1.3 requires that status messages are communicated via aria-live.

Result

Semantic HTML forms the basis: nav, main, footer as landmarks, correct heading structure (with one known exception, see below). ARIA labels on navigation elements, tables, and forms. aria-live regions for dynamic content such as filter results and statistics.

What was tested

The case-view modals in the database were tested for focus trapping, correct ARIA markup, and close behavior.

Why this matters for moiree.eu

The database displays case details in modal overlays. If focus escapes the modal, keyboard users can interact with the obscured page content — a common accessibility error.

What state of the art requires

WAI-ARIA Authoring Practices recommend: role="dialog", aria-modal="true", focus trapping within the modal, close via Escape, focus return to the triggering element.

Result

Focus trapping is active: Tab and Shift+Tab stay within the modal. role="dialog" and aria-modal set. Escape closes. Focus returns to the triggering element.

What was tested

The submission form and newsletter form were tested for labels, error messages, ARIA attributes, and keyboard reachability.

Why this matters for moiree.eu

The submission form is the central interaction point of the platform. If input fields are not correctly labeled, screen reader users cannot submit experience reports.

What state of the art requires

WCAG 1.3.1 and 4.1.2 require programmatically associated labels for all form fields. WCAG 3.3.1 requires that errors are identified and described in text.

Result

All fields have associated label elements. Error messages appear as visible text, not just as color changes. aria-invalid is set on validation errors.

What was tested

All clickable elements were checked for minimum size — buttons, links, carousel dots, filter chips, checkbox labels, navigation entries.

Why this matters for moiree.eu

The platform is also used on mobile devices. Small touch targets (e.g., carousel dots) lead to mis-taps, especially for people with motor impairments.

What state of the art requires

WCAG 2.5.8 (Level AA in WCAG 2.2) requires a minimum size of 24 × 24 px. Apple and Google recommend 44 × 44 px. moiree.eu follows the stricter recommendation.

Result

All interactive elements achieve at least 44 × 44 px hit area. For visually smaller elements (e.g., carousel dots), the hit area is enlarged via pseudo-elements.

What was tested

All pages were tested at 200% browser zoom for horizontal scrolling, clipped content, and layout errors.

Why this matters for moiree.eu

Tables (database), charts (dashboard), and the multi-column navigation are especially prone to layout breakage when zoomed.

What state of the art requires

WCAG 1.4.4 requires that text can be enlarged to 200% without loss of content or functionality. WCAG 1.4.10 requires no horizontal scrolling at 400% zoom with a 320 px viewport.

Result

No horizontal scrolling at 200% zoom. Tables receive horizontal scrolling within their container. All content remains readable and operable.

What was tested

The eight dashboard charts were tested with VoiceOver and axe DevTools for screen reader accessibility, keyboard navigation, and alternative data access.

Why this matters for moiree.eu

The dashboard is the analytical core of the platform. If charts are not accessible, the entire data analysis is excluded for screen reader users.

What state of the art requires

WCAG 1.1.1 requires text alternatives for non-text content. For complex data visualizations, W3C guidelines recommend tabular alternatives or structured descriptions.

Result

Plotly.js renders SVG charts that are not interpretable by screen readers — a known limitation of the library. Chart data is viewable as a table on the database page and exportable as CSV. This is a deliberate trade-off between visual complexity and accessibility: the data is fully accessible, the visual presentation is not.

What was tested

The heading structure of all pages was checked with axe DevTools and VoiceOver heading navigation for a seamless hierarchy.

Why this matters for moiree.eu

Screen reader users frequently navigate via heading structure. Skipped levels make orientation on the page more difficult.

What state of the art requires

WCAG 1.3.1 requires that structure and relationships are programmatically determinable. A seamless heading hierarchy (h1 → h2 → h3) is part of this requirement.

Result

The homepage skips one level (h1 → h3 without h2) — a known error that can affect screen reader navigation. All other pages have a correct hierarchy. The fix is planned for the next update.

What was tested

The DE/EN language toggle was tested for keyboard reachability, ARIA semantics, and screen reader announcement.

Why this matters for moiree.eu

The platform is bilingual. If the language toggle is not correctly recognizable by assistive technologies, users cannot switch languages.

What state of the art requires

WCAG 4.1.2 requires that custom controls have programmatically determinable name, role, and state. A toggle element needs at least role="button" or role="switch" and a descriptive aria-label.

Result

The toggle is keyboard-reachable and functional. It lacks an explicit ARIA role attribute — screen readers therefore do not reliably recognize the element as an interactive control. Adding role and aria-label is planned for the next version.