Testing dynamic and authenticated tasks

What you will learn

• Assess control names, roles, states, values, instructions, keyboard operation, and screen-reader output.
• Follow a form through initial, invalid, corrected, and successful states.
• Compare visible dynamic changes with announcements, timing, and focus behavior.
• Test warnings, extensions, expiry, preserved work, and return to an interrupted task.
• Evaluate authentication assistance, verification, cognitive-function requirements, errors, and recovery.
• Maintain reproducible evidence across a changing task without confusing accessibility testing with security assessment or universal compatibility claims.

Follow the path

1. Path checkpoint

   Prepare a safe, reproducible test environment

   Prepare fictional test data, record the environment and starting state, and keep observations safe and reproducible.

   15 minutes

2. Testing method

   Testing controls with a screen reader

   Check whether common controls expose useful names, roles, states, values, keyboard behavior, and changes after interaction.

   25 minutes

3. Exercise

   Testing controls in a community events finder

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

   25 minutes

4. Testing method

   Testing forms and validation

   Check whether people can understand, complete, correct, and successfully submit a form.

   25 minutes

5. Exercise

   Testing a community-course registration form

   Complete, invalidate, correct, and submit a realistic registration form while examining its form relationships and messages.

   25 minutes

6. Path checkpoint

   Track state, context, and recovery

   Use one evidence structure to follow visible changes, announcements, focus, retained values, and recovery across task states.

   15 minutes

7. Testing method

   Testing status messages and live updates

   Check whether dynamic updates are communicated at the right time and priority without unnecessarily moving focus or interrupting a task.

   30 minutes

8. Exercise

   Testing status messages in a community activities search

   Investigate how a dynamic activities search communicates loading, results, saving, removal, no-results, and urgent-error updates.

   30 minutes

9. Testing method

   Testing time limits and interruptions

   Check whether people have enough time, receive useful warnings, can extend a session, and can recover their work after interruption.

   25 minutes

10. Exercise

    Testing session timeout in a community-support application

    Complete and interrupt a fictional multi-step application while testing its warning, extension, expiry, and recovery behavior.

    30 minutes

11. Testing method

    Testing authentication and verification

    Check whether people can sign in and complete verification without unsupported memory, transcription, or recovery barriers.

    30 minutes

12. Exercise

    Testing authentication for a community-services booking

    Investigate input purposes, paste, password reveal, verification, memory demands, errors, and recovery in a fictional sign-in flow.

    35 minutes

Complete this path across several sessions if needed. Revisit each Testing method while you complete its paired Exercise, and keep your notes so you can compare how information and task context change from one state to the next.

The Exercises use separate fictional interfaces rather than one continuous service. Carry the same evidence structure between them, not application state or one accumulating target finding count. A useful test may record passing behavior, a support limitation, or a finding; it does not need to discover a defect in every category.

Prepare a safe, reproducible test environment

Use fictional information provided by the Exercise or other explicitly authorized test data. Do not enter real credentials or personal information, trigger production lockouts or recovery messages, or complete destructive submissions merely to reach a test state.

Before each Exercise:

1. Record the browser, operating system, viewport, input method, screen reader, versions, and relevant settings.
2. Note any browser assistance or password manager you will use when the task reaches authentication.
3. Read the practice-data notice and learn how to return the interface to its deterministic initial state.
4. Record the state you start from before operating a control, submitting a form, waiting for an update, or allowing a session to expire.
5. Keep visible, keyboard, focus, and screen-reader observations distinct so that one result is not mistaken for another.

This preparation supports an accessibility review. It does not authorize security testing or establish that the fictional Exercise behavior represents a production system.

Track state, context, and recovery

Controls and validation establish the task states you will examine in the later methods. Use one consistent evidence structure as you move from ordinary interaction to dynamic updates, interruptions, and authentication.

For each relevant observation, record:

• the task and starting state;
• the trigger or input;
• the visible result;
• the announced result and its timing;
• focus before and after the change;
• values and context that were retained or cleared;
• the available recovery and the task position to which the person returned;
• the expected result, actual result, and user impact;
• the tested environment and support limitations; and
• a remediation direction and retest condition.

Not every field applies to every observation. Use the structure to preserve the evidence that matters, connect related behavior across states, and avoid reporting several symptoms of one underlying problem as unrelated findings.

Where to go next

Apply these skills together in Reviewing a community-services appointment change. The journey combines controls, validation, dynamic confirmations, a session warning, reauthentication, preserved work, and return to the original task in one realistic workspace.

Use Your first accessibility review when you want a broader foundation in automated, keyboard, visual, text-spacing, zoom, and forms testing.

Use Testing display preferences, touch, and media for focused practice with forced colors, reduced motion, touch, orientation, and prerecorded media.

Use Practical screen-reader testing for more focused practice with page structure, data tables, controls, images, graphics, language changes, and modal dialogs.

These paths are optional supporting routes. You do not need to complete any of them before working through this self-contained sequence.

Keep the scope in mind

These five techniques do not form a comprehensive accessibility or conformance assessment. One browser and assistive-technology combination cannot establish universal compatibility, and accessibility testing does not determine whether an authentication system is secure enough for a service’s threat model. For real services, define the review boundary, arrange specialist work where needed, and involve disabled people whose experiences and ways of using technology may differ from your own.

Read about the full scope and limitations of the Lab, including what its technical checks can and cannot establish.