Accessibility Test Cases

A11Y-TBK-003

TalkBack with Chrome on physical Android: Forms, instructions and errors

Generated file current Authoring: Content complete
What file status means

This status reports only whether the generated procedure matches the current controlled source hash. It is not independent content verification, regulatory approval, product evidence or a conformance decision.

Recorded standards review: No optional specialist review recorded. Next review: Not scheduled.

MethodMobile screen-reader journey
TesterExperienced mobile screen-reader tester
Indicative effort74–107 min small scope

Complete a form, trigger validation errors, recover and confirm success using real TalkBack with Chrome on physical Android.

Available formats

Use this test in the format you need

The HTML procedure includes the working worksheet. JSON provides the structured source data. Editable Markdown files are delivered inside package downloads.

Purpose

What this test checks

Complete a form, trigger validation errors, recover and confirm success using real TalkBack with Chrome on physical Android.

What this result means: This procedure records how Complete and correct a form with TalkBack with Chrome on physical Android behaves on android-talkback-chrome. It can expose evidence relevant to WCAG 1.3.1, 3.3.1, 3.3.2, 3.3.3 and 4.1.2 for the tested task and environment. Use the linked conformance procedures for WCAG 1.3.1, 3.3.1, 3.3.2, 3.3.3 and 4.1.2 to assess the complete requirements across the declared conformance scope.

Why it matters

Detect form journeys whose labels, instructions, errors, focus or status changes are missing, misleading or unusable when using TalkBack with Chrome on physical Android. People most likely affected: blind and low-vision people using the named screen reader and browser combination. Users may enter incorrect data, be unable to find or correct errors, lose context or fail to confirm submission. In the recorded android-talkback-chrome environment, check explore-by-touch, sequential swipes, rotor or local-context navigation, gestures and focus recovery; a gesture conflict or lost virtual focus can make the current screen unusable.

When to use it

Apply when the product includes a form that must be evaluated for practical interoperability with TalkBack with Chrome on physical Android. This is a journey, not a substitute for criterion-specific WCAG testing.

Confirm before starting

Mark it not applicable only when

Exceptions

This platform journey has no normative exception of its own. Any exception affecting a linked WCAG criterion must be evaluated in the separate criterion-specific procedure.

Prepare

What you need

  • A physical supported phone or tablet is available; browser device emulation is prohibited for real mobile coverage.
  • The built-in screen reader and browser are updated to the recorded versions.
  • The tester has completed the vendor tutorial and is proficient with the configured gestures/rotor or reading controls.
  • The journey uses authorised synthetic or controlled client data.

Targets and required variations

  • The complete form journey and each unique field, instruction, error, status message and focus transition encountered.
  • Initial, data-entry, each validation-error class, interruption, recovery, successful submission and confirmation.
  • Portrait and landscape for mobile where the product supports both; documented browser zoom and viewport for desktop.

Clean state

  • Use a clean browser profile or record every extension and preference that can alter the accessibility tree or form behaviour.
  • Restart the browser, load the known-good calibration fixture first and confirm expected focus and speech output.
  • Clear product test data only through an authorised, non-destructive test account workflow.

Effort estimate

Setup
25 min
Per target
25 min
Evidence
12 min
Technical review
12 min

Assumptions: one short journey on one physical device and orientation; repeat supported orientations and materially different gesture paths

Variation: Add a new per-target execution and evidence allowance for each additional target class or state that could produce a different result. Add setup time for each distinct environment.

Excluded: Client coordination, inaccessible-environment recovery, recruitment, legal review, remediation implementation and waiting time unless the procedure states otherwise.

Execute

Test steps

Follow each action in order. The expected result is always visible; open the guidance when you need setup, tool, evidence, decision or repeat details. Step-level recording is optional while work is in progress and required only to export a completed execution.

Step 1

Record the form journey and safe data

Purpose: Freeze the form path and expected states before using a screen reader.

