Skip to content
Hubtask

Accessibility

Operable by keyboard, or it is a defect

Hubtask is built to WCAG 2.2 level AA — the standard the European Accessibility Act expects. This page says what that means in practice and what is actually measured rather than intended. The formal accessibility statement is published with the first stable release, once conformance has been demonstrated for a release rather than asserted for a plan.

In practice

What was built rather than reviewed

  • Contrast is measured, not eyeballed Every colour pair the design system declares is measured in both light and dark on every test run: 4.5:1 for text, 3:1 for a control boundary and the focus ring. A new colour with no role assigned fails the suite rather than being skipped.
  • Focus is always visible A two-pixel ring with an offset, on every interactive element. The workbench can walk the focus order of a component and report it, so “it is keyboard operable” is something somebody looked at rather than assumed.
  • Overlays behave Focus is trapped in a dialog and returned to what opened it; menus work with arrows, Home, End and type-ahead; Escape closes exactly one layer; a notification is announced without stealing focus, because a save confirmation arrives while somebody is typing.
  • Nothing is disabled without a reason There is no bare “disabled” anywhere in the component library — switching a control off requires giving the reason, so a control you cannot use cannot come apart from why.
  • Text can grow by forty per cent Every component is checked against a pseudo-locale that lengthens every string. Clipping is treated as a defect, not as a rendering.
  • Reduced motion is a user preference Not only the operating system’s: the product carries its own switch, because a preference only the OS can set is not one the reader controls.
  • Right to left is not an afterthought Layout uses start and end rather than left and right throughout, and every component is reviewed in both directions.
  • Colour never carries meaning alone Every status also has text or an icon — which matters for colour vision deficiency, and equally for print and greyscale documentation.
design-system.md §6 · the six rules

The statement

Standard, status, exceptions, and the date

The standard

EN 301 549, the European standard the Accessibility Act refers to, which carries WCAG 2.2 level AA for web content. Level AAA is not claimed anywhere; there is no video, so no sign-language or audio-description provision applies.

The status, as of 16 September 2026

Partially conformant, assessed by the makers. Every route of the web interface has been walked by keyboard alone, in both writing directions, with text spacing widened, and its accessibility tree read for names, roles, headings, lists, tables, images and live regions; every finding of those walks was fixed before this sentence was written. What has not been done is the pass with a screen reader — VoiceOver, NVDA and Orca have not yet been run through the routes by a person listening — and a claim of conformance for a reader nobody ran would be false. That pass is the next assessment, and this page changes when it is done.

Known exceptions

  • Screen readers, 16 September 2026. Not yet walked with VoiceOver, NVDA or Orca (see the status). The structure a reader consumes — names, roles, states, headings, one live region — has been read from the accessibility tree instead.
  • Hover and selection lifts, 16 September 2026. Six components paint a hovered or selected row with a background the design system does not define, so the lift is missing until the token is added; the selected state is still carried by text, an icon or aria-current, never by colour alone. Tracked as a defect.
  • Content you enter yourself. An image attachment without a description, a colour used as the only distinction in a workspace's own labels — outside what the software can guarantee. Where the product can help it does: a label is always a colour and a name.

Who assessed it, and how

The makers, by walking the interface (the evidence is in the repository under docs/evidence/: the keyboard walk, the right-to-left audit and this pass) and by the measurements every test run repeats. The formal statement is published with the first stable release, once a screen-reader pass has been run; until then this page is the assessment as it stands, dated, and updated whenever a walk is.

Scope and limits

What this statement covers, and what it does not

What this covers

The web interface an installation serves, and this website. The installed desktop and mobile applications are being built and will be held to the same standard, with a screen reader pass and a keyboard pass part of the release rather than a follow-up.

This website

The page you are reading is plain HTML with no scripting at all, one skip link, a visible focus ring, and the same measured contrast. Its colour mode control is three radio buttons and works from the keyboard.

Reporting a barrier

If something here or in the application cannot be reached, please say so. A barrier is a defect and is handled as one — and a report now, while the interface is being built, is worth more than one after it has shipped. info@hubtask.eu