In a previous blog post, we shared our ambition for every form on GOV.UK to be accessible, easy to use and quick to process.
To support government to collectively work towards that vision, our team initially compared some of the different forms technologies currently in use. While not a fix-all for every form or every team, online HTML forms emerged as more accessible, easier to use and quicker to process, compared to document-based forms. We hope more government teams using online HTML forms will make it easier for people to use niche, but important government services.
How we compared different forms technologies
We’ve looked at some of the main technologies used in different forms to collect information from members of the public and businesses. On GOV.UK, most services use document-based forms, such as PDFs, Word documents or OpenDocuments. Higher volume services also use online HTML forms.
We did not evaluate forms sent in by post. The volumes of posted forms equate roughly with the 10% of the UK adult population who don’t use the internet. This suggests there is a need to support posted forms rather than replace them entirely, so we didn’t think it was fair to compare posted forms with internet-based technologies, as this group would be unlikely to use them.
While there were some differences between file formats and how technologies are used, we initially only compared two groups: document-based forms sent over email and online HTML forms.
We wanted to see how these two technologies could help us achieve government’s collective vision of every form on GOV.UK being accessible, easy to use and quick to process. Let’s see how they fared against those three criteria.
Accessibility
The Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 use the WCAG 2.1 AA standard. While meeting the standard is just a starting point for improving accessibility, it’s a useful bar for assessing different technologies.
Document-based forms can currently only meet the WCAG 2.0 AA standard, not WCAG 2.1 AA. For example, documents designed to be edited don’t reflow when zoomed in, instead users have to scroll horizontally and vertically which makes things much harder for some users.
Even creating document-based forms that meet the lower WCAG 2.0 AA standard requires specialist accessibility skills. While we haven’t conducted a comprehensive audit, we have found very few examples of document-based forms on GOV.UK that meet the WCAG 2.0 AA standard.
Online HTML forms can meet the higher WCAG 2.1 AA standard, but creating them usually requires a digital team with specialist digital skills. There are many examples of these types of forms on GOV.UK. While there are platforms that use templates to make it easier to create online HTML forms that meet the standard without specialist skills, they are relatively expensive, require a lot of training or lack necessary features.
We conclude that online HTML forms are better than document-based forms for meeting the WCAG 2.1 AA standard, but at the moment it can be too difficult or expensive to create them.
Ease of use
Unlike accessibility, measuring ease of use is less standardised. We considered the main factors that would affect someone’s ability to successfully complete a form.
Document-based forms have a few benefits that online HTML forms don’t always have. For example, they can be filled out in whatever order the user prefers and are easily filled out by more than one person. However, they can be difficult to use on all device types, particularly on mobile devices, which make up the majority of users on GOV.UK. We heard from many services that people struggle to fill them in using specialist PDF editors or word processors. Many users resort to printing forms out, filling them in with pen, then scanning or taking photos to attach to an email. For people that don’t have access to a printer, this isn’t an option. Some users just give up.
With the right platform and templates, we think most of the benefits of document-based forms can be mirrored in online HTML forms. In addition, online HTML forms are much easier to use on all device types, particularly on mobile devices. Being able to fill in a form in a web browser without downloading and editing a form means people can more easily access government services on their phone on the bus home.
Processing time
The time it takes a civil servant to process a form affects how long members of the public and businesses have to wait to get what they need from government.
Drawing on our team’s own experiences of working on different government services, we estimated the time it could take to process document-based forms received over email compared to online HTML forms. We estimated timings based on the steps involved in processing information collected using forms and used them to help our team prioritise areas to explore. Actual processing times will vary from team to team, and we did not ask other government service teams to verify our estimates at this stage.
The first scenario, ‘emailed document-based forms’, assumes the information is sent to the processing team in a document-based form attached to an email, with supporting evidence in other attachments. It assumes the document-based forms are a mix of scans, photographs and digitally-edited documents, with around half the information unable to be copied and pasted.
The second scenario, ‘online HTML forms’, assumes the information is sent by an online forms platform to the processing team in the body of an email, with supporting evidence in attachments.
| Task | Estimated minutes with emailed document-based forms | Estimated minutes with online HTML forms |
| Opening and queuing | 1 | 1 |
| Scanning, electronic documents record management, posting back originals | 1 | 0 |
| Validating information | 6 | 3 |
| Re-keying, record creation | 6 | 3 |
| Quality assurance on 10% | 0.5 | 0.5 |
| Phone calls | 1 | 0.25 |
| Total time | 15.5 | 7.75 |
| Estimated costs of an administrative officer and overheads | £4.22 | £2.11 |
Our initial estimates show that online HTML forms could be twice as fast to process compared to document-based forms sent over email. Most of the potential time savings come from using validation to check all of the form information is there before someone submits it. Form validation could significantly reduce the amount of time civil servants spend contacting people who didn’t submit the right information.
The rest of the potential savings come from collecting the information in ways that are easier to process, such as faster copying and pasting. In the long term, we hope to be able to make this even more efficient by feeding information directly into case management systems.
Other considerations
Having done an initial evaluation of accessibility, ease of use and processing times, it seems like there are big benefits of using online HTML forms, especially when there are currently thousands of forms only available as documents. However, we’re also considering some other factors, not least matters of digital inclusion for example, ensuring document-based forms remain available for people that don’t use the internet.
In addition, we estimate that between 20 and 35% of document-based forms on GOV.UK have complex and less common question or answer formats. These formats probably wouldn’t be available in a typical form-building platform, and there might be some that are too complex to use without a digital team. Others might be so specific to one particular service that it would not make sense to have in a common platform.
Teams could recreate these features in online HTML forms using a developer to write some bespoke code. However, if they’re a lower volume service and don’t have a developer, they might not be able to use online HTML forms. As a result, we think for some lower volume services, the best way to improve forms may still be to get help from specialists to make document-based forms more accessible.
Help us test easier ways for civil servants to start using online HTML forms
To bring these benefits to members of the public and businesses, we want to make it as easy as possible for more government teams to start using online HTML forms alongside document-based forms.
To help us achieve this, we’re now looking for civil servants to be the first to test out a new form-building platform we’re developing. At the moment, we’re looking for civil servants outside the digital, data and technology profession that currently create or edit document-based forms.
27 comments
Comment by James McInally posted on
This seems like a no-brainer regarding HTML forms. Did research really need to be done in to this to determine what format was better? I suppose in order to determine what is more accessible from an empirical point of view it had to be done. We chnaged all our forms on https://www.xlweb.co.uk to both document and HTML in order to capture everyone but then reversed it as no-one completed the documents. Interesting research this, it backs up what I thought.
Comment by Harry Vos posted on
Hi James,
Thanks for sharing your work! At GDS, we’ve used HTML forms for quite a while, so we had an idea of some of the benefits. That said, lots of government services still solely use document-based forms. This fairly quick bit of research aimed to check if we were missing something because of how widely government uses document-based forms. Understanding where document-based forms are useful and less useful has made it easier to persuade teams to start using HTML forms.
Thanks,
Harry Vos
Comment by Neil Bookless posted on
How do you cater for [older] people that are less Tech savvy or those without internet access? If everything is on-line there is a risk of a 2-tier system.
Comment by The GDS Team posted on
Hi Neil,
Thanks very much for your comment, it’s a great point and one we take incredibly seriously. We have to make sure government services are available to everybody and government teams provide non-digital routes where some of our users may need these.
The latest ONS data about internet access amongst adults show this has increased slightly to 95%. However, 15% of adults do not use email, which suggests there is a significant proportion of the population for whom both digital and downloadable document-based forms are not appropriate.
Government is many different organisations, all with different approaches, and we try our best to offer alternatives such as posting documents, telephone and in-person support where needed.
Thanks,
The GDS Team
Comment by Selina J. Morales posted on
They are better for a variety of reasons. For example, information is easier to fill out and there is a higher rate of actually submitting it to the company or federal agency.
Comment by Joe posted on
Also, now I think more on it, I'm curious about this "specialist knowledge" required to create an HTML form. I would argue it's not more specialist than creating a PDF form (w/ digital input), or using MS Word and adding the accessibility tests, and possibly even easier.
Having created many HTML4 and 5 forms up to 20 years ago, the "specialist knowledge" is usually because orgs were sold on non-WCAG complaint frameworks. If you start with HTML and keep the divs to a minimum, it's a hellova lot easier than getting a branded CMS or framework that requires experts to massage it back into #a11y.
Comment by Harry Vos posted on
Hi Joe,
Thanks for your feedback. I’m glad the post was useful.
You’re right to point out we also need to consider storage, sustainability and timeliness. Our colleagues in the Central Digital and Data Office found that because HTML usually takes less time to load, it’s generally more sustainable than PDFs. While printing, posting and storing forms is probably less sustainable, we also have to consider how we support people to access government services when they don’t use the internet.
Thanks for sharing your experiences of working across both document-based and HTML forms and yes specialist skills are essential for creating accessible forms in whichever format. We’ll certainly consider the risks of frameworks that don’t produce accessible HTML.
Thanks,
Harry Vos
Comment by Joe posted on
Great to read this article so thanks to all the researchers/writers. I've read many articles on accessibility of word/PDF/HTML forms but what I like about this is it looks at the entire service. From creating and publishing, through filling and submitting, to processing and completing. A few more issues to add to your next study could include storage, sustainability and timliness.
For example, a PDF/DOC that requires a wet signature, needs to be printed, scanned and disposed of. not very sustainable. It also requires more storage space. not an issue for one doc but several million multipage docs a year is not great.
Also, aside from "specialist knowledge", an HTML form can be modified and republished pretty quickly.
Comment by John Beale posted on
This is good stuff. I'm working on a project to convert non-accessible forms using our in-house solution that lets us build accessible forms following GDS standards. I'll use this article as evidence that it's the right thing to do 🙂
We're having some early successes - when we demo rough prototypes stakeholders can see that not only are HTML forms simpler for the user, they can prevent known errors that result in them regularly rejecting applications, or needing more info. They also ask themselves if they really need all the data they ask for, and sometimes conclude that they don't, which is great.
There's one major blocker at the moment though - wet signatures. We are finding it difficult to persuade form owners they don't need them. Did you look at this issue at all? (We have some forms that must be completed online, then printed out for a signature to be added, then posted - or scanned as an attachment to another online form to submit!)
Comment by Iain Boyd posted on
Hi John,
Thanks for getting in touch and great to hear you are working on a solution to move away from inaccessible document-based forms to accessible HTML ones. Agree on all the benefits you mention both to users and to teams processing data for eg. applications to government services.
We are looking at wet signatures and whilst a lot of forms we have audited ask for signatures, in the same way you mention teams are evaluating what data to collect, we think many of these instances could be equally satisfied with a declaration. Yes there will be a need for greater identity verification also. We have some early ideas but nothing to report…yet!
We’d love to hear more about your work, please get in touch with us if you’re interested, thanks.
Thanks,
Iain Boyd
Comment by John oshea posted on
So i need to verify my identtity
Comment by Steve Green posted on
I don't think these results will come as a surprise to anyone because HTML forms have many advantages over documents. It would have been more interesting to do a comparison between forms in PDF, Word and ODT format.
In mandating the use of ODT, GDS are going against the opinion of just about everyone in the accessibility community, which is that PDF forms are much more accessible than Word and ODT, assuming they are designed properly. Word and ODT forms have some serious shortcomings with regard to assistive technologies.
Comment by Iain Boyd posted on
Hi Steve,
Thanks for your comments and whilst, yes, it would be interesting to compare these formats, we’re focusing on understanding the processes in creating and publishing a form as well as the tools used.
Yes, there is some work to do to make these formats more accessible and you’re right that PDFs can be done well. But it’s hard to do and still doesn’t meet the required WCAG 2.1 AA standard. Hence our focus on HTML forms in conjunction with document-based forms. We’re working with other departments on this and our hope is that, one day, accessible PDF, Open Document and HTML forms will be available.
For now, our publishing guidelines state that service teams should publish document-based forms in at least 2 formats to provide users with alternative options. The reason we ask for Open Document formats is that it’s non-proprietary and free, and therefore does not require the use of paid-for, licensed software. Government services are for everyone, not just those who can afford them!
Thanks,
Iain
Comment by Steve Green posted on
Hi Iain,
We create fully WCAG 2.1 AA conformant PDFs, including forms, every day. Why are you of the opinion that it is not possible to do so?
Comment by Harry Vos posted on
Hi Steve,
If you’re happy to share, we’d like to learn how you make reflow work on editable PDFs with interactive form components?
You can email our team.
Thanks,
Harry Vos
Comment by Steve Green posted on
I expected you to bring up the issue of reflow. The WCAG "understanding" page states "In a PDF created to conform to PDF/Universal Accessibility (ISO 14289), the content can be reflowed and zoomed in to make reading possible for someone with low-vision."
Also, under the Sufficient Techniques heading, it says "@@ New: Using PDF/UA when creating PDFs."
https://www.w3.org/WAI/WCAG21/Understanding/reflow.html
The fact that Adobe Reader does not reflow pages that contain interactive elements is a shortcoming of Adobe Reader, not a WCAG non-conformance.
Comment by Harry Vos posted on
Hi Steve,
Thanks very much for sharing that. Would you mind sharing which software you use to get reflow working for a PDF form? We haven’t come across any, which is why at the moment, we can’t confidently say a PDF form meets WCAG 2.1 AA. Though I recognise this depends on reader software, and is something that will hopefully improve over time.
Thanks,
Harry Vos
Comment by Jonathan posted on
You say "but creating them usually requires a digital team with specialist digital skills", but you don't say why... what's the problem? Lining up labels with inputs? Organising multi-page forms?
Comment by Iain Boyd posted on
Hi Jonathan,
Thanks and yes, creating HTML forms which are WCAG 2.1 AA-compliant does require specialist digital skills, for example appropriately tagging components. This ensures that assistive technology can access all the information. Digital specialists are usually too expensive for many government teams. It’s much easier to create a document, turn this into a PDF and publish this, which unfortunately creates more forms which don’t meet accessibility standards. This is what we would like to fix.
Thanks,
Iain
Comment by Jonathan posted on
Iain
So this is one of those situations where building a website directly in HTML is counter-productive. Maybe it would be useful for GDS to create a form builder which will automatically link labels and inputs. Given that forms are literally *the way people interact with gov, I'm surprised this hasn't been solved. Though it does explain why some of the forms (covid locator, for example) aren't as good as they could be.
Comment by Harry Vos posted on
Hi Jonathan,
Great point. We agree! We’re working on it. If you’re curious, you can read our blog post and listen to our podcast.
Thanks,
Harry Vos
Comment by Phil Match posted on
Did you evaluate any commercially available products that build accessible forms? Not just PDF or document templates.
Comment by Iain Boyd posted on
Hi Phil,
Yes we have looked at a number of commercially available off-the-shelf products. We wouldn’t be able to list them here and there are lots of good products out there, but none that were both commercially viable and that meet WCAG 2.1 AA standards. Ultimately, we want to provide a solution that's accessible for all users and not prohibitively expensive for small operations teams in government. Let us know if you know of more products please.
Thanks,
Iain
Comment by R K Hayden posted on
I'm a bit puzzled by your comment that one of the benefits of document based forms over HTML ones is that "they can be filled out in whatever order the user prefers". Surely that's just an artefact of how you're designing your HTML forms? If an HTML form can only be filled in in a particular order, then that's a design decision that someone has made when structuring the form. Allowing a user to fill in a form in (almost) any order can make form navigation slightly more complex, but it can be done.
And once accounts on GOV.UK are up and running HTML forms "filled out by more than one person" should be possible too.
Comment by Iain Boyd posted on
Hi Robin,
Thanks for your comments. We try to structure digital forms in ways that help users to complete the form in the most simple way. For example, we use one question per page to help users answer questions and to navigate to the most relevant next question. Document-based formats often will have ‘skip to’ logic which helps users to navigate in a similar way.
An advantage that document-based forms have over online forms is that a user can see the whole document at a glance. They may then choose which sections to complete; for example, if they only have certain information to hand and can return at a later stage, say when they have found a document they need to refer to. We will be looking at a ‘save and return’ option to make this feature possible. In the future, we may explore how to enable multiple users to contribute to forms, which GOV.UK accounts may be able to help with.
In the future, we'll also be looking into how to help users navigate between different sections of more complex forms.
Thanks,
Iain
Comment by Les Morris posted on
Agree with all the above. BUT….. the department’s need to practice what you preach, my recent experience of using DWP Online forms for pension shows you have a long way to go with this approach.
Comment by Iain Boyd posted on
Hi Les,
Thanks for your comments and sorry to hear you have had problems when applying for a pension through the online service. If you are still having trouble applying, you can call the Pensions Service claim line on 0800 731 7898. If you have hearing or speech difficulties, please use the textphone service on 0800 731 7339.
We really appreciate feedback that can help teams to improve services. If you would like to provide feedback on the Get your state pension service, please use the ‘Is this page useful’ feedback link at the bottom of the page.
Finally, our work on making all forms on GOV.UK accessible is in partnership with other departments and whilst there are over 5,000 document-based forms and a lot of work to do, we also have a lot of support to resolve this and make these better for users.
Thanks,
Iain