User impact: Missing error or recovery states can produce a false impression that the journey is usable.

Record the entry route, completion point, field types, instructions, empty/malformed/conflicting validation cases, interruption point, recovery path and confirmation state.

Expected result

Every state has a stable identifier and safe input data.

Failure observation

A required state, route or safe value is missing or cannot be restored.

Setup, evidence and decision guidance
Target
One complete form from its entry point to confirmation.
Required state
Known build, authorised account, blank form and synthetic data set.
Tool or command
Journey inventory and controlled test-data reference.
Record
Journey/state inventory, build, account type and data-set ID.
Pass
All planned states are reproducible.
Fail
The inventory omits a materially different form or validation state.
Not applicable
No form journey exists in the agreed sample.
Blocked
Permissions or safe data prevent access to a required state.
Repeat or recover
Resolve access and data blockers before AT execution; never use live personal data to fill the gap.
Limitations
This is test preparation, not real screen-reader evidence.
If you are new to this test
Resolve access and data blockers before AT execution; never use live personal data to fill the gap.
Record this step

Step 2

Record the real TalkBack environment

Purpose: Make later observations reproducible and distinguish product behaviour from platform configuration.

User impact: Unrecorded versions and settings make findings difficult to review or retest.

Record TalkBack 16.2 with Chrome 138 on a physical Android 15 device; record the actual device and later versions when used. Include speech/verbosity, keyboard or gesture configuration, orientation where relevant, extensions and display/text settings.

Expected result

All material versions, device details and settings are recorded before product testing.

Failure observation

The execution uses simulation, an unrecorded version or a materially customised setting that is not disclosed.

Setup, evidence and decision guidance
Target
The exact screen-reader, browser and operating environment.
Required state
Clean browser profile, default screen-reader settings except recorded user preferences, product at the frozen build.
Tool or command
A physical Android device with TalkBack and Chrome; emulator or accessibility-tree inspection cannot satisfy real-device coverage.
Record
Environment ID, version strings, settings export or screenshots and real-device attestation.
Pass
A real, fully recorded environment is used.
Fail
Do not assign a product failure solely from this setup record; correct the environment and repeat.
Not applicable
The procedure is outside the approved plan.
Blocked
The real screen reader or physical device is unavailable.
Repeat or recover
Mark execution blocked. Automation or tree inspection may be attached as supporting diagnostics but cannot replace this run.
Limitations
Results apply only to the recorded environment pair and settings.
If you are new to this test
Mark execution blocked. Automation or tree inspection may be attached as supporting diagnostics but cannot replace this run.
Record this step

Step 3

Run the known-good form control

Purpose: Demonstrate that the environment can expose a labelled field, error and status before testing the product.

User impact: A broken lab setup can otherwise be misreported as a product defect.

Using Use one-finger swipe right/left, explore by touch, double-tap activation and the on-screen keyboard. Record any customised gesture instead of assuming it is universal. Enter the labelled control, submit it empty, locate its error, correct it and confirm the success status against the fixture answer key.

Expected result

The control produces the frozen expected announcements and focus transitions.

Failure observation

The calibration output differs materially from its answer key or cannot be completed.

Setup, evidence and decision guidance
Target
The version-frozen calibration form linked by the test plan.
Required state
Same environment as S2; calibration fixture reset to blank.
Tool or command
TalkBack 16.2 with Chrome 138 on a physical Android 15 device; record the actual device and later versions when used.
Record
Fixture ID/version/hash, exact output transcript, commands/gestures and result.
Pass
The environment passes every calibration checkpoint.
Fail
Stop product testing and repair or replace the environment; this is not a product finding.
Not applicable
The approved plan explicitly supplies an equivalent, version-frozen calibration with its own answer key.
Blocked
No valid calibration fixture can be executed.
Repeat or recover
Restart the screen reader and browser/device once; if still failing, create an environment blocker.
Limitations
Calibration validates the test environment only; it does not prove product accessibility.
If you are new to this test
Restart the screen reader and browser/device once; if still failing, create an environment blocker.
Record this step

