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

Testing modal dialogs in account settings

Compare an incomplete custom modal with a native dialog while testing naming, focus, background availability, and closing behavior.

Difficulty:
beginner
Estimated time:
25 minutes

Objectives

  • Identify and compare custom ARIA and native modal-dialog implementations.
  • Check each dialog's accessible name with a screen reader or accessibility inspector.
  • Test initial focus, focus containment, and background availability with a keyboard.
  • Test visible closing controls and Escape behavior.
  • Verify where focus moves after a dialog closes.
  • Distinguish native browser behavior from responsibilities a custom implementation must supply.

Instructions

Use the Testing modal dialogs method to compare the two modal interactions in the account-settings page. Start the exercise from the Exercise workspace.

  1. Record your browser, operating system, screen reader, and relevant versions.
  2. Open the contact-preferences modal and test its accessible name and initial focus.
  3. Move through all controls with Tab and Shift+Tab, then try to reach and operate the page behind it.
  4. Test both Escape and the visible close button. Record where focus moves after closing.
  5. Repeat the same procedure with the appointment-reminder modal.
  6. Identify exactly six findings in the contact-preferences modal and record the appointment-reminder dialog as a passing check.
  7. For every finding, record the expected behavior, observed behavior, user impact, and remediation direction.

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

Exercise workspace

Account settings modal dialogs 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. Compare what is announced when each modal opens and note where keyboard focus starts.
  2. Move forward and backward through every focusable item, then try a control behind each modal and press Escape.
  3. Inspect the contact-preferences dialog's accessible name and compare what happens to focus after each visible close button is used.
Solution

The contact-preferences modal contains six related findings. The appointment-reminder dialog is a passing check that preserves the platform's native modal behavior.

The contact-preferences dialog has no accessible name

The dialog has a visible heading but does not reference it with aria-labelledby or provide another accessible name. Associate the visible heading with the dialog.

Focus remains on the opener

Revealing the custom modal does not move focus inside it. Move focus deliberately to the most suitable element in the dialog when it opens.

Keyboard focus can leave the custom modal

Tab and Shift+Tab can move between the dialog and surrounding page. Contain sequential focus within the active custom modal.

Background content remains available

Controls behind the custom modal can still receive focus and be activated. Make content outside the active custom modal inert, then restore it when the modal closes.

Escape does not close the custom modal

The custom implementation does not handle the conventional Escape close request. Add Escape support while preserving any intentional cancellation logic.

Closing does not restore focus

The visible close button hides the custom modal without returning focus to the control that opened it. Remember the invoking element and restore focus when it remains available.