Accessibility in ORIGAM: where we stand today, and a proposal to start using ARIA

ideas
1

Hi everyone,

I recently did a quick accessibility audit of our two main frontends — frontend-html (end-user web client) and architect-html (HTML Architect) — and the results pushed me to start this discussion. The short version: ARIA attributes are essentially not used in our application code, and we have no a11y tooling in place. With the European Accessibility Act now in force, I think it’s time we started treating accessibility as a first-class concern, and I’d love to hear what you all think.

What I found:

  • In frontend-html/src, zero ARIA attributes in application code — every aria-* match was inside the bundled FontAwesome vendor JS. Only one role= attribute exists, in TextEditor.tsx.
  • In architect-html/src, just 3 ARIA attributes total: one aria-label="Status" in SearchResultsEditor.tsx and two aria-hidden flags in FilterableSelect.tsx. One role= in TopLayout.tsx.
  • Neither project has eslint-plugin-jsx-a11y, axe-core, or any other accessibility linter / test tool in package.json.
  • Keyboard navigation inside data forms works thanks to our custom FormFocusManager / TabIndexOwner, but that’s the only area with explicit care — and it doesn’t expose semantics to screen readers.
  • Practical impact: users relying on screen readers, voice control, or non-mouse navigation outside the form grid effectively cannot use ORIGAM today.

Why this matters legally (EU context):

  • Directive (EU) 2019/882 — European Accessibility Act (EAA): applies since 28 June 2025. Covers consumer-facing digital products and services (e-commerce, banking, e-readers, computing hardware/OS, etc.). Many ORIGAM-built applications fall directly under its scope when deployed for consumers. Existing products without substantial changes have a transitional period until 28 June 2030.
  • Directive (EU) 2016/2102 — Web Accessibility Directive: already in force, mandates WCAG 2.1 Level AA conformance for public sector bodies’ websites and mobile apps (including intranets/extranets since 23 September 2019). A significant share of ORIGAM customers are public sector — their ORIGAM-based portals are legally required to be accessible.
  • EN 301 549 V3.2.1 — “Accessibility requirements for ICT products and services”: the harmonised European standard (ETSI, March 2021) that operationalizes both directives. References WCAG 2.1 Level AA and adds further software-specific requirements, including clause 11.5 “Interoperability with assistive technology” — specifically clause 11.5.2.5 “Object information”, which requires that role, state(s), name, and description of UI elements are exposed to assistive technologies. That is exactly what ARIA solves for custom widgets.
  • WCAG 2.1, success criterion 4.1.2 Name, Role, Value (Level A — required even at the lowest conformance level) explicitly requires that for all UI components the name and role can be programmatically determined. This applies directly to our custom grid, dropdowns, dialogs, and editors.
  • Czech transposition: zákon č. 99/2019 Sb. (transposes 2016/2102, effective 9 April 2019) and zákon č. 424/2023 Sb. (transposes the EAA, effective 28 June 2025).

Proposal — how I’d like us to start:

  • Add eslint-plugin-jsx-a11y to both frontend-html and architect-html with a baseline ruleset, so new code is checked automatically.
  • Add axe-core (e.g. @axe-core/react in dev, or as part of Playwright/Jest checks) so we can detect issues at runtime in CI.
  • Pick a small set of high-impact components first: modal dialogs (ModalWindow.tsx), dropdowns (DropdownEditorControl.tsx, FilterableSelect.tsx), data grid / table headers, and form editors — add aria-label, aria-labelledby, role, aria-expanded, aria-invalid, etc. where appropriate.
  • Define a conformance target — I’d suggest WCAG 2.1 Level AA as the minimum, since that’s what EN 301 549 references.
  • Document the resulting conventions in agents.md / contributor docs so future PRs follow them.

This doesn’t need to be a big-bang refactor — a baseline of tooling plus incremental coverage of the most-used components would already move us a long way, both for end users and for compliance.

Let me know what you think — especially if any of you have already shipped ORIGAM apps that had to pass an accessibility audit, I’d love to hear how you handled it!

Disclaimer: I may have gotten some of the legal citations slightly wrong — but the core issue stands: we’re not handling accessibility well.