Step 4

Discover the blank form and its instructions

Purpose: Check that a nonvisual user can find the form and understand what is required before entering data.

User impact: Hidden context or instructions cause avoidable errors and abandonment.

Use linear swipe navigation first; use the recorded TalkBack reading-control gesture only for the selected control type and return to linear order afterward. Identify the form purpose, required-field convention, first control name/role/state and any format or privacy instruction without visual assistance.

Expected result

Purpose and instructions are announced in a logical order before they are needed.

Failure observation

The form cannot be found, instructions are skipped or ambiguous, or required meaning depends on visual position alone.

Setup, evidence and decision guidance
Target
The form heading, introductory instructions and first control.
Required state
Blank form at its entry route with focus at page or screen start.
Tool or command
TalkBack 16.2 with Chrome 138 on a physical Android 15 device; record the actual device and later versions when used.
Record
Exact speech transcript, navigation commands/gestures, focus sequence and control metadata.
Pass
All necessary context is discoverable before input.
Fail
One or more necessary instructions are absent or not programmatically available.
Not applicable
The selected target contains no form.
Blocked
The form cannot be loaded or the AT environment has become invalid.
Repeat or recover
Return to the known start and repeat once; if output changes, retain both runs and classify the result cannot-tell pending review.
Limitations
This scenario covers discovery and instructions, not field entry or validation.
If you are new to this test
Return to the known start and repeat once; if output changes, retain both runs and classify the result cannot-tell pending review.
Record this step

Step 5

Enter data in one representative field type

Purpose: Verify a control exposes enough name, role, value and input purpose to enter and review data.

User impact: Incorrect field semantics can prevent entry, review or correction.

Use one-finger swipe right/left, explore by touch, double-tap activation and the on-screen keyboard. Record any customised gesture instead of assuming it is universal. Announce the control, enter the authorised value, move away, return and review its name, role, state and value.

Expected result

The control is operable and the entered value remains understandable when revisited.

Failure observation

The control lacks an understandable name/role/state, cannot accept input, loses the value or announces a misleading value.

Setup, evidence and decision guidance
Target
One selected instance of each unique field type in the sample.
Required state
Focus on the first selected field; blank value; instructions already reviewed.
Tool or command
TalkBack 16.2 with Chrome 138 on a physical Android 15 device; record the actual device and later versions when used.
Record
Control ID, exact output before/after entry, input used and resulting value/state.
Pass
Each selected unique field type meets the observation.
Fail
Any selected field type produces the failure observation.
Not applicable
The form has no editable or selectable controls.
Blocked
A required input method, permission or safe value is unavailable.
Repeat or recover
Reset only the affected field and repeat; do not test several field types in one evidence record.
Limitations
A passed representative field does not cover materially different control implementations.
If you are new to this test
Reset only the affected field and repeat; do not test several field types in one evidence record.
Record this step

Step 6

Submit the form with an empty required field

Purpose: Verify the user is told an error occurred and can locate the affected field.

User impact: Silent or disconnected errors prevent correction and task completion.

Submit once. Without visual assistance, determine that submission failed, locate the empty field and read its error. Use Use linear swipe navigation first; use the recorded TalkBack reading-control gesture only for the selected control type and return to linear order afterward.

Expected result

The error is announced or discoverable, identifies the field and explains that a value is required.

Failure observation

No error is exposed, focus moves unpredictably, the field cannot be located or the message does not identify the problem.

