26517ISO 26517 Revision CheckerDIS edition 1 · stage 40.60

Home / The record / Clause 8: Evaluating UA design and content

ISO/IEC/IEEE DIS 26517, Clause 8 · Headings only

8 Evaluating UA design and content

Clause 8 asks for testing goals, measures and mobile testing that reflect the device and the setting, not a desktop usability session relabelled as mobile.

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

What to put in place before publication

  1. Write the testing goals before the first session and tie each one to a decision the team can take.
  2. Choose measures that fit the help, such as task completion, time to answer, wrong turns, findability and confidence.
  3. Set a baseline on the current release so a later result can be compared with something.
  4. Test on real devices and real networks, including a small screen, a slow connection and an interrupted session.
  5. Include first time and expert users, and record which group each finding came from.
  6. Keep consent, recording and personal data handling in the test plan, and delete what you do not need.

Evidence to keep

EvidenceWhat it looks like
GoalsA test plan with goals written before the sessions
MeasuresA measures table with definitions and a baseline
DevicesA device and network matrix used for the sessions
FindingsA findings log with severity, audience and a decision
PrivacyConsent 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

The rules this is built from

Read from the real rules, not invented.

This page is read from the public record for clause 8: the heading in the free contents, and where public, the text the preview carries.

  • 80 headings and defined terms
  • 12 dated stages behind the draft
  • 26514:2022 named as the normative reference
  • Check any line yourself
Nothing here is guessed while you wait. Each answer is written from the public record and points to the exact page it came from. Record updated 21 October 2026