All skills

SKILL / accessible-components

Accessible components

Review how an interface works beyond the click. Keyboard, focus, semantics and component states.

Download skill (.zip)Read instructions
Input
A component or page, its source when available and its expected behavior.
Output
Reproducible findings, fixes when requested and tests for the affected interactions.

PLAYGROUND / AUTOCOMPLETE

Try it without a mouse.

An independent technology picker example. Type to filter, navigate suggestions and add values as chips.

Choose one or more. ↑ ↓ navigate, Enter adds and Esc closes.

No technologies selected yet.

WHAT TO LOOK FOR

  1. 01. Focus stays in the input while arrow keys highlight suggestions.
  2. 02. Enter commits a choice. Esc closes without clearing the text.
  3. 03. Each chip has a named removal button. Removing one returns focus to the input.
  4. 04. Tab leaves the suggestions and continues through the page.

Before: the problem to avoid

A click-only list that does not expose the active option or handle focus after an item is removed.

After: explicit behavior

This example implements keyboard selection, input/list relationships and focus restoration. Screen-reader validation remains a separate step.

Interaction reference: WAI-ARIA APG · Combobox. Created for this portfolio; it does not reproduce company code or interfaces.

Use it in your project

Extract the ZIP and make the folder available to your SKILL.md-compatible agent. You can also provide the instruction file directly. The package includes references; inspection uses your environment’s browser and code tools.

Example prompt

Use $accessible-components to review this component’s keyboard navigation, focus, semantics and states. Fix the findings and test the changed interactions.

The demonstration on this page is local and illustrative. It does not audit external sites or establish accessibility conformance.

Accessible components — Tiago Pinto