Accessibility Isn’t a Screenshot: The Mobile Evidence Pack UK Buyers Want in 2026

UK procurement teams have changed their questions. A few years ago, accessibility was often a line in a tender questionnaire and a promise to review before launch. In 2026, buyers — especially public sector teams, NHS suppliers and larger enterprise procurement functions — want evidence they can file, date and challenge. That is not unreasonable. The Equality Act 2010 has been around for a long time, and the Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 made the direction of travel clear. WCAG 2.2 AA is now the working benchmark for many UK tenders, even where it is not named explicitly.

The trap is treating the evidence pack as a last-minute PDF. It should be a by-product of how the app is designed, built and released. Here is a practical way to assemble one without turning the final fortnight into an audit scramble.

Start with a claim you can defend

Do not open with full conformance unless you can prove it across the whole product. A credible pack states the scope plainly: platforms, supported OS versions, key user journeys, and any areas excluded. It should name the standard — usually WCAG 2.2 AA, often read alongside EN 301 549 — and explain how the app was tested.

A short, honest statement beats a sweeping one. Buyers can work with known limitations and dated remediation plans. They get nervous when every box is ticked and there is no test trail behind it.

What goes into the pack

A useful accessibility evidence pack for a UK tender or renewal usually contains eight things.

1. An accessibility statement. What the app does, how to use accessibility features, known limitations, a contact route and a review date. Public sector teams may have specific expectations here, but private buyers increasingly ask for the same clarity.
2. A conformance report. A VPAT or equivalent Accessibility Conformance Report, dated and versioned. It should map criteria to results and point to evidence, not just list pass or fail.
3. Test scope and device matrix. Which iPhones and Android devices were used, which OS versions, which screen sizes, and which assistive technologies. At minimum, cover VoiceOver, TalkBack, Switch Access, Voice Control and large text or magnification.
4. Manual test evidence. Scripts, results, screen recordings and issue IDs. Automated scans are useful for catching contrast and missing labels, but they will not tell you whether a checkout flow makes sense with a screen reader.
5. A defect log and remediation plan. Severity, owner, target release and any temporary workaround. Buyers would rather see a managed defect than a vague promise to look into it.
6. Design and content evidence. Contrast tokens, minimum target sizes, focus-order rules, alt-text guidance and plain-English content standards. This shows the pack is not a one-off test.
7. Release-gate evidence. Where accessibility checks sit in the delivery process, who signs them off, and what happens when a regression is found.
8. A procurement Q&A sheet. Short answers to the questions buyers actually ask: who tested it, when, with what, what failed, what changed, and who owns accessibility day to day.

The WCAG 2.2 mobile failures that still trip teams

WCAG 2.2 added and clarified criteria that matter directly to mobile apps. These are the ones we still see causing trouble in UK audits.

Target size. The minimum 24 by 24 CSS-pixel target sounds small until you try it on a packed toolbar. Close buttons, icon-only actions and map pins are common offenders. Spacing matters as much as size.

Dragging movements. Sliders, swipe-to-delete and map interactions often have no single-pointer alternative. If a user cannot drag, they need buttons or another straightforward route.

Focus not obscured. Sticky headers, cookie banners and chat widgets can cover the item that currently has focus. This is easy to miss on a phone and painful for keyboard and switch users.

Consistent help. Help and contact routes jump around between screens. A consistent help mechanism is not glamorous, but it is exactly the sort of thing procurement teams check.

Redundant entry. Asking for the same address, reference number or payment detail twice in one journey. Mobile forms are fiddly enough without repeated data entry.

Accessible authentication. Time-limited codes, puzzle-style checks and blocked paste functions create barriers. Password managers and one-time codes need to work without a cognitive test.

Orientation and reflow. Locking an app to landscape, or breaking when text is enlarged, still appears in reviews. So do custom gestures with no alternative and unlabelled icon buttons.

Documenting conformance for tenders

Make the evidence easy to audit. Use a simple matrix: criterion, result, evidence link, owner and date. Keep the pack versioned alongside the release. If the app changes materially, the report should change too.

Be precise about partial conformance. Say what does not meet the standard, who is affected, what the workaround is and when it will be fixed. A dated remediation plan is stronger than a claim that everything is fine.

Buyers also appreciate a named contact and a process. Who receives accessibility feedback? How is it triaged? What is the service-level expectation? These answers show accessibility is operational, not a tender decoration.

Stop retrofitting: build the paper trail as you go

The teams that breeze through accessibility questions are not doing more paperwork at the end. They are putting accessibility into the work itself. Acceptance criteria reference WCAG 2.2. Design tokens enforce contrast and target sizes. Automated checks run in the pipeline, and a manual pass happens each sprint or release. An external audit before a major tender or renewal gives you fresh evidence and a punch list.

That approach produces a better app and a calmer procurement conversation. The evidence pack stops being a last-minute screenshot and becomes a record of decisions you can stand behind.