A public sector platform is accessible for all citizens when it meets recognised digital accessibility standards, supports assistive technologies, and is designed with the needs of diverse users in mind from the outset. Accessibility is not a single feature but a combination of technical compliance, thoughtful design, and ongoing maintenance. The questions below unpack each dimension of what truly accessible government digital services look like in practice.
What accessibility standards must public sector platforms meet?
Public sector platforms must meet the Web Content Accessibility Guidelines (WCAG), currently at version 2.1 or 2.2, with a minimum conformance level of AA. In many countries, including EU member states and the UK, this requirement is written into law. WCAG compliance means content must be perceivable, operable, understandable, and robust for all users, including those relying on assistive technologies.
Beyond WCAG, public sector organisations in the European Union must comply with the EU Web Accessibility Directive, which mandates accessibility statements and regular audits for all public websites and mobile applications. In the United States, Section 508 of the Rehabilitation Act sets equivalent requirements for federal agencies. These frameworks share a common foundation: ensuring that citizens with visual, auditory, motor, or cognitive impairments can access government services on equal terms.
Meeting these standards requires more than a one-time audit. Platforms must be tested with automated tools, manual review, and real users with disabilities to confirm that compliance is genuine rather than superficial. Accessibility statements must be kept current, and feedback mechanisms must be in place so citizens can report barriers they encounter.
How does inclusive design differ from accessibility compliance?
Inclusive design is a broader approach that considers the full diversity of human experience from the earliest stages of design, while accessibility compliance focuses on meeting defined technical standards for users with disabilities. Compliance asks whether a platform passes a checklist; inclusive design asks whether the platform genuinely works well for everyone, including people with low digital literacy, older citizens, non-native speakers, and those using low-bandwidth connections.
A platform can be technically WCAG-compliant and still be difficult to use for many citizens. Inclusive design addresses this gap by involving diverse users in research and testing throughout the design process, not only at the end. It considers context of use, such as someone accessing a benefits portal on a shared mobile device with a slow connection, and designs for that reality.
The practical difference is significant for government digital services. Compliance sets a floor; inclusive design raises the ceiling. Organisations that invest in inclusive design typically find that the improvements benefit all users, not only those with specific needs. Clearer language, simpler navigation, and better error handling help everyone complete tasks more successfully.
What are the most common accessibility barriers on government platforms?
The most common accessibility barriers on government platforms include poor colour contrast, missing alternative text for images, inaccessible form fields, keyboard navigation failures, and documents published only as PDFs without accessible alternatives. These issues consistently appear in accessibility audits of public sector websites and prevent a significant portion of citizens from completing essential tasks online.
- Colour contrast failures: Text that does not meet minimum contrast ratios is unreadable for users with low vision or colour blindness.
- Missing alt text: Images without descriptive alternative text are invisible to screen reader users, including charts and infographics that convey important information.
- Inaccessible forms: Form fields without proper labels, unclear error messages, and time limits that cannot be extended create significant barriers for users with cognitive or motor impairments.
- Keyboard navigation gaps: Users who cannot use a mouse rely entirely on keyboard navigation. Missing focus indicators or illogical tab order make forms and menus unusable.
- PDF-only content: PDFs are frequently inaccessible by default and cannot reflow for mobile screens or be read reliably by assistive technologies unless specifically tagged.
Beyond these technical issues, language complexity is a persistent barrier. Government content is often written at a reading level that excludes citizens with lower literacy, those with cognitive disabilities, and non-native speakers. Plain language is an accessibility requirement, not merely a stylistic preference.
How can user research improve accessibility for diverse citizen groups?
User research improves accessibility by revealing how real citizens with different needs, abilities, and contexts actually interact with a platform, uncovering barriers that automated tools and internal reviews miss. Recruiting participants who represent the diversity of the citizen population, including older adults, people with disabilities, and those with limited digital experience, produces insights that cannot be obtained any other way.
Effective accessibility-focused user research includes usability testing with assistive technology users, contextual interviews to understand how people access services in their daily lives, and task-based testing that reveals where citizens get stuck or give up. These methods surface both technical failures and design problems that compliance checklists do not capture.
User research also helps prioritise remediation work. Not every accessibility issue has equal impact. Research identifies which barriers affect the largest number of citizens or block access to the most critical services, allowing teams to direct effort where it matters most. Ongoing research, rather than a single round of testing, ensures that accessibility improvements are validated and that new features do not introduce new barriers.
What role does technology infrastructure play in platform accessibility?
Technology infrastructure plays a foundational role in platform accessibility by determining whether a platform can reliably support assistive technologies, load quickly on low-bandwidth connections, and remain available to all users regardless of device or browser. A well-designed interface built on fragile or outdated infrastructure will still fail citizens when performance degrades or compatibility breaks.
Key infrastructure considerations for accessible government digital services include:
- Performance and load times: Slow platforms disproportionately affect users on older devices or limited data plans, which are more common among lower-income citizens and older adults.
- Browser and device compatibility: Public sector platforms must function across a wide range of browsers, operating systems, and screen sizes, including older software versions that some users cannot upgrade.
- Cloud architecture: Scalable cloud infrastructure ensures platforms remain available during peak demand, such as tax filing deadlines or benefit application periods, preventing access failures at critical moments.
- Semantic HTML and ARIA support: The underlying code structure must use correct HTML semantics and ARIA attributes so that assistive technologies can interpret and navigate content accurately.
Infrastructure choices made early in a platform’s development have lasting consequences for accessibility. Retrofitting accessibility onto a poorly structured codebase is significantly more costly and less effective than building it in from the start. This is why greenfield platform projects offer the best opportunity to embed accessibility at every layer of the technical stack.
How should public sector organisations measure and maintain accessibility over time?
Public sector organisations should measure accessibility through a combination of automated testing, manual expert review, and regular user testing with people who have disabilities, repeated at defined intervals and after every significant platform update. Accessibility is not a state that can be achieved once and preserved without effort; it requires continuous monitoring because platforms evolve, and new barriers can be introduced with every change.
A sustainable accessibility maintenance programme typically includes:
- Automated scanning: Tools that run continuously or on a scheduled basis to flag common WCAG failures such as missing alt text, contrast issues, and broken focus management.
- Manual audits: Periodic reviews by accessibility specialists who test with assistive technologies and apply judgement that automated tools cannot replicate.
- User feedback channels: A clearly signposted mechanism for citizens to report accessibility problems, with a defined process for responding and resolving issues within a reasonable timeframe.
- Regression testing: Accessibility checks built into the development pipeline so that new code releases are tested before they reach production.
- Published accessibility statements: Transparent documentation of known issues, planned remediation timelines, and contact information for citizens who need alternative access.
Measuring accessibility also means tracking outcomes, not only conformance. Completion rates for key citizen tasks, support contact volumes, and feedback from citizens with disabilities provide evidence of whether the platform is genuinely serving its full audience, not only passing a checklist.
How Bloom Group helps build accessible public sector platforms
Building a genuinely accessible public sector platform requires the right combination of technical expertise, inclusive design practice, and structured user research. That is exactly where we come in.
At Bloom Group, we bring together highly qualified developers, UX and UI designers, and data specialists to help organisations design and build digital services that work for every citizen. Here is what working with us looks like in practice:
- We embed WCAG compliance and inclusive design principles from the earliest stages of platform development, so accessibility is never an afterthought.
- Our UX research capability allows us to recruit and test with diverse citizen groups, surfacing real barriers before they reach production.
- We provide cloud architecture and application development expertise to ensure your platform performs reliably across devices, connections, and assistive technologies.
- Through our applications in the social domain, we have direct experience building digital services for public and citizen-facing contexts.
- We offer Team as a Service (TaaS) models, meaning we can embed directly into your organisation to support ongoing accessibility monitoring and improvement cycles.
If you are ready to make your government digital services genuinely accessible for all citizens, get in touch with our team and let us show you how we can help.
Frequently Asked Questions
How long does it typically take to make an existing government platform fully accessible?
The timeline depends heavily on the size and complexity of the platform, the severity of existing barriers, and the resources available. A focused remediation project for a moderately complex platform typically takes between three and twelve months, with critical barriers prioritised first. However, full accessibility is best understood as an ongoing programme rather than a one-time project, since platforms continuously evolve and new content or features can introduce new barriers.
What is the difference between WCAG 2.1 and WCAG 2.2, and which should public sector platforms target?
WCAG 2.2, published in October 2023, builds on WCAG 2.1 by adding nine new success criteria, with a particular focus on improving accessibility for users with cognitive disabilities and those navigating on mobile devices. Public sector platforms should aim to meet WCAG 2.2 AA as the current best practice standard, though many legal frameworks still reference 2.1. Targeting 2.2 ensures compliance with both versions and provides a stronger foundation for inclusive design.
How do we recruit people with disabilities for accessibility user research without it becoming tokenistic?
Meaningful recruitment starts with partnering with disability organisations, community groups, and advocacy networks rather than relying on generic research panels, which often underrepresent people with disabilities. Participants should be compensated fairly for their time, and research should be designed around their genuine interaction with real tasks rather than abstract usability scenarios. Running multiple rounds of research with different participant profiles, rather than a single session, ensures findings reflect the breadth of lived experience rather than one person’s perspective.
Can automated accessibility testing tools be relied upon to confirm that a platform is fully compliant?
No — automated tools are valuable for catching a defined set of common, detectable issues such as missing alt text, contrast failures, and absent form labels, but they typically identify only 30–40% of WCAG failures. Many accessibility barriers, such as confusing navigation structure, misleading error messages, or illogical reading order, require human judgement and assistive technology testing to uncover. Automated scanning should be treated as a first filter, not a compliance certificate.
What should a public sector accessibility statement include, and how often should it be updated?
A compliant accessibility statement should clearly state which standard the platform aims to meet, list any known accessibility issues and their impact on users, provide a contact route for citizens to report barriers or request alternative formats, and include a timeline for resolving outstanding issues. Under the EU Web Accessibility Directive, statements must be reviewed and updated at least annually, and whenever a significant platform change is made. Statements should be written in plain language and be easily findable, not buried in a footer.
What are the most common mistakes organisations make when approaching a first accessibility audit?
The most common mistake is treating the audit as the end goal rather than the starting point, receiving a report of issues and then failing to embed the fixes into a sustainable development process. Organisations also frequently audit only their homepage or a small sample of pages, missing critical barriers on high-traffic transactional journeys such as application forms or account management flows. A well-scoped audit should prioritise the citizen journeys that carry the highest volume or serve the most vulnerable users, and findings should feed directly into a prioritised remediation backlog with clear ownership.
How can accessibility requirements be built into procurement and vendor contracts to avoid inheriting inaccessible platforms?
Accessibility requirements should be included as mandatory technical criteria in procurement specifications, referencing the applicable WCAG version and conformance level, and vendors should be required to provide a Voluntary Product Accessibility Template (VPAT) or equivalent evidence of compliance. Contracts should also include provisions for ongoing accessibility maintenance, regression testing, and remediation within defined timeframes if issues are discovered post-deployment. Evaluating vendor responses against real accessibility criteria during the tender process — rather than accepting self-declarations — significantly reduces the risk of inheriting a non-compliant platform.