The Message and the Map: Auditing Error Summaries on Council Tax Forms

Council tax is one of the few local authority transactions that almost every household encounters, and the online forms that support it are correspondingly consequential. A mistake in a name, a forwarding address, or an account number can delay a bill, a discount, or a summons. When the form fails, the error summary is often the first thing a resident meets after pressing submit. It should therefore be treated as a designed interface in its own right, not as a by-product of validation.

The Web Content Accessibility Guidelines set a floor. Success criterion 3.3.1, Error Identification, requires that items in error are identified and described to the user in text. Success criterion 3.3.3, Error Suggestion, asks for suggestions for correction where known. A summary that says only 'There is a problem' satisfies neither criterion in any useful sense. It identifies a state, not an item; it describes a mood, not a mistake.

Why the summary is more than a courtesy

An error summary performs two jobs at once. It gives a short account of what went wrong, and it provides a route back to each affected field. For a keyboard user, that route is a sequence of links. For a screen reader user, it is a set of announcements that must make sense without visual context. For a resident using magnification or a small phone, it is a block of text that must not push the form beyond reach.

The pattern is familiar from the GOV.UK Design System: a summary appears above the form after submission, receives focus, lists each error as a link, and is paired with an inline message at the field. Familiarity is not the same as compliance. A council can copy the appearance of the pattern while missing the behaviour that makes it work. The audit therefore needs to test the summary as a navigational aid, not merely as a warning banner.

Four questions for every summary

The first question is reachability. After a failed submission, where does focus land? If the page reloads and focus returns to the top of the document, a screen reader user may hear the header and navigation again before reaching the summary. If focus moves to the summary heading, the user hears the problem immediately. The summary should also be reachable by keyboard in a predictable order, and it should not be hidden inside a collapsed accordion or a modal that opens without focus management.

The second question is specificity. 'Please correct the errors below' is not an error message. A useful entry names the field and the problem: 'Enter your council tax account number'; 'Enter a valid postcode'; 'Select whether you are the sole occupier'. Specificity is not about length. It is about giving the resident enough information to know which part of the form needs attention.

The third question is linkage. Each item in the summary should be a link to the corresponding field, and the link text should make sense on its own. 'Here' and 'this field' are poor link texts, particularly when a screen reader user lists links out of context. The link should also move focus to the field, not merely scroll the page. If the field is inside a group, such as an address or a date, the destination should be the first relevant input or the group legend.

The fourth question is plain English. Council tax forms attract technical language: hereditament, liability, exemption, disregarding. Some of that vocabulary is unavoidable. Error messages are not the place to add more. A summary should say what the resident needs to do, in words they can act on. 'Invalid input' is a message for a database. 'Enter your account number using eight digits' is a message for a person.

A repeatable audit routine for 2026

A practical review can be completed in a few hours per form if it is scoped carefully. The following routine is designed for web teams, content designers, and accessibility testers working on council tax and benefits services.

1. Choose three journeys: a simple change of address, a discount or exemption application, and a payment arrangement. These cover different field types and different levels of consequence.

2. Trigger errors deliberately: leave required fields blank, enter an invalid date, use a malformed postcode, and submit without selecting a radio option. Record the exact messages that appear.

3. Test with the keyboard only. After submission, note where focus lands. Tab through the summary and activate each link. Confirm that focus moves to the affected field and that the field-level message is announced or visible.

4. Test with a screen reader. Listen to the summary as a whole, then navigate by links and by form fields. Check that the summary heading is announced, that each link has a meaningful name, and that the inline error is associated with the input.

5. Check the visual presentation. The summary should be close to the top of the main content, use a heading that describes it, and not rely on colour alone. Inline errors should be positioned near the field and connected to it visually as well as programmatically.

6. Read the messages aloud. If a message cannot be understood without seeing the form, rewrite it. If a message suggests a correction, make sure the suggestion is accurate for the field type.

7. Record the evidence. Screenshots are useful, but notes on focus behaviour and screen reader output are more valuable. A short video of a keyboard journey can be enough to convince a product owner that the issue is real.

What good looks like

A well-built summary on a council tax form might read: 'There are two problems with your form.' It then lists: 'Enter your council tax account number. It is eight digits and can be found at the top of your bill.' and 'Enter a postcode in the format SW1A 1AA.' Each line is a link to the relevant field. At the field, the label remains visible, the error message repeats the instruction, and the input is marked as invalid programmatically. The resident does not have to guess, and they do not have to start again.

None of this is exotic. It is the ordinary work of joining content, design, and front-end behaviour. The difficulty is that error summaries are often assembled by validation libraries, legacy components, or a content management system that treats messages as strings rather than as part of a journey. That is why the audit has to be repeatable and why it has to happen after every significant change.

Making the checklist stick

The most useful outcome of an audit is not a list of defects but a change to the definition of done. Add error-summary behaviour to the acceptance criteria for any form component. Include focus management, link destinations, inline associations, and plain-English messages in the design review. Ask content designers to sign off the messages before development, and ask testers to run the keyboard and screen reader checks before release.

In 2026, councils are under pressure to digitise more transactions while maintaining trust in the services residents rely on. The error summary is a small interface with a large role. When it works, it turns a failure into a route forward. When it does not, it adds a second failure on top of the first. Auditing it properly is not a luxury; it is part of running a form that people can actually use.