Orqestria Download
← Back to Nakama · project planning pack

Skill · Version 1.0.0

Accessible interfaces

Makes the game's website and browser-based player tools usable with keyboard, screen reader and enlarged text. Checks real navigation and feedback rather than relying only on automated scores.

web-accessibility

Agents using this skill

See how it helps

When is it useful?

Use this skill to make an interface usable with a keyboard, screen reader and different screen sizes. It checks real interactions, readable content and clear feedback throughout a user journey.

What does it help you do?

  • Uses meaningful HTML, visible labels, descriptive links and suitable alternative text for images.
  • Checks focus order, keyboard controls, dialogs and error messages so users can complete the flow without a mouse.
  • Reviews contrast, text resizing, mobile reflow and reduced motion, supported by manual and available automated checks.

Try asking this

Review a game's account page and tournament registration form in the browser. Complete both with keyboard navigation, check field-error announcements and test narrow screens with enlarged text. Ensure icon buttons have meaningful names, focus returns after dialogs and success or failure is communicated without relying on color alone.

Detailed documentation

Read the skill’s original instructions, examples and checks in their authored language.

Details…Show less

Web Accessibility (WCAG 2.2 AA)

Semantic HTML first

  • Native elements: button for actions, a href for navigation, input/select/textarea for data, table for tabular data, lists for lists. Never a clickable div.
  • Landmarks: one main, plus header, nav (labelled if several), footer.
  • One h1 per page; headings in order without skipping levels.
  • Set lang on html and a unique, descriptive title per page or route.

Keyboard and focus

  • Everything interactive works with Tab, Shift+Tab, Enter, Space, Escape, and arrow keys where the pattern expects them.
  • Never remove focus outlines without a visible replacement (:focus-visible). Focused items must not hide behind sticky headers.
  • Focus order follows visual order; no positive tabindex.
  • Dialogs: move focus in on open, keep it inside, close on Escape, return focus to the trigger. Prefer the native dialog element or the repo's accessible component.
  • Add a skip link on pages with repeated navigation. In SPAs, move focus or announce on route change.

Text, color and media

  • Contrast 4.5:1 for normal text; 3:1 for large text, icons, focus indicators and control borders.
  • Never convey meaning by color alone.
  • Alt text states the image's purpose; decorative images get alt="". Icon-only buttons need an accessible name.
  • Content reflows at 320px width and 200% text size without loss or horizontal scrolling.
  • Captions for video; no autoplaying audio.

Forms and errors

  • Every control has a visible label bound with for/id; a placeholder is not a label. Group related controls with fieldset and legend.
  • Mark required fields in text; use autocomplete attributes for personal data.
  • Errors name the field and the fix in text, link via aria-describedby, and are announced or focused on submit.
  • Do not make users re-enter data they already gave; no cognitive puzzles to log in.

ARIA only when needed

  • No ARIA beats wrong ARIA. Use it only when HTML has no native equivalent.
  • Custom widgets (tabs, combobox, menu) follow the WAI-ARIA Authoring Practices roles, states and keys.
  • Keep states in sync: aria-expanded, aria-selected, aria-checked, aria-current. Use aria-live for async status messages.

Motion and targets

  • Respect prefers-reduced-motion: reduce or remove non-essential animation.
  • Nothing flashes more than three times per second.
  • Pointer targets at least 24x24 CSS px; offer a non-drag alternative to drag actions.

Test

  • Keyboard-only pass through the changed flow.
  • Screen reader pass (VoiceOver or NVDA) on changed components: names, roles, states, announcements.
  • Check that status messages (toasts, inline errors, loading and saved states) are announced, and that the page stays usable in forced-colors (high contrast) mode and at 400% zoom.
  • Run the automated checker the repo has (axe, jest-axe, Playwright axe, Lighthouse). Automated tools catch only part of the problems.

Before you finish

  • Semantic elements, headings and landmarks correct.
  • Full keyboard operation with visible focus.
  • Contrast and non-color cues meet AA.
  • Every input and icon button has an accessible name; errors are announced.
  • Reduced motion respected.
  • Keyboard, screen reader and automated checks done.

Included files 1

  • SKILL.md