Accessibility Statement

Society Intelligence is committed to making EU Optikos usable by as many people as possible, including people who rely on assistive technology such as screen readers, keyboard-only navigation, screen magnification, or speech input. This statement describes the accessibility target we work towards, how we test against it, what we already know to be incomplete, and how to tell us when something does not work for you.

This statement is honest about where we are: it describes what we strive to conform to and how we verify it, and it does not claim a level of conformance that has not yet been formally audited and signed off.

1. Scope

This statement applies to the EU Optikos web terminal served at euoptikos.com. It covers the application surface — the map, the indicator and comparison views, profiles, briefings, and the account and informational pages. Third-party content rendered verbatim for attribution or licence compliance (see /sources) is the responsibility of the upstream provider, although we still aim to present it accessibly.

2. Conformance Target

EU Optikos targets, and strives to conform to, the Web Content Accessibility Guidelines (WCAG) 2.1, Level AA, and the European harmonised standard EN 301 549 v3.2.1 (which incorporates WCAG 2.1 AA for web content). These are the benchmarks our design, engineering, and review processes are measured against.

We deliberately phrase this as a target rather than a guarantee. A formal, independently reviewed conformance claim for the whole terminal is pending — see “Formal conformance and VPAT” below.

3. How We Test (Conformance Approach)

Conformance is verified through a combination of automated and manual methods, run as part of normal development rather than as a one-off exercise:

• Automated checks — the axe-core accessibility engine is run against application views to catch common defects (missing names, insufficient contrast, invalid ARIA, structure problems).
• Manual keyboard testing — interactive flows are exercised using the keyboard alone, checking focus order, visible focus indication, focus management when panels open and close, and that no control becomes a keyboard trap.
• Screen-reader testing — key surfaces are checked with a screen reader to confirm that names, roles, states, and live-region announcements are conveyed. Data visualisations expose their underlying numbers as a real, navigable table (for example, the map offers a “View as table” alternative to the colour-encoded choropleth).
• A static build guard — an in-repository check (check:a11y) fails the build if an interactive map, chart, image, or icon-only control ships without an accessible name. This prevents a known class of regressions from reaching production.

4. Accessibility Features

Measures already in place across the terminal include:

• Semantic landmarks and headings, and a skip-to-content link.
• Accessible names on interactive controls, including icon-only buttons.
• Visible keyboard focus indication and managed focus when dialogs, drawers, and panels open and close.
• A text/table alternative for the interactive map: the “View as table” control presents the same data the map paints — region, value, and period — as a navigable table with a caption and column and row headers.
• Colour is not used as the only means of conveying information; values are also available as text and in tables.
• Light and dark themes with token-driven colours chosen to meet AA contrast on text.

5. Known Limitations

We are aware that parts of the terminal are not yet fully accessible. The list below is a working record and is provisional pending the results of an end-to-end accessibility audit currently in progress; it will be finalised, with specifics and remediation timelines, once that audit completes.

• Interactive map canvas — the map itself is rendered to a graphics canvas that assistive technology cannot read directly. We mitigate this with an accessible map summary and the “View as table” data alternative, but parity of interaction (for example, panning and zooming by keyboard) is still being improved.
• Complex data visualisations — some charts and overlays (for example, hazard and exposure layers) expose their data as text or tables, but the richest interactions may not yet be fully operable by every assistive technology.
• Items from the in-progress audit — additional findings from the end-to-end audit will be added here as they are confirmed.

6. Formal Conformance and VPAT

A formal accessibility conformance report — a VPAT 2.x (Voluntary Product Accessibility Template), including an EN 301 549 mapping — and a stated final conformance level are pending completion of the end-to-end audit and sign-off by the product owner and legal review. Until that document is published, this statement should be read as a description of our target and approach, not as a certified conformance claim. We will link the VPAT here once it is available.

7. Feedback and Reporting a Barrier

If you encounter an accessibility barrier on EU Optikos, please tell us — your reports directly inform what we fix and in what order. Where possible, include the page, what you were trying to do, the assistive technology and browser you were using, and what happened.

To report a barrier or request information in an accessible format, contact support@euoptikos.com. For formal accessibility-compliance correspondence, contact legal@euoptikos.com. We aim to acknowledge feedback within five working days.

8. Review

This statement was last reviewed on 2026-06-26. We review it as the terminal changes and as the end-to-end audit and the formal conformance report are completed.