Custom checkbox or toggle

Test a visual toggle that must expose its role, name, state, and keyboard behavior.

Level: Beginner
Time: 5-10 minutes

Objective

Recognize when custom controls need native semantics or complete ARIA behavior.

PREPARE

Set up your test

Turn on a screen reader you know how to operate.
Navigate by controls or use Tab where the task asks you to.
Listen for purpose and state, not one exact sequence of spoken words.

WORKING EXAMPLE

Establish the expected behavior

Navigate to the toggle and activate it with Space. Listen for its name, role, and state.

Email notifications

Expected behavior: the control is keyboard operable and exposes a checked or unchecked state.

INTENTIONAL DEFECT

Find the barrier

The example below deliberately contains one accessibility defect. Skip the defective example.

Try to reach and operate the visual toggle with a keyboard and screen reader.

Email notifications

Hint

If you cannot focus it or hear its state, the visual switch is not enough.

End of intentional defect.

DIAGNOSE

Choose the primary cause

EXPLANATION

Understand and repair it

Reveal explanation

What happened

The defective switch is a styled span. It has no control role, no accessible state, and no keyboard interaction.

Repair

Use a native checkbox when possible. If a custom switch is necessary, implement the full switch pattern including role, name, state, focus, and keyboard support.

<label>
  Email notifications
  <input type="checkbox">
</label>

Retest

Tab to the control and confirm it receives focus.
Confirm its role, name, and checked state are announced.
Activate it with Space and confirm the state changes.

Report it

Example: The email notifications toggle is only a styled element, so screen reader and keyboard users cannot identify or operate it.

Standards and support

This exercise describes behavior rather than promising identical speech across screen reader and browser combinations.

Editorially reviewed 20 July 2026.