Accessibility

What we aim for

We target WCAG 2.1 Level AA across this website. The marketing and policy pages meet that standard as far as we can determine. The game itself is a canvas, and canvas games are genuinely hard to make fully accessible.

This page is deliberately specific about where we fall short rather than making a blanket conformance claim. If a statement here turns out to be wrong, we would like to know.

What is in place

• A skip-to-content link as the first focusable element on every page.
• Semantic landmarks, one h1 per page and headings that descend in order without skipping levels.
• Navigation that works by keyboard. The mobile menu is a real button with aria-expanded, closes on Escape, returns focus to the button, and traps focus while open.
• Visible focus indicators everywhere. We never remove an outline without replacing it.
• Touch targets of at least 44 by 44 pixels.
• Text contrast checked by calculation rather than by eye. Body text sits at 6.9:1 and secondary text at 4.9:1 against the background. Our accent blue measures only 2.4:1 on the page background, so it is used for decoration and never behind or as text; a darker blue at 4.8:1 with white is used for buttons.
• Full support for prefers-reduced-motion. It disables the hero animation, scroll reveals, button press movement, confetti and the blocker pulse.
• The FAQ accordion uses real buttons with aria-expanded controlling regions, and works with a keyboard.
• No content depends on colour alone. Locked arrows carry a marker as well as a different colour, and the status line names their state in words.
• Layout works from 320 pixels upward with no horizontal scrolling, and text can be zoomed without loss of content.

Playing without a mouse

The game can be played entirely from the keyboard. Focus the board, then:

Below the board is a status line that updates as you play. It announces the level and its shape, how many arrows remain, how many drops you have left, and for the selected arrow: its number, the direction it points, its grid position, and whether its path is clear, blocked or locked. That is enough information to play the game without seeing it.

The status line is also useful at high level numbers, where cells become small and precise clicking gets difficult. Keyboard selection is unaffected by cell size.

Known limitations

These are real and we are not going to pretend otherwise.

The board is summarised, not mapped

A canvas has no internal structure for assistive technology to explore. We provide a text description instead, which tells you the state of the board and of the arrow you have selected, but it does not let you feel out the spatial layout the way a sighted player can scan it. Solving a large board this way is possible but considerably harder.

Timed blockers introduce a timing dependency

From level 21, some cells alternate between passable and blocked on a fixed cycle of roughly 1.4 to 2.3 seconds. There is no way to pause or extend that cycle.

Under a strict reading of WCAG success criterion 2.2.1, that is a failure: the timing is not adjustable. We consider the timing essential to the mechanic, which is the exception the criterion allows, but reasonable people can disagree and you deserve to know it is there. Levels 1 to 20 contain no timing element at all.

Small targets at high levels

The number of arrows equals the level number, so late boards are dense. Cells shrink accordingly and can end up only a few pixels across, well below any sensible target size. Pointer play becomes uncomfortable somewhere around level 300 and impractical well before 1000. The board does not zoom. Keyboard play remains usable.

Combo scoring rewards speed

The score multiplier requires clearing arrows within about two seconds of each other. It affects your score only, never whether you can finish a level, so it is safe to ignore entirely.

No high contrast theme

We honour the operating system's forced-colours mode for interface elements, but the canvas itself is not re-themed and there is no separate high contrast option.

What we have not verified

Being straight with you about the difference between checked and assumed:

• Verified by inspection and calculation: heading order, one h1 per page, landmark structure, contrast ratios, focus visibility, target sizes, reduced-motion behaviour, keyboard operation of the navigation, accordion and game.
• Not yet verified with assistive technology: we have not completed testing passes with NVDA, JAWS, VoiceOver or TalkBack. The live status line is built to the specification, but how it actually sounds in each screen reader has not been confirmed.
• Not yet verified on physical devices: layout has been checked at the standard breakpoints but not on a range of real phones and tablets.
• Not verified with users: no testing with disabled users has taken place.

Full accessibility validation needs manual testing with assistive technologies and review by an accessibility specialist. Neither has happened yet, so treat the conformance target above as our aim and this list as its current honest state.

Reporting a barrier

If something here blocks you, please tell us. Reports about accessibility go to the front of the queue.

Email support@iamtac.com with "Accessibility" in the subject. It helps if you can include:

• the page or level where it happened;
• your browser and operating system;
• the assistive technology you use, and its version;
• what you expected, and what happened instead.

We will acknowledge your message, tell you whether we can fix it and roughly when, and if we cannot fix something we will say so and explain why. Fixes are recorded in the changelog.