Website Accessibility for Government Entities:
What Should Be Tested?
Government & Public Sector
Government website accessibility is essential to helping people use public services independently. Whether someone is renewing a licence, applying for support, paying a fee or booking an appointment, they should be able to complete the entire digital journey. When accessibility barriers prevent this, users may miss deadlines, need help with personal information or be unable to access an essential service.
Start with the services people need to complete
Begin by identifying your most important public tasks. Examples include applying for a permit, checking eligibility, submitting supporting documents, paying a charge, tracking a request and raising a complaint. Prioritise services with statutory deadlines, financial consequences or a high impact on people’s daily lives.
For each task, map the journey from the service information page through every transaction step to confirmation. Include login, redirects to external platforms, validation errors and downloadable outputs. A usable homepage cannot compensate for a blocked application form.
W3C’s Website Accessibility Conformance Evaluation Methodology (WCAG-EM) provides a structured approach to defining scope, exploring a website, selecting a representative sample, evaluating it and reporting findings. For large government portals, use that structure to build a defensible assessment scope rather than selecting a few convenient pages. [2]
Record the boundaries clearly: domains, authenticated areas, language versions, documents, integrations and environments. A representative audit is useful evidence about the assessed scope; it should not be presented as proof that every untested page is accessible.
Agree the benchmark before testing begins
The brief should name the applicable standard, its version and the required conformance level. WCAG 2.2 Level AA is a useful technical target for new or updated web services, subject to the requirements that apply to your entity. W3C recommends using WCAG 2.2 when developing or updating accessibility policies. [1]
Do not assume that every GCC government body has identical obligations. Confirm relevant national requirements, authority policies and contractual commitments before approving the assessment brief. Separate mandatory requirements from additional improvements your organisation chooses to adopt.
For WCAG Level AA conformance, all applicable Level A and AA criteria must be met. WCAG also addresses complete processes: the pages needed to complete an activity must conform. [1] A percentage score alone is therefore an inadequate acceptance criterion.
What Should a Government Website Accessibility Audit Cover?
1. Navigation, keyboard access and screen readers
Test whether users can move through menus, search results, service categories, dialogs and interactive controls using a keyboard. Review the order and visibility of focus, and check that people can leave every component without becoming trapped. Assess page headings, control names and announcements with screen readers. [1]
Translate those checks into public-service scenarios. Can a keyboard user select an appointment slot? For someone using a screen reader, are similarly named services distinguishable? When a consent dialog is closed, does focus return to a logical position so the user can continue? Your test script should capture both the technical issue and its effect on the task.
2. Forms, uploads and recovery from errors
Government transactions often involve lengthy forms, conditional questions and supporting evidence. Exercise the difficult paths deliberately: an incomplete required field, an invalid reference number, an unsupported attachment and a failed upload. Assess whether the user understands the problem and can recover without restarting unnecessarily.
Review labels, instructions and error identification against the agreed standard. [1] Also assess operational clarity: file limits should be explained before upload, saved progress should be understandable, and a failed submission should not leave users unsure whether the authority received their application.
3. Login, identity verification and session handling
Authentication can prevent access before a user reaches the service. Test registration, login, password reset, verification codes and any single sign-on handoff within the agreed scope. Verify support for password managers and pasting credentials or codes where relevant. WCAG 2.2’s accessible authentication criterion addresses cognitive tests, permitted assistance mechanisms and defined exceptions. [5]
Assess session expiry and recovery using realistic scenarios. Ask your security and service teams to agree how users will be warned, what can be saved and how they can resume. Security decisions should be evaluated alongside their effect on people who need additional time or assistive technology.
4. Payments, declarations and confirmation
A user should understand the action they are about to take, its consequences and whether it succeeded. Test the review screen, fee information, declarations, payment handoff, return to the portal and receipt.
For submissions covered by WCAG’s legal, financial or data error-prevention criterion, at least one safeguard must be provided: reversibility, checking with an opportunity to correct errors, or review and confirmation before finalisation. [6] Your assessment should identify which safeguard the service uses and test it in practice.
Include failure and cancellation paths. A payment error, for example, should not leave someone uncertain about whether to pay again. Record who owns each problem when the transaction crosses organisational or supplier boundaries.
5. Arabic and English service journeys
Where both languages are offered, assess each version. Shared templates do not guarantee equivalent accessibility: translated instructions, validation messages, attachments and layouts may differ.
Check programmatic language identification, including passages in another language where applicable, so assistive technologies can interpret the content appropriately. [7] Test right-to-left presentation and mixed Arabic-English content separately, especially reference numbers, dates, telephone numbers and payment values.
For GCC public-sector teams, bilingual acceptance testing should be explicit in the project scope. Include equivalent tasks in Arabic and English and record findings against the relevant language version. This avoids approving one journey while leaving the other unverified.
6. Mobile use, zoom and visual presentation
Assess the service on smaller screens and with enlarged content. WCAG’s reflow criterion addresses presenting content without loss of information or functionality and without requiring scrolling in two dimensions, subject to specified exceptions. [8]
For the service team, the practical test is whether people can still locate instructions, complete fields and reach the action button. Check sticky headers, chat controls and banners under these conditions. A layout that works at its default desktop size may behave differently when the viewport changes.
7. Documents, videos and external components
Inventory the content people need to use the service: application guides, downloadable forms, eligibility documents, notices and instructional videos. Identify which items belong within the assessment and which require a separate document or media review.
For PDFs, request checks of reading order, structure, text alternatives, tables and interactive fields. For video, consider captions and the accessibility of information conveyed visually. An accessible HTML alternative can be particularly helpful for essential guidance, but it should preserve the information users need.
Include embedded booking systems, payment interfaces and help tools in the service map. If an external component cannot be fully tested, record that limitation and request evidence from its supplier. Contract boundaries should be visible in the report because they determine who can resolve a barrier.
Use automation as one part of the assessment
An automated accessibility checker can help government teams detect repeatable technical problems and monitor releases. However, government website accessibility testing must also establish whether people can complete essential services with a keyboard and assistive technology. W3C explains that no tool alone can determine whether a website meets accessibility standards, so automated results need knowledgeable human evaluation. [3]
A government assessment should combine automated checks with manual review and assistive-technology testing. Where feasible, involve people with disabilities in realistic tasks to understand difficulties that may not be apparent from technical checks alone. W3C recommends involving users alongside standards-based evaluation; user feedback does not replace conformance assessment. [4]
Similarly, installing an accessibility widget is not sufficient evidence to approve a public service. Evaluate the underlying journey and the behaviour of any added tool. At VisiAble, we recommend keeping assistance features and formal acceptance evidence distinct in your project decisions.
Request evidence your team can act on
An effective audit report should support delivery decisions. We recommend requesting the following information:
- Assessment scope, benchmark, dates, tested languages and technology combinations, with exclusions and limitations.
- For each finding: affected page or component, relevant criterion, reproduction steps, evidence and impact on the user’s task.
- Remediation guidance, a responsible owner and a priority informed by service impact.
- A retest record showing which fixes were verified, which issues remain and what still needs assessment.
Prioritise barriers that prevent essential tasks, but keep severity separate from conformance. A finding described as minor can still fail an applicable criterion. Management decisions about sequencing repairs should not be mistaken for evidence that the required standard has been met.
If procurement requires an Accessibility Conformance Report (ACR), agree its scope and supporting evidence in advance. A completed VPAT template should be evaluated alongside the underlying assessment, product version and stated limitations. Documentation is useful when it accurately represents the service being accepted.
Make accessibility part of acceptance and ongoing ownership
Procurement teams should define the benchmark, assessment coverage, evidence required, supplier remediation responsibilities and retesting arrangements before contract award. Digital and IT teams should include accessibility reviews during design and development, rather than leaving the entire assessment to the final handover. W3C recommends evaluating early and throughout development. [3]
After launch, assign an owner for accessibility across the service. Establish review triggers for redesigned forms, new integrations, CMS template changes and newly published documents. Give content editors practical guidance and maintain an issue log that service owners can review.
Publish an accessibility statement that explains your commitment, the standard being pursued, known limitations and a way to report barriers. W3C provides guidance on these elements. [9] Ensure the feedback route is usable and backed by a response process. An alternative contact channel can help resolve immediate difficulties while the digital barrier is addressed.
A practical example: applying for a government permit
Consider a hypothetical resident applying online for a permit. The assessment should follow the application from initial guidance to the issued confirmation, including unsuccessful attempts. This is an illustrative test scenario, not a VisiAble client case study.
Start with eligibility: can the resident locate the correct service and understand its requirements in the selected language? Then test login with a keyboard and screen reader. Continue through the form, deliberately leaving a required field blank and uploading an unsupported file. Check whether the resident can identify each problem, correct it and continue without losing completed information.
Next, review the declaration and payment stages. Can the resident check their details before submission, understand the fee and return from the payment provider? Test a cancelled or failed payment as well as a successful one. Finally, verify that the resident can recognise the outcome, retrieve the reference number and access any receipt or confirmation document.
If a barrier blocks the journey, record the affected step, evidence, user impact and responsible supplier. Retest the repaired step within the complete journey. Resolving an isolated component is not enough if the resident still cannot finish the application.
A pre-launch checklist for public-sector teams
Before approving a new or redesigned service, confirm that:
- The applicable benchmark and acceptance requirements are documented.
- Priority journeys, both offered languages and relevant external components are included in the assessment scope.
- Manual and assistive-technology testing covers successful completion, errors and recovery.
- Essential documents and media have been assessed or their review status is recorded.
- Findings have named owners, agreed remediation dates and documented retest outcomes.
- Remaining barriers and untested areas are disclosed to the acceptance decision-maker.
- An accessibility owner and a usable feedback route are in place for ongoing operation.
Use this checklist to organise readiness discussions. It is not a substitute for evaluating all applicable criteria or for the evidence required by your authority.
How VisiAble supports public-sector accessibility teams
VisiAble helps organisations assess digital accessibility through professional audits, manual testing and conformance documentation based on recognised standards. For government and public-sector teams, we recommend agreeing the assessment around your priority services, Arabic and English journeys, relevant documents and vendor boundaries.
This gives your digital, procurement and service-delivery teams a shared basis for understanding barriers and planning improvements. The deliverables, testing coverage and any retesting should be defined in the engagement scope so the evidence matches the decisions your organisation needs to make.
If your entity is preparing to launch, redesign or evaluate a digital service, speak to VisiAble about a professional accessibility audit. Start with the services your users need to complete and establish what must be tested before acceptance.
How VisiAble Can Help
VisiAble helps government and public-sector teams assess website accessibility across the services people need to complete. Whether your entity is launching a new portal, reviewing an existing platform or evaluating a supplier’s delivery, our focus is on identifying barriers and providing clear evidence for improvement.
Our professional accessibility audit combines automated testing with expert manual review against the agreed WCAG version and conformance level. The assessment can cover priority service journeys, including navigation, authentication, application forms, document uploads, payments and confirmation messages, with Arabic and English interfaces included in the agreed scope.
We support your team with:
Practical findings: Documented barriers, affected pages or components, relevant accessibility criteria and recommendations for resolving each issue.
Service-based priorities: Findings prioritised by their impact on users, particularly barriers that prevent people from completing essential transactions.
Support for developers and suppliers: Clear guidance to help teams understand the findings and implement appropriate fixes.
Verification after remediation: Retesting within the agreed scope to confirm whether identified barriers have been resolved.
Evidence for internal review: Assessment documentation to support project acceptance, procurement discussions and ongoing accessibility management.
For government teams, the objective is to make accessibility part of service delivery, with a defined scope, accountable actions and evidence of progress.
Contact VisiAble to discuss your platform, priority services and accessibility assessment requirements.
Official Sources
- W3C: Web Content Accessibility Guidelines (WCAG) 2.2
- W3C WAI: WCAG-EM Overview
- W3C WAI: Evaluating Web Accessibility Overview
- W3C WAI: Involving Users in Web Projects
- W3C: Understanding Accessible Authentication (Minimum)
- W3C: Understanding Error Prevention (Legal, Financial, Data)
- W3C: Understanding Language of Parts
- W3C: Understanding Reflow
- W3C WAI: Developing an Accessibility Statement
