M
Maria Sweeney
Guest
Accessibility standards for public-sector websites can be complicated to manage when ongoing operations are spread across regions and departments. The CMS should help.
A public-sector organization launches a redesigned website after months of accessibility work. The templates have been tested. Forms use clear labels. Keyboard navigation works. Editors have been trained on the new components.
Then normal publishing resumes.
A department adds service pages. A campaign team uploads documents. A consultation uses an external form. Someone creates a new component to meet an urgent deadline. Older microsites remain online because nobody has the budget or authority to retire them.
Six months after launch, the original templates may still perform well. The wider estate is another matter.
That is the difficult part of government website accessibility. The initial project usually has a defined team, a delivery plan and formal testing. Once the site is live, publishing spreads across departments, service owners and regional teams with different skills and priorities.
Accessibility has to survive that operating environment.
The Web Content Accessibility Guidelines provide an internationally recognized technical standard for making web content more accessible to people with disabilities. WCAG 2.2 is the latest published version, although the version required and the associated legal obligations vary by jurisdiction.
So how do public sector organizations keep maintaining their accessibility requirements when dozens or even hundreds of people can change the digital estate?
An accessible design system certainly helps, but it does not control every new document, embedded service or editorial decision.
Accessibility faults often arrive through ordinary work rather than major redesigns.
An editor uploads a PDF that has no useful heading structure. A page heading is chosen for its size rather than its place in the content hierarchy. An image has alternative text, but the description adds no useful information. A third-party form changes after procurement. A translated page is published without going through the same review as the source version.
None of these changes necessarily looks significant in isolation. Across a large estate, they accumulate.
The problem also extends beyond the pages managed directly in the CMS. Public services may involve:
An audit of the main website cannot tell you whether that complete experience is accessible.
Automated tools help teams find recurring technical faults across large numbers of pages. Their limits need to be understood. W3C states that no tool alone can determine whether a site meets accessibility standards and that knowledgeable human evaluation is required. Some checks depend on context, judgement and the way a person experiences the complete service.
The governance model must therefore cover publishing, development, procurement and testing.
The following controls are intended for organizations where publishing responsibility is distributed but standards remain centrally governed.
WCAG is written for a wide professional audience. Most departmental editors need practical instructions for the tasks they perform.
They need to know how to write useful link text, structure a page, describe an image and handle a table. They also need clear rules for documents, video, translated content and external services.
The same applies to developers. A component should not enter the shared library until the organization has agreed how it will be built, reviewed and tested.
A standards document that nobody can apply during routine work will have limited effect.
Every service page, document collection and digital journey needs an owner.
Central web teams rarely know when departmental guidance has changed or a form has been replaced. Service teams do. They should have enough access to maintain that information without raising a technical ticket for each update.
Ownership also carries responsibility. Teams need to know which content they maintain, when it should be reviewed and which issues they are expected to resolve.
This is often where governance plans remain vague. Responsibility is assigned to a department, but no individual role has the authority or time to act.
CMS controls can reduce the amount of interpretation required from individual contributors.
Editors working with approved templates and reusable components have fewer opportunities to create inconsistent structures. Structured fields can guide them through specific content requirements. Permissions can stop untrained users from changing global templates, inserting unsupported code or accessing parts of the system they do not manage.
These are guardrails, not proof of conformance. A required alternative-text field can prevent an omission. It cannot decide whether the text is useful.
The aim is to remove avoidable choices while keeping trained editors in control of their content.
A change to office opening hours does not require the same process as new public-health guidance or an application for an essential service.
Many organizations respond by either reviewing everything centrally or allowing every trained editor to publish directly. Both models create problems at scale.
A more workable approach is to group content by risk. Routine information can follow a short workflow. Content with legal, safety or eligibility implications may need additional review. Emergency information requires a faster route with named approvers and a clear record of what was published.
The workflow should reflect the consequence of getting the information wrong or making it inaccessible.
A component can pass its technical checks while the service built with it remains difficult to use.
Testing should follow the routes people take. That may include finding the service, reading guidance, downloading a document, signing in and completing a form hosted by another system.
Automated scanning is useful for coverage and repeatability. Manual review is needed for context and interaction. User testing involving people with disabilities can expose difficulties that neither the specification nor an automated report will explain. W3C recommends evaluating accessibility early and throughout development, when problems are easier to address.
The level of testing should also reflect service risk. A new reusable component deserves more scrutiny than a minor text correction.
Publishing teams need a process for assigning and resolving issues after launch. They also need to look beyond the page where the problem was found.
If the same heading fault appears across several departments, the authoring guidance may be unclear. If one widget repeatedly creates keyboard issues, the widget needs to be changed. If inaccessible documents keep being uploaded, the organization may need a different document process rather than more reminders.
Monitoring becomes useful when it changes the system behind the defect: the component, training, permissions or workflow.
The Food and Agriculture Organization of the United Nations offers a useful example of distributed publishing under central controls.
The FAO was managing 700 websites and tens of thousands of newsroom articles. Almost all its websites were available in at least six languages, while the central IT team had 10 people. Sending every website request through that team was not realistic.
Content editors were given predefined corporate templates and customized reusable components. FAO worked with Progress Professional Services to build components around shared rules and practices, then trained its team to maintain and extend them.
Production access remained tightly controlled. Only one IT team member had access to production. Editors worked in staging and used Progress Sitefinity Cloud Content Pipeline to synchronize approved changes. The central web team set platform rules and guidelines to support consistency and reduce unintended publication.
FAO had 50 content editors using Progress Sitefinity CMS and planned to increase that number to 250. It also reduced the time needed to configure the technical components of a new website from one day to one hour.
While this was not presented as an accessibility project, it does provide a concrete operating model: local teams maintain content, shared components carry central rules and production remains controlled.
Those same controls are relevant to accessibility. A tested component can be corrected centrally rather than page by page. Permissions can reflect the contributor’s responsibilities. Staging gives teams a place to review changes before publication.
Escambia County adds another part of the picture. Its previous platform was difficult for departmental staff to use, which contributed to content being left outdated. The county later integrated Sitefinity CMS with Siteimprove to support ongoing accessibility and content-quality governance.
A CMS cannot make custom code, uploaded documents or third-party systems accessible by itself. Its value lies in the controls it gives the organization and how well those controls fit real publishing work.
Sitefinity CMS supports one-, two- and three-level approval workflows. Permissions can be granted or denied to users and roles and inherited through the content hierarchy. Its multisite capabilities support different sites and languages, permissions by site or content source and content sharing between properties.
For frontend delivery, development teams can use ASP.NET Core and Next.js, while editors continue to manage pages and content through Sitefinity CMS. This gives developers control over implementation without moving routine publishing back into a development queue.
Custom AI agents can add another review layer where content is created.
Sitefinity Agentic AI allows administrators to configure agents with their own instructions and scope them to specific sites, content types and fields. An organization could configure an agent to review content against its internal accessibility guidance and flag issues such as empty image descriptions, unclear link text, missing information or inconsistent content structures. Recommendations appear within the editing experience, where the editor can preview, apply or dismiss them. The agent cannot apply a content change without a person reviewing the suggestion.
This is most useful for repeatable editorial checks across a large publishing estate. A small central accessibility team may be unable to inspect every routine update, while an agent can bring relevant guidance into the authoring process for departmental contributors.
AI suggestions do not establish WCAG conformance. They cannot confirm that a complete service works with a keyboard or screen reader, assess every third-party interaction or replace expert and user testing. Their role is to identify possible content issues earlier and reinforce the standards the organization has already defined.
A public-sector CMS demonstration should show how accessibility governance works during normal publishing. A carefully prepared sample page does not reveal how the platform behaves across departments, sites and contributor roles.
Ask the vendor to demonstrate or explain:
The demonstration should use realistic contributor roles, representative content and a complete service journey. Where a scenario requires custom development, third-party software or additional services, the vendor should identify that clearly rather than presenting it as standard product functionality.
The most revealing accessibility review may be the one conducted six months after the new site goes live.
By then, new editors have joined. Departments have published their own pages. Documents and integrations have been added. The original delivery team may no longer be involved.
Look at what has happened since launch. Are contributors using the approved components? Do service owners know what they are responsible for? Are repeated issues being traced back to their source? Can the central team correct a shared fault without fixing hundreds of pages individually?
That is the difference between an accessible launch and an organization that can maintain accessible public services.
The CMS contributes templates, permissions, workflows and reusable structures but the organization still has to decide who owns the work and what happens when standards are missed.
Continue reading...
A public-sector organization launches a redesigned website after months of accessibility work. The templates have been tested. Forms use clear labels. Keyboard navigation works. Editors have been trained on the new components.
Then normal publishing resumes.
A department adds service pages. A campaign team uploads documents. A consultation uses an external form. Someone creates a new component to meet an urgent deadline. Older microsites remain online because nobody has the budget or authority to retire them.
Six months after launch, the original templates may still perform well. The wider estate is another matter.
That is the difficult part of government website accessibility. The initial project usually has a defined team, a delivery plan and formal testing. Once the site is live, publishing spreads across departments, service owners and regional teams with different skills and priorities.
Accessibility has to survive that operating environment.
WCAG Sets the Standard. Publishing Determines What Happens Next.
The Web Content Accessibility Guidelines provide an internationally recognized technical standard for making web content more accessible to people with disabilities. WCAG 2.2 is the latest published version, although the version required and the associated legal obligations vary by jurisdiction.
So how do public sector organizations keep maintaining their accessibility requirements when dozens or even hundreds of people can change the digital estate?
An accessible design system certainly helps, but it does not control every new document, embedded service or editorial decision.
Where Accessibility Problems Return
Accessibility faults often arrive through ordinary work rather than major redesigns.
An editor uploads a PDF that has no useful heading structure. A page heading is chosen for its size rather than its place in the content hierarchy. An image has alternative text, but the description adds no useful information. A third-party form changes after procurement. A translated page is published without going through the same review as the source version.
None of these changes necessarily looks significant in isolation. Across a large estate, they accumulate.
The problem also extends beyond the pages managed directly in the CMS. Public services may involve:
- Documents and downloadable forms
- Authenticated portals
- Videos and recorded meetings
- Mapping or location tools
- External payment and application systems
- Legacy websites
- Third-party widgets
- Mobile services
An audit of the main website cannot tell you whether that complete experience is accessible.
Automated tools help teams find recurring technical faults across large numbers of pages. Their limits need to be understood. W3C states that no tool alone can determine whether a site meets accessibility standards and that knowledgeable human evaluation is required. Some checks depend on context, judgement and the way a person experiences the complete service.
The governance model must therefore cover publishing, development, procurement and testing.
The Six-Control Accessibility Governance Model
The following controls are intended for organizations where publishing responsibility is distributed but standards remain centrally governed.
1. Turn Standards into Publishing Rules
WCAG is written for a wide professional audience. Most departmental editors need practical instructions for the tasks they perform.
They need to know how to write useful link text, structure a page, describe an image and handle a table. They also need clear rules for documents, video, translated content and external services.
The same applies to developers. A component should not enter the shared library until the organization has agreed how it will be built, reviewed and tested.
A standards document that nobody can apply during routine work will have limited effect.
2. Put a Name Against the Content
Every service page, document collection and digital journey needs an owner.
Central web teams rarely know when departmental guidance has changed or a form has been replaced. Service teams do. They should have enough access to maintain that information without raising a technical ticket for each update.
Ownership also carries responsibility. Teams need to know which content they maintain, when it should be reviewed and which issues they are expected to resolve.
This is often where governance plans remain vague. Responsibility is assigned to a department, but no individual role has the authority or time to act.
3. Make Approved Practice the Easy Option
CMS controls can reduce the amount of interpretation required from individual contributors.
Editors working with approved templates and reusable components have fewer opportunities to create inconsistent structures. Structured fields can guide them through specific content requirements. Permissions can stop untrained users from changing global templates, inserting unsupported code or accessing parts of the system they do not manage.
These are guardrails, not proof of conformance. A required alternative-text field can prevent an omission. It cannot decide whether the text is useful.
The aim is to remove avoidable choices while keeping trained editors in control of their content.
4. Match Review to Risk
A change to office opening hours does not require the same process as new public-health guidance or an application for an essential service.
Many organizations respond by either reviewing everything centrally or allowing every trained editor to publish directly. Both models create problems at scale.
A more workable approach is to group content by risk. Routine information can follow a short workflow. Content with legal, safety or eligibility implications may need additional review. Emergency information requires a faster route with named approvers and a clear record of what was published.
The workflow should reflect the consequence of getting the information wrong or making it inaccessible.
5. Test Journeys, Not Isolated Pages
A component can pass its technical checks while the service built with it remains difficult to use.
Testing should follow the routes people take. That may include finding the service, reading guidance, downloading a document, signing in and completing a form hosted by another system.
Automated scanning is useful for coverage and repeatability. Manual review is needed for context and interaction. User testing involving people with disabilities can expose difficulties that neither the specification nor an automated report will explain. W3C recommends evaluating accessibility early and throughout development, when problems are easier to address.
The level of testing should also reflect service risk. A new reusable component deserves more scrutiny than a minor text correction.
6. Fix the Source of Repeated Problems
Publishing teams need a process for assigning and resolving issues after launch. They also need to look beyond the page where the problem was found.
If the same heading fault appears across several departments, the authoring guidance may be unclear. If one widget repeatedly creates keyboard issues, the widget needs to be changed. If inaccessible documents keep being uploaded, the organization may need a different document process rather than more reminders.
Monitoring becomes useful when it changes the system behind the defect: the component, training, permissions or workflow.
A Governance Model at Public-Sector Scale
The Food and Agriculture Organization of the United Nations offers a useful example of distributed publishing under central controls.
The FAO was managing 700 websites and tens of thousands of newsroom articles. Almost all its websites were available in at least six languages, while the central IT team had 10 people. Sending every website request through that team was not realistic.
Content editors were given predefined corporate templates and customized reusable components. FAO worked with Progress Professional Services to build components around shared rules and practices, then trained its team to maintain and extend them.
Production access remained tightly controlled. Only one IT team member had access to production. Editors worked in staging and used Progress Sitefinity Cloud Content Pipeline to synchronize approved changes. The central web team set platform rules and guidelines to support consistency and reduce unintended publication.
FAO had 50 content editors using Progress Sitefinity CMS and planned to increase that number to 250. It also reduced the time needed to configure the technical components of a new website from one day to one hour.
While this was not presented as an accessibility project, it does provide a concrete operating model: local teams maintain content, shared components carry central rules and production remains controlled.
Those same controls are relevant to accessibility. A tested component can be corrected centrally rather than page by page. Permissions can reflect the contributor’s responsibilities. Staging gives teams a place to review changes before publication.
Escambia County adds another part of the picture. Its previous platform was difficult for departmental staff to use, which contributed to content being left outdated. The county later integrated Sitefinity CMS with Siteimprove to support ongoing accessibility and content-quality governance.
What the CMS Evaluation Should Prove
A CMS cannot make custom code, uploaded documents or third-party systems accessible by itself. Its value lies in the controls it gives the organization and how well those controls fit real publishing work.
Sitefinity CMS supports one-, two- and three-level approval workflows. Permissions can be granted or denied to users and roles and inherited through the content hierarchy. Its multisite capabilities support different sites and languages, permissions by site or content source and content sharing between properties.
For frontend delivery, development teams can use ASP.NET Core and Next.js, while editors continue to manage pages and content through Sitefinity CMS. This gives developers control over implementation without moving routine publishing back into a development queue.
Use AI Agents to Reinforce Editorial Guidance
Custom AI agents can add another review layer where content is created.
Sitefinity Agentic AI allows administrators to configure agents with their own instructions and scope them to specific sites, content types and fields. An organization could configure an agent to review content against its internal accessibility guidance and flag issues such as empty image descriptions, unclear link text, missing information or inconsistent content structures. Recommendations appear within the editing experience, where the editor can preview, apply or dismiss them. The agent cannot apply a content change without a person reviewing the suggestion.
This is most useful for repeatable editorial checks across a large publishing estate. A small central accessibility team may be unable to inspect every routine update, while an agent can bring relevant guidance into the authoring process for departmental contributors.
AI suggestions do not establish WCAG conformance. They cannot confirm that a complete service works with a keyboard or screen reader, assess every third-party interaction or replace expert and user testing. Their role is to identify possible content issues earlier and reinforce the standards the organization has already defined.
Test the Real Publishing Model
A public-sector CMS demonstration should show how accessibility governance works during normal publishing. A carefully prepared sample page does not reveal how the platform behaves across departments, sites and contributor roles.
Ask the vendor to demonstrate or explain:
- How a departmental editor is restricted to approved templates and components
- How higher-risk content can follow a different approval route, including whether the proposed process is available through configuration or requires custom development
- How one authoritative content item can be updated once and reused across several sites
- How permissions vary by department, website, content source or role
- How translated content is created, reviewed and kept aligned with the source version
- How a shared component is corrected and updated across the estate, including who is responsible for the change and what support is available when the organization does not have an in-house developer
- How documents are uploaded, managed and reviewed within the publishing process
- How third-party forms, applications and services are incorporated into the wider user journey, recognizing that the available controls will depend on the specific service and integration
- How AI recommendations appear within the editorial workflow
- What happens when an editor applies or dismisses an AI recommendation, including how the platform handles the same suggestion during future analyses
The demonstration should use realistic contributor roles, representative content and a complete service journey. Where a scenario requires custom development, third-party software or additional services, the vendor should identify that clearly rather than presenting it as standard product functionality.
The Real Test Comes After Launch
The most revealing accessibility review may be the one conducted six months after the new site goes live.
By then, new editors have joined. Departments have published their own pages. Documents and integrations have been added. The original delivery team may no longer be involved.
Look at what has happened since launch. Are contributors using the approved components? Do service owners know what they are responsible for? Are repeated issues being traced back to their source? Can the central team correct a shared fault without fixing hundreds of pages individually?
That is the difference between an accessible launch and an organization that can maintain accessible public services.
The CMS contributes templates, permissions, workflows and reusable structures but the organization still has to decide who owns the work and what happens when standards are missed.
Continue reading...