Public Sector Web Accessibility: Requirements and Cost

What web accessibility means for the public sector#

Web accessibility means that every user - regardless of physical, sensory, or cognitive limitation - can reach the content, complete a form, and use the service through a website or mobile app. For the public sector this is not an optional feature but a legally defined requirement that applies to state administration bodies, public institutes, agencies, and providers of public services. A client needs to treat accessibility as part of the functional requirements from day one, not as an add-on after development is finished.

Accessibility is not only about the visual layer of an interface. It covers content structure, keyboard-only navigation, screen-reader readability, plain-language clarity, and the accessibility of downloadable documents. When a client drafts requirements for a new or redesigned system, it needs to define which parts fall inside the review scope - the public area, the logged-in area, forms, documents, and any mobile app.

For a client this means accessibility belongs among the criteria for selecting a contractor and among the acceptance criteria at project close. The requirement needs to be written into the tender documentation or project specification - otherwise the review happens only after go-live, when fixes are slower and more expensive.

Who must provide accessibility, and which sites it covers#

The requirements apply to websites and mobile apps run by public sector bodies - ministries, municipalities, public institutes, agencies, and providers of public services. That covers both informational sites and transactional portals through which citizens file applications, book appointments, or access personal data. A client first needs to inventory which sites, portals, and apps it runs, and for each one determine whether it is newly built, being redesigned, or taken over from a previous contractor.

When a body runs several systems at once - a main website, an application portal, and an information screen at a physical location, for instance - the accessibility scope has to be assessed separately for each, since they differ in content, user roles, and technical design. A touchscreen kiosk in a public space has different accessibility requirements than a web portal, because it is a physical device with its own interface.

Where a body takes over an existing or unfinished system from a previous contractor, accessibility is part of the intake review. The source code, interface architecture, and existing documentation are reviewed, and from that the amount of work needed to reach the required accessibility level is estimated - whether it means small fixes or an interface rebuild.

Which parts of a website need to be checked#

An accessibility review does not treat a website as one block - it goes through the interface and content building blocks one by one. A client needs to define in advance which parts of the system fall inside the review, because that scope directly sets the amount of work and the project timeline. Below are the building blocks project teams most often review when assessing accessibility on public sector sites.

The scope of a review differs depending on whether it is the public area, visited by every citizen, or the logged-in area used by staff or registered users. A client needs to set priorities - which parts of the system get the most traffic, and which functions are critical to the body's obligations.

Once the scope is set, the project team produces a list of findings by building block, ranked by urgency. That lets a client plan fixes in batches and roll them into regular releases, instead of waiting for one large fix across the entire system.

• Content structure and mouse-free keyboard navigation
• Screen-reader readability and descriptions of images and graphics
• Color contrast, font size, and layout adaptability
• Forms, confirmation messages, and error messages
• Downloadable documents (PDF and other formats)
• Video and audio content with captions or a transcript
• The mobile app, where one exists as part of the same system

How the accessibility review and testing work#

An accessibility review runs much like other functional and QA testing - it combines manual testing, automated tools, and testing against key user scenarios. Manual testing covers keyboard-only navigation, screen-reader checks, and checking whether content is understandable. Automated testing quickly catches technical issues in the code but does not catch every problem related to clarity and usability.

The accessibility review is folded into the existing QA process, which includes test scenarios, manual and automated testing, and testing in a development and staging environment kept separate from production. That means fixes are tested before they reach production, and on larger projects an independent QA team, separate from the development team, can be brought in to strengthen the reliability of the findings.

After the review, the client receives a list of findings ranked by severity and impact on the user. That list becomes the basis for a fix plan, which can be rolled out gradually alongside regular releases or delivered as a single effort before a new system goes live.

What accessibility means for existing and inherited systems#

Many public sector websites and portals were built years ago, often by a different contractor, without an explicit accessibility requirement. When a client takes over such a system, the first step is a review of the source code, architecture, and infrastructure, which determines whether reaching the required accessibility level is possible through adjustments to the existing interface or requires rebuilding parts of the system.