Setup, evidence and decision guidance
Target
One required field and the form submission response.
Required state
Required field empty; all other mandatory fields contain valid synthetic data.
Tool or command
TalkBack 16.2 with Chrome 138 on a physical Android 15 device; record the actual device and later versions when used.
Record
Submission command, focus before/after, exact announcement, error text and field relationship.
Pass
The user can detect, locate and understand the empty-field error.
Fail
Any required part of detection, location or understanding fails.
Not applicable
The selected form has no required fields.
Blocked
The invalid state cannot be produced safely.
Repeat or recover
Restore valid data to every other field and repeat once; retain server/network errors separately.
Limitations
This scenario covers the empty-required validation class only.
If you are new to this test
Restore valid data to every other field and repeat once; retain server/network errors separately.
Record this step

Step 7

Submit one malformed value

Purpose: Verify format validation gives a usable correction path.

User impact: Generic error messages force trial and error and increase cognitive load.

Submit once, locate the field without visual assistance, read the error and determine the expected format before changing the value.

Expected result

The error identifies the field, problem and usable correction without relying only on colour or position.

Failure observation

The message is absent, generic, detached or does not communicate a correction.

Setup, evidence and decision guidance
Target
One field with a declared format rule, such as email or date.
Required state
The target field contains one controlled malformed value; other required fields are valid.
Tool or command
TalkBack 16.2 with Chrome 138 on a physical Android 15 device; record the actual device and later versions when used.
Record
Malformed value class, exact error output, focus path and field/error relationship.
Pass
The correction is understandable from the exposed message and instructions.
Fail
The exposed information does not support correction.
Not applicable
No sampled field has a format rule.
Blocked
The safe test environment rejects submission before the target validation runs.
Repeat or recover
Remove unrelated invalid data and repeat only this validation class.
Limitations
Do not infer coverage of out-of-range or conflicting-value errors.
If you are new to this test
Remove unrelated invalid data and repeat only this validation class.
Record this step

Step 8

Recover after an interruption

Purpose: Check whether entered context survives a realistic interruption and return.

User impact: Data loss or lost focus can force users to restart lengthy tasks.

Use the test plan's safe interruption, such as navigating to help and returning or backgrounding and restoring the app. Return once and review focus, context and entered values.

Expected result

The user returns to an understandable location with expected data preserved or receives a clear warning before loss.

Failure observation

Focus resets without explanation, context is lost, or entered data disappears without warning.

Setup, evidence and decision guidance
Target
The form at the approved interruption point.
Required state
At least two fields completed; focus on the recorded control.
Tool or command
TalkBack 16.2 with Chrome 138 on a physical Android 15 device; record the actual device and later versions when used.
Record
Interruption action, before/after focus and values, time away and exact output on return.
Pass
Recovery preserves or clearly explains context and data.
Fail
Unexpected loss or disorientation occurs.
Not applicable
The approved journey has no interruption or recovery path.
Blocked
The environment terminates for an unrelated reason.
Repeat or recover
Repeat from a clean start; report intermittent behaviour with both evidence sets.
Limitations
This covers the recorded interruption only, not every browser or operating-system event.
If you are new to this test
Repeat from a clean start; report intermittent behaviour with both evidence sets.
Record this step

Step 9

Correct errors and confirm completion

Purpose: Verify the user can complete the full form and understand the resulting status.

User impact: A technically submitted form is not usable if success or the next action is unclear.

Correct each known error, submit once, then review the confirmation heading/status, reference number and next action without visual assistance.

Expected result

Submission completes, the confirmation is announced or discoverable and the next action is understandable.

Failure observation

An error persists without explanation, focus is lost, or success and next action are not exposed.

Setup, evidence and decision guidance
Target
All fields, correction path, submit control and final confirmation.
Required state
Known error state from S6 or S7 with valid corrections available.
Tool or command
TalkBack 16.2 with Chrome 138 on a physical Android 15 device; record the actual device and later versions when used.
Record
Corrections, final command, exact confirmation output, focus destination and reference value using synthetic data.
Pass
The form completes and confirmation is understandable.
Fail
Completion or confirmation fails for the recorded state.
Not applicable
The selected workflow intentionally has no submission or confirmation.
Blocked
A service outage or test-account restriction prevents submission.
Repeat or recover
Record external service failures as blockers, restore the known state and repeat only after service recovery.
Limitations
Passing this journey is platform- and sample-specific; it does not establish WCAG conformance or universal usability.
If you are new to this test
Record external service failures as blockers, restore the known state and repeat only after service recovery.
Record this step

