What this clause covers
The public contents gives evaluation three steps. First set the content usability testing goals. Then define the measures and requirements that say whether the help worked. Then test for mobile applications. The order matters. A team that starts with a test script and looks for measures afterwards will report what it happened to observe. The mobile step is also a warning about method. A phone in a lab, on a fast network, with a moderator sitting beside the participant, is not the setting the help will meet. The draft leaves the exact measures open, so the team has to choose and defend them. That is an opportunity: completion, time, errors, findability and confidence can all be defined in a way that fits the app.
The headings in this clause
8.1Content usability testing goals8.2UA measures and requirements8.3UA testing for mobile applications
What to put in place before publication
- Write the testing goals before the first session and tie each one to a decision the team can take.
- Choose measures that fit the help, such as task completion, time to answer, wrong turns, findability and confidence.
- Set a baseline on the current release so a later result can be compared with something.
- Test on real devices and real networks, including a small screen, a slow connection and an interrupted session.
- Include first time and expert users, and record which group each finding came from.
- Keep consent, recording and personal data handling in the test plan, and delete what you do not need.
Evidence to keep
| Evidence | What it looks like |
|---|---|
| Goals | A test plan with goals written before the sessions |
| Measures | A measures table with definitions and a baseline |
| Devices | A device and network matrix used for the sessions |
| Findings | A findings log with severity, audience and a decision |
| Privacy | Consent and data handling records for the sessions |
The test a reviewer runs
- Were the measures chosen before the test, or after the results?
- Did the test run on a real phone and a real network?
- Were first time and expert users both represented?
- Is there a baseline from the previous release?
- Did every finding get an owner and a decision?
Where teams usually fall short
- The test is a desktop session with the browser narrowed to phone width.
- Only satisfaction is measured, so the team cannot tell whether the task was completed.
- Findings are reported and never triaged, so the same defect returns next release.
What happens next
At FDIS, check whether the measures are named more precisely. If they are, map the published measures to the ones already in the test plan rather than starting again.
Source
ISO Online Browsing Platform, free preview of ISO/IEC/IEEE DIS 26517 https://www.iso.org/obp/ui#iso:std:iso-iec-ieee:26517:dis:ed-1:v1:en read 21 October 2026
ISO/IEC/IEEE DIS 26517, standard record 87297 https://www.iso.org/standard/87297.html read 21 October 2026
W3C Web Content Accessibility Guidelines 2.2 https://www.w3.org/WAI/standards-guidelines/wcag/ read 21 October 2026