Skip to main content

Accessibility and responsiveness

Accessibility is treated as part of the researcher workflow, not as a colour choice. The current website declares English with lang="en", uses native buttons, inputs, selects and dialogs, and supplements them with ARIA relationships and live status messages. At the submitted revision, the main page contains 42 aria-* uses across labels, descriptions, expanded state, popup state, hidden state and live regions.

Implemented interface support​

  • Every editable field has a visible label or programmatic name.
  • Project creation, security and confirmation actions use dialogs with headings and close controls.
  • Loading, connection, validation, save and run states are written as text and announced through status regions.
  • Focus, success and warning states use both text and colour.
  • Buttons use verbs such as Create project, Close door and Save replay instead of unexplained icons.
  • The shared palette uses light text on dark surfaces and a visible blue focus/accent colour.
  • The dedicated workspace and focus mode preserve an exit route and keep important controls reachable.

Responsive behaviour​

The website has explicit layout rules at 880, 700, 560 and 420 CSS pixels, plus a short-height rule at 700 pixels. Wide layouts keep the arena visible while side panels scroll independently. Narrow layouts stack controls above the arena and remove fixed widths that would create sideways overflow.

The release target includes desktop and 390 px and 360 px mobile widths. Supporting a width in CSS is not evidence by itself, so screenshots and interaction notes should be captured from the deployed final commit.

Manual release procedure​

  1. Use only Tab, Shift+Tab, Enter, Space and Escape from sign-in through project creation, workspace opening, a short run and replay exit.
  2. Confirm that focus is visible and follows the visual order. Opening a dialog should move attention into it; closing it should return to the action that opened it.
  3. Test at 100% and 200% browser zoom without hidden actions or horizontal page overflow.
  4. Test at 390 px and 360 px widths. Check authentication, project popup, team permissions, Setup, Run, Review, downloads and error messages.
  5. Trigger a long validation error and confirm it does not cover a primary action.
  6. Check labels and live status with a screen reader available to the team.
  7. Run an automated accessibility scan on the deployed URL and save the report with the commit and browser version.

What is and is not automated​

Python UI contract tests check the presence of semantic labels, dialog wiring, shared colour/font tokens, major controls and website-to-Godot commands. JavaScript syntax is checked in CI. The repository does not currently claim automated WCAG conformance or zero axe violations because a browser accessibility runner is not part of the submitted pipeline. Keyboard, screen-reader, zoom and visual-overlap checks remain required release evidence.

AI Attribution: This procedure was prepared with OpenAI Codex assistance from the integrated HTML, CSS and UI tests. Manual outcomes must be recorded by the team on the final deployed build.