IndependentNot a client engagement. This study was not commissioned by, affiliated with or endorsed by GOV.UK Frontend or the other organisations discussed. Findings, local experiments and proposed work are identified separately.
Evidence at a glanceWhat we can substantiate.
Focused checks14 / 14Behavioural assertions on the local integration. This is a test count, not an accessibility score. [1]
Viewport widths4No horizontal overflow at 320, 390, 768 and 1440 CSS pixels in the fixture. [1]
Keyboard correction paths2Summary links reached the email field and the missing-year field using Enter. [1]
Negative control1An intentionally broken target was detected, showing that the test can catch a failed correction path. [1]
Source review + local integration test · Studied 12 October 2026 · By SystemVale
The questionAn error message is only useful if the person can understand it, reach the field and continue without repeating work.
1Where does keyboard focus go after an invalid submission?
2Do the summary and the field describe the same correction?
3What still works when client-side JavaScript is unavailable?
Scope & methodA bounded question.
A repeatable method.
GOV.UK Frontend 5.13.0, with the matching tagged error-summary implementation. We built and tested a small local service-request fixture in Chrome 154.0.8037.98. This is a study of a public design-system component and its integration contract, not an audit of a live government service, a user study or a claim of accessibility certification.
Step 01Pin the public implementation
Capture the 5.13.0 package and the source file from its release tag, retaining hashes and its MIT license. This freezes the component behaviour under review; the study does not assume a later release behaves identically.
Step 02Build an actual recovery path
Create a local form that returns a server-rendered error response after submission. Preserve entered values, add a page-title error prefix and render matching summary and field errors. All values are labelled test fixtures; nothing is submitted to GOV.UK.
Step 03Exercise interaction, not just markup
Submit the form, confirm focus reaches the summary, then use keyboard activation to reach each invalid field. Check that description IDs resolve, error wording agrees and the user’s entered values survive the response.
Step 04Test the boundaries
Check four viewport widths and repeat submission with JavaScript disabled. Finally, point one summary link at a missing ID. Confirm that the field-focus check detects the broken path rather than treating any clickable link as success.
FindingsThe evidence,
and what it means.
01
Source-backed + testedThe component supplies focus, not the entire recovery journey
The pinned error-summary code takes focus unless that behaviour is disabled. It resolves the error link’s target and its label or legend before moving focus to the field. In our working fixture, keyboard activation reached both invalid inputs. [1][2]
Why it matters. A design-system component can carry useful behaviour, but the application must supply accurate targets, labels and a correctly rendered response.
02
Measured in the fixtureRetaining the draft is application work
The submitted name and invalid email remained in the server’s error response. The fixture also supplied the title prefix and matching error text. These checks passed because that behaviour was implemented in the form—not because importing the error-summary component adds it automatically. [1][3][4]
Why it matters. Acceptance criteria should cover the whole recovery path, including the server. A component screenshot cannot establish that entered work survives.
03
Measured in the fixtureNo JavaScript is a separate interaction path
With scripts disabled, the response still displayed both errors and retained the name. The summary’s email link kept its field anchor. We do not claim the component’s automatic focus behaviour exists in that mode; the useful fallback comes from the HTML response. [1]
Why it matters. Progressive enhancement means there is a meaningful basic path first, with JavaScript improving it.
04
Negative controlA deliberate defect tests the test itself
We changed one link target to an ID that does not exist. The check correctly detected that the email input did not receive focus. This was an intentional fixture defect, not a defect found in GOV.UK Frontend. [1]
Why it matters. A regression test should fail when the behaviour it protects is broken. Counting links or searching for an error message would have missed this problem.
In detailInspect the results.
Who is responsible for each recovery behaviour?| Behaviour | Observed result | Responsibility |
|---|
| Focus after invalid submission | Summary receives focus | GOV.UK component, after initialisation |
|---|
| Keyboard correction link | Email and year fields receive focus | Component + valid field IDs and labels |
|---|
| Page title identifies the error | Error prefix present | Application / fixture |
|---|
| Entered values survive | Name and invalid email retained | Application / fixture |
|---|
| No JavaScript | Errors, values and field anchors remain | Server-rendered HTML / fixture |
|---|
| Broken field target | Focus failure detected | Intentional negative control |
|---|
These are observed integration behaviours. We did not test screen-reader speech, completion rates or the quality of a real service’s validation rules. [1][2]
Run the integration experiment
Extract the evidence bundle, run npm install in that folder to install the pinned Playwright test dependency, and run node scripts/study-govuk-forms.cjs. The script uses an installed Chrome browser and opens a temporary server bound to 127.0.0.1. It never submits to a public site. The saved package is 5.13.0; package bytes, component source, screenshot and check results are included.
1. Invalid local POST → server-rendered error response
2. Initialise the pinned error-summary component
3. Assert summary focus and retained input
4. Activate each correction link with the keyboard
5. Repeat without JavaScript
6. Inject a missing target and verify the failure is detected
Recommendations · not deployedWhat we would do next.
These are SystemVale’s recommendations for a comparable product or service. They are not claims that the organisations studied implemented them.
01Specify the full correction journey
For a booking, application or customer portal, define the error response as a sequence: identify the problem, announce or focus the summary, reach the field, retain valid work and allow another attempt. Assign component and application responsibilities explicitly.
Use precise field-level language
Tell the person what is missing or which format is required. Keep the summary and inline wording aligned, preserve hints and avoid suggesting that a system outage is the user’s input mistake. Test the actual validation conditions separately.
Validate with people and assistive technology
Next, test representative tasks with users, including people who use screen readers, keyboard-only navigation or magnification. Add Safari and Firefox checks. The current browser assertions provide an engineering baseline, not evidence of successful task completion.
Measure recovery without collecting the input
A proposed production measurement plan would count invalid submissions, successful corrections and abandonment by field identifier. Do not send entered names, emails or free text to analytics. Set a baseline before claiming reduced friction.
SystemVale’s conclusionTreat error recovery as a complete interaction contract, with the component and application tested together.
Our interpretation of this study. Not a client quote or endorsement.
ApplicationWhat this brings to your work.
01Test where focus lands
A visually prominent error is not enough. Keyboard users need a predictable path back to the field.
02Protect completed work
Retaining input is a concrete requirement that can be verified across the server response.
03Separate checks from outcomes
Passing browser assertions supports implementation quality. User research is still needed to establish usability in context.
Explore UI/UX & Usability →
Limits & sourcesCheck the evidence.
What this study does not establish
- No live GOV.UK service was assessed or modified. The server validation and form content belong to SystemVale’s local fixture.
- Chrome only. Viewport-width checks are not equivalent to testing real mobile devices or on-screen keyboards.
- No screen-reader speech testing, participant research or full WCAG audit was performed.
- The 14 checks include four viewport checks and a negative control; they are not 14 independent usability improvements or a compliance score.
Reproduce the analysis
Download the five-study evidence bundle: captured public data, source hashes, scripts, licenses and original result files. The README explains the commands and the boundaries of each experiment.
- SystemVale: the 14 browser checks and their scope ↗
Executed 12 October 2026 in Chrome 154.0.8037.98.
- GOV.UK Frontend 5.13.0: error-summary implementation ↗
Pinned source reviewed alongside the matching npm package; SHA-256 in the evidence manifest.
- GOV.UK Design System: Error summary ↗
Primary guidance; reviewed 12 October 2026.
- GOV.UK Design System: Recover from validation errors ↗
Primary pattern guidance. Component reuse does not make an entire service accessible.