Decide

How to decide

Passed

Using the recorded real TalkBack with Chrome on physical Android environment, the tester completes the selected form from entry through validation, correction, interruption/recovery and confirmation; labels, instructions, errors, focus and status output are understandable and usable.

Failed

A barrier in the selected environment prevents independent completion or recovery, presents materially misleading output, hides an error or confirmation, or makes required form interaction unusable.

Not applicable
No form journey exists in the selected subject for this platform evaluation.
Cannot tell
Calibration passes and the behaviour is reproducible, but product, browser, operating-system, assistive-technology or configuration responsibility cannot be determined.
Not tested
The target is applicable, but a required state, environment, action or evidence item was not completed.
Aggregation and reporting boundaries

Aggregation: Preserve the whole-journey outcome and target-level observations. A critical failed state prevents a passed journey; cantTell and untested remain unresolved.

WCAG decision: This journey never sets a WCAG criterion to satisfied. It supplies platform evidence and may identify issues for separate atomic and criterion-level procedures.

Automation: Accessibility-tree inspection and automation may support diagnosis but cannot replace the real assistive-technology execution.

Record

Record the result

Record the target, state and observed behaviour. Add evidence or technical details only when needed.

Choose the option that best matches what happened to this target.

Describe the actual behaviour and why it supports the selected result.

When more than one target is recorded, the overall procedure result is calculated from all target results.

Environment: Not set.
Add evidence or details

Choose only the group needed for this record. These fields remain optional for a working draft.

Evidence references

Enter one file name, issue ID or evidence reference per line. Files stay on your device.

Test environment

Save a named profile once to reuse the same product, platform and environment details on other procedures in this browser.

Engagement and tester identifiers

Assistive-technology execution confirmation

Use these statements only for work actually performed. Simulation or accessibility-tree inspection does not count as real assistive-technology coverage.

Formal completion and limitations

Identify the frozen list or sampling record used to select every target represented by this execution.

Choose a final result before marking the execution complete. Completed records require the full environment, step, evidence and method-specific information.

Data management

Export before clearing if the record must be retained. Apply the engagement retention schedule and delete browser data when it is no longer needed.

Saved drafts stay in this browser and are not uploaded. Do not enter credentials, secrets or unnecessary personal data.

Reference

Supporting information

Standards and requirement mappings
  • W3C-WCAG22 · 1.3.1 secondary · partial

    This Mobile screen-reader journey observes Complete and correct a form with TalkBack with Chrome on physical Android in the recorded android-talkback-chrome environment. Use the linked WCAG 1.3.1 conformance procedure to evaluate all normative parts of WCAG 1.3.1 across the declared scope.

  • W3C-WCAG22 · 3.3.1 secondary · partial

    This Mobile screen-reader journey observes Complete and correct a form with TalkBack with Chrome on physical Android in the recorded android-talkback-chrome environment. Use the linked WCAG 3.3.1 conformance procedure to evaluate all normative parts of WCAG 3.3.1 across the declared scope.

  • W3C-WCAG22 · 3.3.2 secondary · partial

    This Mobile screen-reader journey observes Complete and correct a form with TalkBack with Chrome on physical Android in the recorded android-talkback-chrome environment. Use the linked WCAG 3.3.2 conformance procedure to evaluate all normative parts of WCAG 3.3.2 across the declared scope.

  • W3C-WCAG22 · 3.3.3 secondary · partial

    This Mobile screen-reader journey observes Complete and correct a form with TalkBack with Chrome on physical Android in the recorded android-talkback-chrome environment. Use the linked WCAG 3.3.3 conformance procedure to evaluate all normative parts of WCAG 3.3.3 across the declared scope.

  • W3C-WCAG22 · 4.1.2 secondary · partial

    This Mobile screen-reader journey observes Complete and correct a form with TalkBack with Chrome on physical Android in the recorded android-talkback-chrome environment. Use the linked WCAG 4.1.2 conformance procedure to evaluate all normative parts of WCAG 4.1.2 across the declared scope.

  • W3C-MOBILE · W3C-MOBILE platform · supporting

    This source does not override WCAG or create an additional WCAG conformance requirement.

  • GOOGLE-TALKBACK · GOOGLE-TALKBACK platform · supporting

    This source does not override WCAG or create an additional WCAG conformance requirement.

  • GOOGLE-ANDROID-TESTING · GOOGLE-ANDROID-TESTING platform · supporting

    This source does not override WCAG or create an additional WCAG conformance requirement.

  • W3C-WCAG22-TECHNIQUES · W3C-WCAG22-TECHNIQUES platform · supporting

    This source does not override WCAG or create an additional WCAG conformance requirement.

