What we test, and what we have not fixed yet.

The standard we build to

Serproz targets conformance with the Web Content Accessibility Guidelines 2.2 at level AA across the public marketplace and the signed-in dashboards.

• This is a target, not a certification: Serproz has not been independently audited against WCAG 2.2 AA and does not claim certified conformance. The target is what design and engineering decisions are measured against, and what a reported barrier will be assessed by.

• Minimum supported width: 360 CSS pixels. Every layout is required to work at that width without sideways scrolling, which is the width that matters most for small and zoomed screens.

• Text and contrast: Body copy is set at a size and contrast intended to satisfy the AA contrast ratios, and layouts are built to survive text resizing and zoom rather than clipping content.

• Motion: No page is permitted to run a persistent, never-ending animation. Moving decoration that cannot be stopped is treated as a defect, not a design choice.

What is actually tested, on every change

An automated suite drives a real browser over the critical surfaces and fails the run on any of the following. This is not a checklist someone signs; it is a gate a change has to pass.

• Automated rule checking: The axe accessibility engine is injected into each surface and run over the whole document. The suite requires an empty violation list — not a reduced count, an empty one.

• Two viewports: Each surface is checked at 360 by 800 pixels and again at 1440 by 900, so a fix at desktop width cannot quietly break the phone layout.

• Reduced motion: The browser context requests reduced motion, so the surfaces are exercised the way a visitor with that preference set will receive them.

• One main landmark, one page heading: Every surface must expose exactly one main landmark and exactly one level-one heading. Duplicated landmarks are a real navigation hazard for screen-reader users and are treated as failures.

• No horizontal overflow: The document width is compared against the viewport width and must not exceed it. This is what enforces the 360 pixel minimum in practice.

• No persistent animation: The suite enumerates running animations and fails if any is set to repeat indefinitely.

• Skip link and focusable main: The public layouts are separately asserted to render a skip link that targets a main landmark which can actually receive focus, so the link does something when it is used.

• Clean console and network: A surface that logs a browser error or fails a request also fails the run. A broken script is an accessibility problem before it is anything else.

The suite covers the critical public surfaces and the signed-in customer and provider shells, in both signed-out and signed-in states. It does not yet cover every page on the site.

Known limitations

This section is deliberately specific. A statement that only lists what works is not an accessibility statement.

• Automated testing finds only some failures: Rule-based tooling reliably catches a minority of WCAG failures. It cannot judge whether alternative text is meaningful, whether a heading structure makes sense, whether an error message is understandable, or whether a flow can be completed by keyboard alone.

• No published manual audit: A full manual audit against WCAG 2.2 AA, with a written report, has not been carried out and published. When one is, its date and outcome will be recorded in this section.

• No assistive-technology test matrix: There is no published matrix of screen readers, magnifiers and voice-control tools that each release is tested against. Until there is, do not read the automated pass above as evidence that a specific tool works end to end.

• Customer-supplied content: Photographs uploaded by providers and customers, and text written into profiles, reviews and job descriptions, are not authored by Serproz. Alternative text and reading order in that content cannot be guaranteed at the same standard as the interface around it.

• Third-party components: The card entry field is rendered by the payment provider, and live call surfaces use a third-party media client. Their accessibility is largely determined by those providers rather than by Serproz.

• Content drawn from Google Maps: Ratings, reviews and photos returned by Google are presented as supplied and are not rewritten by Serproz, so their wording and their alternative text are outside Serproz's control.

• Documents and downloads: Files uploaded to a job are stored and served as supplied. Serproz does not remediate a PDF or an image for accessibility.

• Older archived pages: Surfaces outside the automated suite may not yet meet the target. Reporting one is the fastest way to get it prioritised.

Reporting a barrier

A specific report is worth more than a general one, and it will be treated as a defect rather than as feedback.

• What to include: The page address, what you were trying to do, what happened instead, and the browser, device and any assistive technology you were using. A screenshot or a short description of where you got stuck is enough.

• What happens next: The report is assessed against WCAG 2.2 AA. If it is a failure it is logged as a defect and fixed; if it is not a failure but is still a genuine barrier, it is logged as a usability defect. Either way you get an answer about which it was.

• If you are stuck mid-job: Say so in the report. A barrier that is blocking a live booking, payment or dispute is handled ahead of a general report, and Serproz can act on the job while the underlying fix is made.

Send the report through the support page. A published email address for accessibility reports is not available yet; the support form is the monitored channel, and it does not require you to create an account.

What Serproz does not commit to

An accessibility statement with commitments it cannot keep is worse than one without them.

• There is no published response-time commitment for an accessibility report yet. Reports are triaged with other defects, and a barrier blocking a live job is prioritised.

• There is no formal conformance report, no accessibility conformance report document, and no third-party certification. None is claimed.

• No date has been fixed for a full manual audit. When one is scheduled, this section will say when.

If a barrier is reported and not addressed, escalate it through the complaints page. Accessibility is treated as a complaint about Serproz itself, not as a job dispute.

Changes to this statement

This statement carries a version string and a date so you can see when it was last reviewed. The current version is accessibility-statement-2026-09-06-v1. It is updated when the testing described above changes, when a limitation is closed, or when a new one is identified.