Test a delivery address dialog with the keyboard
A worked example covers focus order, cancellation and saving in an address dialog, making keyboard failures reproducible.
A delivery address dialog must be fully operable with the keyboard. Test the entire flow from opening it to returning to the page. Reaching the Save button alone is insufficient.
This example is fictional: address D-17 in a customer portal is “Hafenweg 8”. The person wants to change the house number to 10. The dialog contains street and house number fields, plus “Cancel” and “Save address”. This is a manual functional test, not a comprehensive accessibility assessment.
Record the failure as a sequence
In the assumed initial state, the dialog opens but focus stays on “Change delivery address” behind the dimmed surface. Pressing Tab then reaches footer links. The visible address fields are skipped. A mouse test could easily have missed this failure.
Record the starting page, trigger, keys used and element actually receiving focus. Development can then reproduce the same problem. Use a safe environment with test data; do not change a real customer address experimentally.
Define the expected behaviour
For this short dialog, the Street field is a sensible initial focus position. Long dialogs or those with significant consequences may need a different position. The WAI dialog pattern explains these distinctions.
Action | Expected result in the example |
|---|---|
Reach the trigger with Tab, then press Enter | Dialog opens; focus is visible in the Street field. |
Move forward with Tab | Street, house number, Cancel, Save address; then Street again. |
Move backwards with Shift+Tab | The same controls in reverse order; no movement behind the dialog. |
Enter house number 10, then press Escape before saving | Dialog closes; focus returns to the trigger; D-17 remains Hafenweg 8. |
Reopen and save 10 | Success appears only after confirmed saving; D-17 shows Hafenweg 10. |
Saving is rejected by business rules | Understandable error; inputs are preserved; the affected area is reachable. |
The Tab sequence applies to this particular example. Your interface may contain additional controls.
Fix the cause in the appropriate place
Use real buttons for actions and correctly labelled fields. A custom dialog needs an accessible name and correctly implemented focus management. role="dialog" or aria-modal="true" alone neither blocks the background nor implements keyboard interaction.
Development must consider opening, keeping focus within the active modal dialog and closing together. Here, the trigger still exists when the dialog closes. If another flow removes it, a different logical return position is needed. Styling must not remove the visible focus indicator.
Test closing while a save is pending
Escape does not automatically recall an already submitted server request. In this example, the window may also close during processing. The page continues to show “Address change is processing” for D-17. A confirmed response updates the address; an uncertain outcome remains unresolved. “Change discarded” would be incorrect in that situation.
Repeat the corrected test in supported browsers and with a suitable screen reader configuration. Record observations and outstanding failures. The repaired keyboard flow says nothing yet about every other page, contrast or item of content.
Sources
Read more
All articles
Design & UX with ASES
User experience, interfaces and brand presence