The choice between rebuilding and adjusting depends on how the system was designed. If the interface is built modularly, individual building blocks can often be fixed without touching the overall architecture. If the system is outdated or poorly documented, rebuilding part of the interface is often faster and cheaper than a long series of individual fixes.

When taking over an existing system, a client needs to demand access to the source code, documentation, passwords, and infrastructure - without that, neither an accessibility review nor later fixes are possible. That holds even when the system was built by an external contractor no longer active as the body's partner.

Roles and responsibilities on an accessibility project#

An accessibility project involves several roles on both the client and contractor side, so it is worth defining roles and responsibilities before work starts. On larger projects a project lead is assigned to coordinate teams, deadlines, and reporting to the client, while the client names its own contact person who signs off on priorities and accepts results.

A clear split of responsibility stops fixes from falling through organizational cracks - for example, when content belongs to the client but interface code belongs to the contractor. A client needs to know in advance who on its side handles regular content publishing, and bring that person into training on accessibility requirements.

At project close a formal handover takes place, covering source code, documentation, access, and passwords, since these belong to the client. That lets the client maintain the system's accessibility going forward, on its own or with a different contractor, without being locked into a single provider.

How to choose a contractor for an accessibility review and fixes#

When choosing a contractor for an accessibility project, check whether the provider covers the full scope of work - from review and QA testing to code fixes and content adjustments - or only part of the process. The project can be taken on in full or as a single work package, such as only the review or only fixes following a review done elsewhere. Public sector experience, such as building interactive content for a public space for the Sevnica municipality project, is a relevant reference here.

A client should ask the contractor to define how progress reporting will work, who is assigned as project lead, and how findings will be ranked by urgency. That lets a client compare bids on process, not only on the promised outcome.

It is also worth checking whether the contractor separates review from fixes - whether the same team that made the fixes also checks the result, or whether a separate QA function is involved. An independent review increases the reliability of the findings, especially on systems with a broad user base.

• Experience with public sector work and similar systems (portals, information systems, kiosks)
• Ability to run both manual and automated testing
• Clear separation of development, staging, and production environments
• Willingness to take over an existing or unfinished system after a code review
• Clean handover of documentation, access, and passwords at project close
• Willingness to agree on post-launch support and response times

What drives the cost of an accessibility project#

The cost of an accessibility project is not set as a flat figure - it follows a review of the scope and the state of the existing system. It depends on how many sites, portals, and apps need reviewing, how many existing systems need connecting, and whether the work is new development or taking over and upgrading an existing system. It also depends on how much data and content needs reviewing and cleaning up, and on security and audit-trail requirements, which in the public sector often exceed private-sector requirements.

The scope of work is also shaped by whether a mobile component is needed and for which platforms, how much testing is required - whether manual testing is enough or automated and independent QA are also needed - and what level of post-launch support is planned, including agreed response times. Each of these factors changes the amount of work, and with it the cost.

Before pricing, a short analysis is recommended that breaks the scope into packages - the review, code fixes, content adjustments, and testing, for instance - so that each package can be estimated and delivered separately. That lets a client run the project in stages and adjust scope to the budget available in a given year.

Maintaining accessibility after go-live#

Accessibility is not a one-off project - it has to be maintained every time content or functionality changes. A new publication, a new form, or a new feature can reopen an accessibility issue, so it makes sense for a client to set up, after go-live, an ongoing way of tracking and fixing new deviations rather than a single one-time alignment.

After go-live, a contractor can take over monitoring, bug fixing, technical and security updates, and further development within an agreed SLA. Issues are ranked into classes by severity - from a system outage, through a disruption in a single function, to a minor issue with no impact on operations, which is scheduled into the next regular release. Changes and upgrades are scoped separately, with a delivery date agreed on their own terms.

Every change passes through review and testing before it reaches production, and that includes accessibility-related fixes. That ensures a new fix does not break parts of the system already brought into line, and that the client keeps an ongoing view of accessibility status rather than relying on a single one-time review.