You should test your services to ensure they can be used easily by people with a range of conditions and disabilities.
You will also need to check your service is compliant with the legal obligations which websites delivered by the government are subject to. Compliance with accessibility legislation is checked against WCAG (Web Content Accessibility Guidelines) requirements and techniques.
Understanding WCAG (GOV.UK Service Manual)
Some issues can be found using automated tools, as well as manual testing with a range of assistive technology, but others require someone to make an informed decision based on the intended purpose and context of the page.
You should not leave testing until the service is ready to build and facing an accessibility audit.
By considering and checking accessibility from the start and through prototyping, you reduce the potential for expensive accessibility debt building up.
Communicating with a broad range of users from the start will mean requirements and any issues with content, design and process can be captured early on when they can be more easily modified. It is essential that the users we engage with during the research carried out represent the general public and so this needs to include those with a range of conditions and disabilities.
Finding participants for user research (GOV.UK Service Manual)
Once your service is being coded for production then you should be carrying out accessibility testing as an ongoing task. You can also start testing internally with assistive technologies such as screen readers and speech recognition software.
Types of accessibility testing
How to test for accessibility
Before your HMRC service is made available to the public, you will need to have an accessibility audit to officially test your service and publish an accessibility statement. Most issues should have been picked up and fixed before the audit in the course of day-to-day testing during development.