Budget Tool

Accessibility statement

This statement applies to the Budget Tool web application.

This file is the statement. The page at /accessibility renders it directly, so there is one copy to keep true rather than two to keep in step.

Budget Tool is built and run by Michael Shreeves as an individual rather than as a company. He is the operator, the developer and the person who answers accessibility reports.

I want as many people as possible to be able to use Budget Tool. That means you should be able to:

  • navigate the whole application using a keyboard alone
  • see clearly which control the keyboard is on
  • read every figure a chart shows, as text, without seeing the chart
  • zoom to 400%, or use a 320px-wide screen, without content being lost or needing to scroll sideways
  • read all text against its background at the contrast the standard requires

How accessible this service is

Budget Tool is partially compliant with the Web Content Accessibility Guidelines version 2.2 AA standard. It is partially rather than fully compliant because it has not yet been tested with a screen reader, and because of the specific items listed below.

Non-accessible content

Non-compliance with the regulations

  • The application has not been tested with a screen reader. Automated testing, keyboard testing and contrast measurement have all been done, and the markup follows the practices that screen readers depend on — real labels, real table headers, live regions for status messages, and text alternatives for every chart. But no listening pass with NVDA, JAWS or VoiceOver has happened, so I cannot claim conformance with the criteria that only a listening pass can confirm — principally 1.3.1 (Info and Relationships), 4.1.2 (Name, Role, Value) and 2.4.6 (Headings and Labels). I plan to complete an NVDA pass over the sign-in, budget, import and administration journeys by 31 October 2026, and to update this statement with what it finds.

  • When a form is submitted with errors, the errors are shown on each field but not summarised at the top of the form, and the keyboard is not moved to the first problem. Each individual error is correctly associated with its field (aria-invalid and aria-describedby), so a screen reader announces it when the field is reached — but somebody who submits a long form has to go looking for what went wrong rather than being told immediately. This is a shortfall against 3.3.1 (Error Identification) in spirit rather than in letter. I plan to add an error summary by 31 December 2026.

  • A few screens have not been tested at all. The two-factor authentication challenge, the email-verification screen, the Microsoft sign-in return page, the recovery-codes screen, and the column-mapping and review steps of the budget and actuals importers were not covered, because each needs a state that could not be reached during testing. They are built from the same layouts, form theme and components as the 61 pages that were tested, but that is an expectation, not a result. I plan to cover them by 31 December 2026.

Content outside the scope of the regulations

  • The application shows an error page produced by the Symfony framework when it is run in development mode. That page is not part of the service as deployed and is not seen by users.

Reporting an accessibility problem

If you find a problem that is not listed here, or you need something in a different format, email [email protected]. I aim to reply within five working days, and I will tell you what I can do and by when. One person reads that inbox, so a realistic answer is better than a fast one.

Which rules apply, and where to escalate

Budget Tool is run by a private individual, so the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 — which bind public sector bodies — do not apply to it, and I do not claim they do. What does apply is the Equality Act 2010 duty to make reasonable adjustments for disabled people, which applies to anyone providing a service. WCAG 2.2 AA is the standard I hold the application to regardless, because it is the right bar.

Where Budget Tool is supplied to a public sector or NHS organisation, that organisation's own duty under the 2018 regulations reaches this software through their procurement, and this statement is written to be usable as evidence for it.

If you are not happy with how I respond, the Equality Advisory and Support Service (EASS) gives free advice on accessibility and discrimination, including where a service has not made reasonable adjustments.

Technical information about this service's accessibility

I hold Budget Tool to WCAG 2.2 level AA.

What I did in the August 2026 pass

Every item below was a real defect, found by testing and fixed before this statement was published:

What was wrong Criterion
Status badges, muted text, links and semantic colours failed contrast — eight distinct colour pairs, the worst at 3.05:1 against a required 4.5:1. Bootstrap's default link blue had never been overridden and measured 4.2:1 on the page background 1.4.3 Contrast (Minimum)
The border of every text input and select measured 1.37:1 against the surface behind it, and that border is the only thing marking where the control is 1.4.11 Non-text Contrast
Drop-down filters and the current sidebar item had no visible focus indicator, because the framework's own focus ring was suppressed on one and invisible against the background on the other 2.4.7 Focus Visible
Wide tables scrolled sideways but could not be scrolled by keyboard, because the scrolling container could not be focused 2.1.1 Keyboard
The file upload on both importers had no label 1.3.1, 3.3.2, 4.1.2
The twelve monthly amount fields on the reforecast form had no accessible name — the month was in a neighbouring cell, which associates it for a sighted user and for nobody else 1.3.1, 3.3.2, 4.1.2
Six dashboard charts were drawn into a <canvas> with no text equivalent, so none of the figures were available to a screen reader or without JavaScript. Each now has a data table carrying the same numbers 1.1.1 Non-text Content
The dashboard and the privacy notice scrolled sideways at 320px 1.4.10 Reflow

I also fixed a fault that was not an accessibility defect but produced the worst possible error message: four forms returned a server error, rather than a validation message, when a drop-down was submitted empty.

How the service is built

  • Pages use semantic HTML — real headings, lists, tables with <th> and scope, and landmarks — before any ARIA is added.
  • A "skip to main content" link is the first thing the keyboard reaches.
  • Status and flash messages are announced through a live region that is already in the page, so a message that appears later is still read out.
  • Status is never carried by colour alone; every RAG indicator also carries the word.
  • Charts are marked as decorative and the same figures are provided as a table.
  • Motion respects the operating system's "reduce motion" setting.

How I tested this service

Budget Tool was last tested on 1 September 2026, by me, against WCAG 2.2 level AA. It has not been audited by anyone independent.

What was tested, and how:

  • Automated testing with axe-core 4.10.2, against the WCAG 2.0, 2.1 and 2.2 A and AA rule sets. The September 2026 pass covered 52 page states in one run — every page an organisation administrator can reach, the detail and edit screens behind them, the notice pages, the support form and all four error pages. Earlier passes additionally covered the platform administrator console, registration, sign-in, password recovery, the invitation acceptance page and the password-reset form reached from an emailed link. Every page tested returns zero violations.
  • Reflow at a 320 CSS pixel viewport width across 30 pages, which is the condition WCAG 1.4.10 describes and is equivalent to 400% zoom on a 1280px screen. No page requires horizontal scrolling.
  • Keyboard testing of the dashboard: every focusable element was checked for a visible focus indicator, tab order was confirmed to follow reading order with no positive tabindex anywhere, and the help panel was confirmed to move focus into itself, close on Escape, and return focus to the control that opened it.
  • Contrast measurement by calculating the ratio for every colour in the design system against every background it is actually used on, rather than sampling.
  • Form error handling by submitting an invalid form and confirming each error is associated with its field programmatically.

What was not tested:

  • No screen reader was used. This is the most significant gap and the reason the statement claims partial rather than full compliance.
  • No testing with disabled users, or with speech-recognition or switch-access software.
  • Browser zoom at 200% and text-only zoom were not tested separately from the 320px reflow check.
  • No review of reading level or plain language.
  • The pages listed under "Non-accessible content" above were not reached.

Automated tools find roughly a third of accessibility problems. A clean automated result is necessary, and it is not sufficient — which is why it is reported here alongside what it cannot tell us.

Preparation of this statement

This statement was prepared on 31 August 2026. It was last reviewed on 1 September 2026. The service was last tested on 1 September 2026.

It will be reviewed at least once a year, and whenever the application changes in a way that affects any of the above.