GOV.UK case study: creating a new component
Government Digital Services (GDS) has a library of accessible components, designed to help you build a service everyone can use. But what happens if none of those components meet your users' needs? You build one yourself.
The service
This case study comes from the digital transformation project I worked on for a subsection of HMRC. We were creating online journeys to replace 10 paper forms which collect lots of complicated information about certain business types across England and Wales.
The challenge
For most sections of the form, we could use existing components from the GDS library. However, we encountered problems when we reached the 'trading history' section of the forms. This requires users to enter detailed trading figures for the preceding 3 financial years.
Some of the 10 forms ask for multiple pages of financial information which are presented as tables in the paper versions. However, GDS guidelines advise against asking users to input figures into large tables.
The client only needs to collect completed sets of annual financial information. That meant we had to devise a way of only asking users for information from relevant years - this was especially important for users who had first started operating with the previous 3 years.
We had to consider users who may have changed their financial year end during the timescale in question. And, of course, any solution we devised had to be accessible.
The solution
Initially, we were reluctant to create a table to collect financial information for 3 financial years. We devised a couple of methods to ask for the figures one financial year at a team. And we toyed with the idea of using an add-to-list mechanism, but it became very unwieldy very quickly.
Our first users did not react favourably to our first efforts, so we decided to introduce a table covering all 3 years. This solution was a unanimous success – every user preferred this display. Armed with this user preference, we pressed ahead with creating a new component.
But although we knew which component the users wanted, making it was not without its issues.
Our first iteration dealt with the problem of users changing their financial year end during the last 3 years by allowing the users to change the dates in the column headers. However, this meant we could not use aria labels in the input fields to tell screen-reader users in which field their cursor was sitting.
To solve this problem, we introduced a checkbox allowing users to indicate if their financial year end had changed. If that was the case, they'd be taken on a sub-journey to indicate when it had changed, and what it was previously. This allowed us to display accurate column headers when the system showed the blank columns.
Having static column headers allowed the developers to create dynamic aria labels, based on the dates in the column headers.
For example, if the row was entitled 'drinks', and the column was for 'financial year ending 4 May 2025', a screen reader would say 'drinks for year ending 4 May 2025'.
The results
Once the dynamic labels were working, we set up some user testing with screen reader users. Each person could navigate through the trading history section with ease. Some people didn't expect the tab key to take them down each column, rather than across each row, but they understood why the page was set up that way.
The HMRC accessibility team gave the component their seal of approval, and the forms are ready for their accessibility audit, prior the service's public beta assessment.