Supporting and advisory guidance

Supporting sources are identified in the mappings and source register. They do not add conformance requirements.

Evidence specification
  • Environment record

    Exact OS, browser, assistive-technology, physical device where applicable, settings and clean-state declaration.

    Use a redacted extract or evidence reference. Do not include credentials, secrets or unnecessary personal data.

  • Calibration record

    Fixture/version, actions, expected output and actual output.

    Use a redacted extract or evidence reference. Do not include credentials, secrets or unnecessary personal data.

  • Assistive technology output

    Displayed speech output or a contemporaneous exact transcript, gesture, accessibility focus target and orientation. for initial, error, recovery and confirmation states.

    Use a redacted extract or evidence reference. Do not include credentials, secrets or unnecessary personal data.

  • Journey record

    Task steps, independent completion, assistance, interruption, recovery, confirmation and issue references.

    Use a redacted extract or evidence reference. Do not include credentials, secrets or unnecessary personal data.

  • Responsibility record

    Product, browser, OS, assistive-technology and configuration checks plus unresolved questions.

    Use a redacted extract or evidence reference. Do not include credentials, secrets or unnecessary personal data.

Worked example and outcome calibration

A11Y-TBK-003-WORKED-001: representative worked example

Context: Representative synthetic example of the Civic Benefits Portal address form on Android; not a physical-device TalkBack run.

Inspected: Linear navigation, postcode entry, empty required error, rotation/recovery and confirmation.

Observed output: The representative accessibility snapshot exposes the postcode error after Submit, but the live status is ordered after footer links and the input is not identified in the message.

Evidence:

  • EVD-REF-010 representative accessibility snapshot
  • EVD-REF-011 gesture/focus sequence
  • EVD-REF-012 error relationship extract

Tester reasoning: The error is technically present but not timely or identifiable in the expected linear path. Real TalkBack behaviour is unverified, so execution is blocked rather than passed or failed.

Decision: blocked

Finding: FND-REF-003 — Postcode error appears after unrelated footer content. A mobile screen-reader user may not discover why submission failed.

Remediation: Place the error summary directly after the page heading or move accessibility focus to it on failed submission; identify the Postcode field and associate its inline error.

Reviewer feedback: Reviewer required the report to distinguish tree order from a real TalkBack announcement and replaced a claimed failure with a blocked execution plus a review issue.

Final client wording: Supporting inspection indicates that the postcode validation message follows unrelated footer content. Run the approved physical-device TalkBack scenario before confirming the client-facing finding.

Retest: RT-REF-004 remains blocked pending a physical Android/TalkBack run; static ordering is corrected in the representative fixed fixture.

Boundary: This is a representative, synthetic worked example for training and calibration. It is not evidence from a client product, participant or real assistive-technology execution.

