Accessibility Testing Lab home
Accessibility Testing LabA hands-on environment for practising accessibility testing

Testing controls in a community events finder

Investigate names, roles, states, keyboard behavior, and result announcements in a realistic event-finding interface.

Difficulty:
beginner
Estimated time:
25 minutes

Objectives

  • Inspect accessible names, roles, states, and values before interaction.
  • Operate common controls with their expected keyboard commands.
  • Re-check exposed state and related page updates after interaction.
  • Distinguish findings from useful passing comparisons.

Instructions

Use Testing controls with a screen reader while investigating the community events finder.

  1. Record your screen reader, browser, operating system, relevant versions, and initial page state.
  2. Inspect every interactive control before operating it. Record its visible label, accessible name, role, and state or value.
  3. Open the filters, choose categories, change the results view, inspect event details, and use each save control with the expected keyboard command.
  4. Re-check each control after activation and listen for information that changes elsewhere on the page.
  5. Identify exactly five findings and record useful passing behavior from the native checkboxes, radio buttons, action button, and event-details link.
  6. For every finding, record reproduction steps, actual and expected behavior, user impact, and remediation direction.

Exact announcements can differ across screen readers, browsers, and operating systems. Evaluate the exposed properties and observable interaction rather than expecting one prescribed speech string.

Exercise workspace

Community events finder controls exercise

Start exercise

The exercise opens on a separate page. Return to this page whenever you need a hint, or when you are ready to continue and review the solution.

You can open the exercise in a new tab if you want to keep these instructions and hints available.

Hints
  1. Pay particular attention to the filter trigger, event actions, and information that changes after you make a choice.
  2. Compare visible labels with accessible names and compare each control's initial state with what it exposes after activation.
  3. Check aria-expanded on the filter button, the control type used for event details, aria-checked on the save switch, the second save control's name, and how the result count is communicated.
Solution

The events finder contains five focused control and announcement findings alongside correctly exposed native comparisons.

The filter button exposes stale expanded state

The panel opens visually but aria-expanded remains false. Update aria-expanded whenever the controlled panel opens or closes.

Event details use button semantics for navigation

The repair-café control moves to a destination but is exposed as a button. Use a link with a real href for navigation.

The save switch exposes stale checked state

The switch works with click and Space and changes visibly, but aria-checked remains false. Update the exposed state with the saved state.

A save control's accessible name conflicts with its visible label

The visible Save event label is replaced by the unrelated accessible name Bookmark item. Use an accessible name that includes and communicates the visible label.

Filtered results are not announced

Category checkboxes update the visible result count and list, but the result information is not exposed as a status update. Communicate the concise result change without moving focus.