Choose and test web interface components

Start with the task

Write the task in one sentence: read terms, choose a town, compare offers or confirm a deletion. Describe what changes afterwards: the address, displayed content, a field value or saved data. This distinction helps choose between a link, button, input and dialog.

Begin with the simplest presentation that meets the need. A list of links may be enough where complex navigation would add interactions. Information needed by everyone can stay visible. Click count alone does not establish how easy a journey is.

Specify a behaviour contract

Record each component’s visible name, states, available actions and focus destination. The W3C ARIA practices explain that an announced role carries behavioural expectations: adding ARIA does not implement interaction. Prefer native HTML elements when they meet the need.

Include conditions outside the demonstration: long text, missing data, delay, cancellation, errors and concurrent changes. Specify what is saved and what remains provisional. Someone reviewing a design should be able to distinguish an accepted request from a button animation.

Choose a topic by the decision required

The following guides address distinct tasks: reveal supporting information, change views, select a value, manage an interruption, read data or reorder items. They extend the general accessibility guide and do not certify a website.

Once a choice is made, enter a task and expected result in the acceptance log. Test a real occurrence, followed by variants in a form, catalogue and translated page. A correction to a shared component needs checks in those contexts.

• Design and test a modal dialog

  Decide when to interrupt a task, organise opening, closing and focus return, then test long content and failed operations.

• Organise content with accordions and disclosures

  Choose what stays visible, label panels, manage multiple open sections and check links to collapsed information.

• Choose and test tabbed web views

  Distinguish tabs from navigation and visible sections, manage activation and loading, and preserve each panel’s input.

• Design autocomplete for selecting a value

  Separate free text from selection, handle delayed responses and repeated names, and test keyboard use and missing suggestions.

• Choose and test an image carousel or gallery

  Compare galleries and carousels, preserve movement control and check hidden slides, controls, captions and loading.

• Design mobile navigation and submenus

  Separate destination links from section disclosure, choose a mobile panel and test closing, keyboard use, zoom and resizing.

• Write and announce interface status messages

  Distinguish waiting, success, failure and empty results, announce changes and retain useful confirmation of important actions.

• Publish readable and accessible data tables

  Structure headers, units and missing values, choose sorting and mobile display, and check reading and data export.

• Choose interface links, buttons and actions

  Separate navigation from actions, write useful labels and handle submission, unavailability, cancellation and duplicate requests.

• Design date input and a booking calendar

  Distinguish calendar date, time and availability, choose input or calendar, manage formats and check booking confirmation.

• Reorder items without relying on drag and drop

  Offer simple movement controls, preserve focus, communicate the new position and manage saving and cancellation.

Compare alternatives on the same task

Educational example: a team compares three tabs with three visible sections for presenting offers. Participants find a condition and compare two services on a phone. The team records backtracking, missed details and whether the relevant information can be shared. If people need to read all three parts together, visible sections may suit the task better.