Outcome calibration

Passed
The tester discovers instructions, completes the form, finds and corrects each error, recovers after interruption and confirms submission without visual assistance.

The complete journey is usable in the exact recorded TalkBack with Chrome on physical Android environment.

Failed
After invalid submission, focus moves but the screen reader announces neither an error nor the affected field, and the tester cannot locate the problem.

A validation barrier prevents independent recovery in the selected journey.

Not applicable
The selected product area contains no form journey.

No journey target matches applicability.

Cannot tell
The same field works in calibration but fails only in the product; browser and assistive-technology evidence conflict and responsibility remains unresolved.

Record the behaviour and use cantTell rather than unsupported attribution.

Not tested
The success path was completed, but validation-error and recovery states were not executed.

Required journey states remain untested.

Sampling, complete processes and platform limitations

Run each selected critical journey from start to finish, including its main error and recovery paths. Record which journeys and states were included.

If this check is part of a user journey, test the selected journey from start to finish, including relevant errors and recovery. Record any path that was not tested.

  • Physical-device evidence applies only to the recorded device, operating system, browser, screen-reader version and settings.
  • Check relevant browser, tool or assistive-technology release notes before assigning unexpected behaviour to the product.
  • If responsibility is unclear, record the reproducible behaviour and use cannot tell until it is resolved.
Related procedures
  • A11Y-WCAG-007
  • A11Y-WCAG-048
  • A11Y-WCAG-049
  • A11Y-WCAG-050
  • A11Y-WCAG-054
ACT rules and WCAG technique traceability

This is a project-authored manual procedure, not a W3C Approved ACT Rule. An ACT result can support only the part of this procedure covered by that rule. It does not replace the remaining manual or assistive-technology checks.

No supporting W3C Approved ACT Rule is selected for this procedure.

  • Understanding SC 1.3.1. Techniques are examples, not extra requirements. Record any technique or common failure used, but decide the result against the success criterion.
  • Understanding SC 3.3.1. Techniques are examples, not extra requirements. Record any technique or common failure used, but decide the result against the success criterion.
  • Understanding SC 3.3.2. Techniques are examples, not extra requirements. Record any technique or common failure used, but decide the result against the success criterion.
  • Understanding SC 3.3.3. Techniques are examples, not extra requirements. Record any technique or common failure used, but decide the result against the success criterion.
  • Understanding SC 4.1.2. Techniques are examples, not extra requirements. Record any technique or common failure used, but decide the result against the success criterion.
Review history and source register
  1. 2026.08.27-rc.9 — Reworked for plain language, case-focused steps, scoped evidence and transparent draft review status.
  2. 2026.08.27-rc.9 — Migrated to professional catalogue schema v3 with separated outcomes, structured authority, applicability, evidence, decision and review records.
  3. 2026.08.27-rc.9 — Specialist procedure mapped to its task family and current first-party platform guidance and checked for internal consistency; competent review and real execution remain separate.
  4. 2026.08.27-rc.9 — Replaced migrated boilerplate with a case-specific reference implementation and completed generated-file integrity review.
  5. 2026.08.27-rc.9 — Rewritten as an atomic professional-delivery flagship with component effort guidance and a complete representative worked example.
  6. 2026.08.27-rc.9 — Procedure guidance and presentation simplified without changing draft governance status.

Review decision: pending. Open issues: No real TalkBack with Chrome on physical Android execution has been performed or claimed. A registered real-platform adapter must execute the calibration and journey, followed by a distinct competent review, before platform coverage can be recorded.; The linked WCAG criteria remain secondary partial mappings and require separate atomic or criterion-level assessment.

Source historyReport an accuracy issue
WCAG
SC 1.3.1, SC 3.3.1, SC 3.3.2, SC 3.3.3, SC 4.1.2
Execution
Real device and assistive technology
Catalogue version
2026.08.27-rc.9