top of page

Insights

Writer's picturePiya Patel

Breaking barriers: digital inclusion in government services

Breaking barriers: digital inclusion in government services
Breaking barriers: digital inclusion in government services

In this article, Piya discusses the importance of creating government services that are accessible to everyone. Government accessibility standards exist to ensure that a wide range of people can use government services on both web and mobile applications. Importantly, accessibility is a shared responsibility, and Piya lists resources that offer guidance on integrating accessibility into the development of services.


Overview: 

  • GOV.UK requirements

  • Meeting WCAG 2.2

  • Testing with assistive technology

  • User research with disabled people

  • Accessibility statements 

  • GOV.UK design system

  • DWP resource


GOV.UK requirements

The government accessibility requirements state that all services must meet the following criteria to ensure that all legal requirements regarding public sector websites and mobile applications are met:


  • Meet level AA of the WCAG 2.2 (Web Content Accessibility Guidelines) at a minimum

  • Work on the most commonly used assistive technologies - including screen magnifiers, screen readers and speech recognition tools

  • Include disabled people in user research (including cognitive, motor, situational, visual and auditory impairments)

  • Have an accessibility statement that explains how accessible the service is (published when the service moves to public beta)


Reaching these requirements ensures that services meet the legal requirements as stated by Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018. In addition, we can ensure that we are creating more inclusive digital services for users with diverse needs.


Meeting WCAG 2.2

WCAG 2.2 is based on 4 principles, that emphasise the need to think about the different ways that people interact with digital content:

  • perceivable: recognising and using the service with senses that are available to the user.

  • operable: finding and using content, regardless of how a user chooses to access it.

  • understandable: understanding content and how the service works.

  • robust: content that can be interpreted reliably by a wide variety of user agents.


For example, users might use a keyboard instead of a mouse or rely on a screen reader to have content spoken aloud.


The WCAG 2.2 principles apply to all aspects of your service (including code, content and interactions), which means all members of your team need to understand and consider them. It is important to conduct regular accessibility testing using a range of automated and manual tools as early as possible to ensure your design, code, and content meet WCAG 2.2 AA requirements (all A and AA criteria).


Testing with assistive technology 

To meet the government service standard, testing should be done across the following assistive technologies and browsers throughout development, ensuring that the most commonly used assistive technologies are tested and work on the service before moving to public beta: 


  • JAWS (screen reader) on Chrome or Edge 

  • NVDA (screen reader) on Chrome, Firefox or Edge

  • VoiceOver (screen reader) on Safari 

  • TalkBack (mobile screen reader) on Chrome 

  • Windows magnifier or Apple Zoom (screen magnifiers) 

  • Dragon (speech recognition tool) on Chrome 


Low vision user using a screen magnification tool to increase the text size on a webpage to allow them to see the content clearly. 
Low vision user using a screen magnification tool to increase the text size on a webpage to allow them to see the content clearly.

Source: Digital Accessibility Centre (DAC) https://digitalaccessibilitycentre.org/usertesting.html 


It is a shared responsibility to make sure services are compatible with commonly used assistive technologies as testing across these combinations should be done throughout all stages of development; when planning new features, when designing and building new features, and testing. For more information on how to test with assistive technology, see testing with assistive technologies


User research with disabled people

Inclusive user research is essential for creating user-centred services that meet the needs of all users, including those with disabilities and diverse backgrounds. By involving a varied group of participants early on, teams can identify and address usability and accessibility barriers, enhancing the design, functionality, and content to benefit everyone.


This approach encourages continuous improvement, ensuring government services evolve with users' needs. Ultimately, inclusive user research builds trust by showing a commitment to accessibility, making services more usable and welcoming for a broader audience.


Accessibility statements 

Accessibility statements are required to communicate how accessible a service is. This includes stating the WCAG compliance level, explaining where the service has failed to meet guidelines (and a roadmap of when this will be fixed), contact information and how to report accessibility issues. Government services should follow a standard accessibility statement format to maintain consistency. 


GOV.UK Design System (GDS)

The GOV.UK design system (GDS) has many reusable components that are utilised across government services. Each component shows an example, an option to view the details on how to implement the component, as well as research regarding the component's usability and what kind of issues users have faced.


Any known accessibility issues are also highlighted and based on this research, some components are labelled ‘experimental’ as some users may still experience issues navigating them. Services must proceed with caution when adopting these components, and carry out rigorous manual, assistive technology and user testing to ensure that the implementation is accessible and WCAG guidelines are met. 

Accessibility research for the GDS details component - There is evidence that some users avoid clicking the link to show more detail as they think it will take them away from the page. There are concerns that some users of voice assist software will not be able to interact with the component. Some software might require the user to specifically refer to the link to show more details as a button in order to interact with it.
Example of where to find accessibility research on the GDS details component, under heading ‘Research on this component’. 

Source: Government Design System (GDS) details component - https://design-system.service.gov.uk/components/details/ 


Summary

Overall, government services must ensure they are creating services that are regularly tested and work with users who have a range of access needs or assistive technology requirements including: 


  • Reviewing, understanding, and meeting GOV.UK and WCAG 2.2 standards

  • Implementing accessible components that can be accessed by assistive technology

  • Ensuring accessibility is the whole team’s responsibility when developing a service

  • Regularly testing with users with disabilities

  • Providing an accessibility statement to inform users where the service does and does not meet accessibility guidelines 


Accessibility should be considered from the start as retrofitting costs more time and resources, and results in your users not being able to use your service.


DWP resource: 

The Department for Work and Pensions (DWP) accessibility manual is a great resource for guidance on testing, accessibility best practices throughout service development and details on how each member of the team can integrate accessibility.


Photograph of DWP Accessibility Manual home page on a tablet device.
DWP Accessibility Manual home page

Contact information

If you have any questions about our accessibility services or you want to find out more about other services we provide at Solirius, please get in touch.

30 views

Comments


bottom of page