Accessibility Testing Plan for an App Release
Plan accessibility testing for a mobile app release: screen readers, text size, contrast, touch targets and pass criteria.
The Open buttons send the prompt text as currently shown below to that site only when you click. Fill in the placeholders first.
[VERIFY] is an editorial flag, not a blank to fill. Wherever the prompt shows [VERIFY], check that item against a reliable source before you use it.
Plan release testing. Features in this release: [FEATURES]. Devices and settings: [DEVICES]. Team: [TEAM]. Create a checklist by feature, a manual test of 20 minutes per screen reader and per large text, defect severity levels, a release gate such as no critical barriers in core flows, and a feedback channel. Return a plan and a defect template. Add a worked plan for an invented release. Features: new search screen, checkout change, notification settings. Test matrix: two screen reader and operating system combinations, large text at the largest setting, reduced motion, dark mode, voice control on one device and keyboard on a tablet if supported. Time estimate: 20 minutes per screen per combination; with 8 screens and 4 combinations that is 640 minutes or 10.7 hours, shown as 8 x 4 x 20 = 640. Prioritise core flows first: sign in, search, checkout. Severity levels: blocker for tasks that cannot be completed, major for tasks that are very hard, minor for inconvenience. Release gate: no blockers, no more than two majors with workarounds and plans, and sign-off from a named owner. Defect template: ID, screen, device and version, steps, expected, observed, severity, owner and fix date. Add a feedback channel for users after release and a commitment to respond to reported barriers within a stated time. Include a regression list of earlier accessibility bugs that must not return. Suggest user testing with people who use assistive technology once per quarter, compensated fairly, and a rule to add accessibility acceptance criteria to every new feature before development. Record test results in a shared log and review the trends monthly. Mention that this plan supports but does not replace specialist audits where conformance claims are required [VERIFY]. Finish with a short retrospective after each release: which defects were found late, which tests found the most, and what to automate next. Record the answers in the shared log so that the plan improves with each cycle and new team members can see the history.
Fill in before use
Optional: type your details and the prompt above updates. Nothing is saved or sent.
Replace each bracketed placeholder with your own details, then paste into Any AI or another assistant.
See an example result (fictional data)
Invented plan. 8 screens, 4 setting combinations, 20 minutes each: 8 x 4 x 20 = 640 minutes = 10.7 hours. Core flows first: sign in, search, checkout. Severity: blocker, major, minor. Release gate: no blockers; at most two majors with workarounds and dates; sign-off by a named owner. Result of a sample run: 32 checks, 27 passed (84 percent), 4 minor, 1 major (stepper not announced). Decision: fix the major and release; schedule minors for the next sprint. Retest date: the first working day after the fix is merged; record the result in the shared log.
Illustrative only, made-up data. Your results will differ and must be reviewed.