Accessibility is a Systems Problem: Lessons From Reviewing 243+ Government Accessibility Issues

Accessibility is often treated as a compliance exercise. A checklist. A requirement. Something organisations need to complete before launching a website, application or digital service.

After spending several months reviewing government digital systems and identifying more than 243 accessibility issues across multiple platforms, I came to a different conclusion.

Accessibility is not primarily a compliance problem.

It is a systems problem.

Some findings appeared once. Others appeared repeatedly, with individual issues occurring dozens of times across pages, workflows and applications. The volume of findings was significant, but the more important insight was not the number itself.

It was how consistently the same patterns appeared.

Keyboard accessibility gaps. Missing labels. Inconsistent validation. Weak focus states. Poor semantic structure. Incorrect ARIA usage. Dynamic content that was not announced to screen readers. Complex tables without sufficient structure. Map-based interactions that were difficult or impossible to use without a mouse.

These issues were not random.

They reflected the way digital products were designed, procured, built, tested, governed and maintained.

The biggest accessibility lessons were not only about accessibility.

They were about delivery.

Accessibility Is About Reducing Friction

Every accessibility issue represents a moment where a user encounters unnecessary friction.

Sometimes that friction is minor. Sometimes it slows a user down. Sometimes it causes confusion. Sometimes it completely prevents someone from completing a task.

A missing label can make a form difficult to understand. Poor keyboard support can block a user from progressing. Weak focus visibility can make navigation uncertain. Inaccessible validation can leave users unaware of what went wrong. Complex tables without structure can make important information almost impossible to interpret.

Accessibility is often described in legal or technical language, but at its core it is about whether people can use a service.

Good accessibility reduces friction.

It makes digital services clearer, more predictable and easier to complete.

Accessibility Problems Rarely Exist in Isolation

One of the clearest lessons from the review was that accessibility issues rarely appeared as isolated defects.

A missing form label was rarely just a missing form label.

The same workflow might also include unclear validation messages, poor keyboard support, insufficient focus visibility, inconsistent heading structure or dynamic content that was not properly announced to assistive technology.

This matters because it changes how organisations should respond.

If an issue is isolated, it can be fixed as a defect. If the same issue appears repeatedly across multiple systems, templates or vendors, it is usually a pattern problem.

Pattern problems require more than remediation.

They require standards, reusable components, implementation guidance, governance and ownership.

The Same Issues Reappear When Accessibility Enters Too Late

Many accessibility problems become expensive because they are discovered too late.

When accessibility first appears during quality assurance or final testing, teams are often working against fixed designs, established code, release deadlines and limited budgets.

At that stage, accessibility can feel like rework.

But when accessibility is considered during planning, procurement, design and development, it becomes part of normal delivery.

The earlier accessibility is introduced, the easier it is to manage.

A procurement requirement can prevent years of accessibility debt. A design system decision can improve dozens of future interfaces. A reusable component can remove the need for every team to solve the same problem independently.

Accessibility should not be something that waits until the end of a project.

It should be built into the delivery lifecycle from the beginning.

Most Accessibility Issues Are Preventable

Many of the issues identified were not highly complex technical failures.

Common examples included missing alternative text, incorrect heading hierarchy, insufficient colour contrast, unlabelled form fields, inaccessible documents, unclear validation messages, keyboard traps and inconsistent focus states.

These problems are serious because they create barriers for users. But they are also preventable.

They can often be avoided through better design practices, stronger development standards, accessible component libraries, clearer acceptance criteria and more consistent testing.

This is why accessibility should be treated as a quality discipline, not just a compliance activity.

The goal is not simply to find issues.

The goal is to reduce the number of issues being created in the first place.

Design Systems Are One of the Most Powerful Accessibility Tools

Some of the strongest-performing digital experiences shared a common characteristic: consistency.

Buttons behaved predictably. Forms followed recognisable patterns. Navigation was understandable. Focus states were visible. Components were reused rather than rebuilt from scratch.

This is where design systems become extremely powerful.

When accessibility is built into a design system, improvements can be distributed across multiple products and services. A better form component can improve every form that uses it. A better modal pattern can improve every dialog. A better table pattern can improve every complex data view.

Without reusable accessible patterns, accessibility depends on every individual team remembering every individual requirement every time.

That is rarely sustainable.

Automated Testing Is Valuable, But It Is Not Enough

Automated accessibility testing tools are extremely useful.

Every organisation should use them.

They can quickly identify many technical issues, including missing labels, contrast failures, structural problems and some ARIA errors.

However, automated testing only finds part of the problem.

Many important accessibility issues require human judgement.

Can a user complete the task using only a keyboard? Does the page structure make sense? Is the error message helpful? Does the link text make sense out of context? Does the workflow behave predictably? Does a screen reader user receive the information they need at the right moment?

Accessibility is ultimately about people completing tasks.

Automated testing should be treated as a starting point, not a complete accessibility strategy.

Compliance Versus Capability

Compliance asks whether a system meets a standard at a point in time.

Capability asks whether an organisation can continue producing accessible systems over time.

That distinction matters.

An audit can help an organisation understand its current level of compliance. But sustainable accessibility requires organisational capability.

That capability includes standards, policies, procurement requirements, ownership models, training, reusable components, testing practices, documentation and governance.

Compliance can identify problems.

Capability helps prevent them from returning.

The Accessibility Artefacts That Actually Help

Accessibility documentation is only valuable when it solves a real delivery problem.

In a large organisation, different artefacts serve different purposes.

A policy explains the organisation’s commitment. A standard defines expectations. A checklist helps delivery teams apply those expectations. A RACI clarifies ownership. A findings register supports remediation. Procurement requirements help prevent inaccessible products from being purchased. Training builds capability over time.

Together, these artefacts create an accessibility operating model.

The most useful artefacts usually include:

• Accessibility Policy: Defines the organisation’s position, obligations and expectations.
• Accessibility Standard: Sets the technical and delivery requirements teams need to meet.
• Accessibility RACI: Clarifies responsibility between system owners, product teams, vendors, developers, QA and governance teams.
• Delivery Lifecycle Checklist: Embeds accessibility into planning, design, development, testing, release and maintenance.
• Procurement Requirements: Ensures accessibility is considered before platforms, products or vendors are selected.
• Audit Checklist: Creates a consistent method for reviewing systems against accessibility expectations.
• Findings Register: Provides a source of truth for issues, priorities, WCAG references, ownership and remediation status.
• System Owner Briefings: Translate audit findings into practical actions for the people responsible for systems.
• Training Programme: Builds awareness and capability across design, content, development, QA and product roles.
• Maintenance Guide: Helps teams sustain accessibility after the initial audit or remediation phase.

The goal is not to produce documents for the sake of documentation.

The goal is to create practical tools that help people make better decisions during delivery.

Accessibility Needs Different Conversations at Different Levels

One of the most important lessons was that accessibility cannot be communicated the same way to every audience.

Executives, system owners, product owners, technical leads, vendors, developers and QA teams all need different information.

Executives need to understand risk, compliance exposure, public service impact and organisational priorities.

System owners need to understand which issues affect their platforms, what needs to be remediated and how to prioritise action.

Technical leads need implementation detail, reusable patterns and guidance on how to fix issues correctly.

Product owners need support converting findings into backlog items and release planning decisions.

Procurement teams need clear accessibility requirements that can be included in vendor selection and contracts.

QA teams need testing criteria that can be embedded into normal release processes.

Accessibility programs often fail when the same report is handed to everyone.

Successful accessibility adoption requires the message to be translated for each layer of the organisation.

The Organisation Funnel Matters

Accessibility findings need a path through the organisation.

It is not enough to identify issues and send a report.

Issues need to move from assessment into ownership, prioritisation, remediation, validation and ongoing governance.

A practical delivery funnel might look like this:

1. Audit findings identified: Issues are reviewed, documented and prioritised.
2. Findings register created: Each issue is recorded with context, severity, WCAG reference and remediation guidance.
3. System owner briefings delivered: Findings are explained to the people accountable for each system.
4. Technical leads engaged: Implementation detail is clarified and repeated patterns are identified.
5. Backlog items created: Findings are converted into actionable remediation tasks.
6. Priorities agreed: High-risk public-facing and transactional issues are addressed first.
7. Fixes implemented: Delivery teams or vendors remediate issues.
8. QA and accessibility retesting completed: Fixes are validated before release.
9. Patterns added to guidance: Recurring issues inform standards, checklists and design system improvements.
10. Governance maintained: Accessibility becomes part of ongoing delivery rather than a one-off project.

This funnel is important because accessibility work can easily stall between identification and implementation.

Reports do not fix issues.

Ownership, prioritisation and delivery workflows do.

The Findings Register Becomes the Operational Source of Truth

A well-structured findings register is one of the most important artefacts in an accessibility program.

It allows accessibility findings to move from observation into action.

A useful findings register should include:

• System or product name
• Page, screen or workflow location
• Issue description
• User impact
• Severity or priority
• WCAG success criterion
• Recommended remediation
• Owner or responsible team
• Status
• Retesting outcome

This makes the register more than a list of defects.

It becomes a planning tool, a remediation tracker, a governance record and a source of insight into recurring accessibility patterns.

RACI Models Reduce Ambiguity

Accessibility often suffers when ownership is unclear.

Is the system owner responsible? The vendor? The product owner? The developer? The QA team? The procurement team? The accessibility specialist?

In practice, the answer is usually shared responsibility.

That is why a RACI model can be useful.

A RACI helps define who is responsible, accountable, consulted and informed across accessibility activities.

For example:

• System owners may be accountable for remediation planning.
• Developers may be responsible for technical fixes.
• Product owners may be responsible for backlog prioritisation.
• Accessibility specialists may be consulted on interpretation and validation.
• Executives may be informed of risk, progress and unresolved barriers.

This reduces confusion and helps accessibility work move through the organisation.

Policies and Standards Set Expectations

Policies and standards serve different purposes.

An accessibility policy explains the organisation’s commitment and establishes accessibility as an organisational expectation.

An accessibility standard defines what teams need to do in practical terms.

For example, a standard may specify WCAG conformance expectations, keyboard accessibility requirements, colour contrast requirements, form validation expectations, document accessibility requirements and testing responsibilities.

Policies create the mandate.

Standards create the delivery requirements.

Both are needed.

Checklists Help Teams Act Earlier

Checklists are useful because they bring accessibility into everyday delivery decisions.

A good checklist does not replace expertise, but it helps teams remember the common failure points.

Accessibility checklists can be used during:

• Project initiation
• Procurement
• UX design
• Content design
• Interface design
• Front-end development
• QA testing
• Release readiness
• Ongoing maintenance

The earlier checklists are used, the more valuable they become.

A checklist used at release may find problems.

A checklist used during design and development can prevent them.

Procurement Requirements Prevent Long-Term Accessibility Debt

Procurement is one of the most important accessibility control points.

Many accessibility problems are locked in before a system is implemented.

If a vendor product, platform or component is inaccessible, the organisation may inherit years of remediation cost and user impact.

Accessibility requirements should be included in procurement documentation, vendor evaluation, product demonstrations, contracts and acceptance criteria.

Procurement teams should ask questions such as:

• Does the product meet WCAG requirements?
• Can the vendor provide accessibility documentation?
• Has the product been tested with assistive technologies?
• Are known accessibility defects documented?
• Can accessibility issues be remediated within the contract?
• Who is responsible for accessibility fixes after implementation?

Selecting accessible technology is usually easier than retrofitting inaccessible technology later.

Training Turns Compliance Into Capability

Training is essential because accessibility cannot depend on one specialist or one audit.

Designers need to understand accessible interaction patterns. Content teams need to write clear and structured content. Developers need to understand semantic HTML, ARIA, keyboard behaviour and focus management. QA teams need to test beyond automated tools. Product owners need to understand prioritisation and risk.

Different roles need different training.

The goal is not to make everyone an accessibility specialist.

The goal is to help each role understand the accessibility decisions they influence.

Accessibility Improves Usability for Everyone

One of the most persistent misconceptions is that accessibility only benefits people with disabilities.

In reality, accessibility improvements often improve the experience for all users.

Clearer content helps everyone. Better contrast helps everyone. Logical page structure helps everyone. Consistent navigation helps everyone. Captions help users in noisy environments. Keyboard accessibility helps power users. Helpful validation messages reduce errors for everyone completing a form.

Accessibility and usability are not competing priorities.

They are closely connected.

A more accessible service is usually a more usable service.

Accessibility Is a Leadership Issue

Accessibility succeeds when it is supported by leadership.

Teams need permission to prioritise accessibility. Product owners need to include it in roadmaps. Delivery teams need time to implement it properly. Procurement teams need requirements to assess it. Vendors need clear expectations. Governance teams need authority to maintain standards.

Without leadership support, accessibility can become optional, inconsistent or reactive.

With leadership support, accessibility becomes part of organisational culture.

That is when meaningful progress happens.

Accessibility Maturity Requires a Capability Stack

One way to think about accessibility maturity is as a capability stack.

Level 1: Findings

Audits, testing, issue identification and WCAG mapping.

Level 2: Remediation

Backlogs, ownership, prioritisation, fixes and retesting.

Level 3: Governance

Policies, standards, RACI models, procurement requirements and reporting.

Level 4: Capability

Training, reusable components, design systems, implementation guidance and delivery checklists.

Level 5: Culture

Leadership support, continuous improvement, accessibility awareness and integration into normal delivery practice.

Many organisations begin at Level 1.

The biggest long-term gains come from moving upward into governance, capability and culture.

The Best Documents Are the Ones Teams Actually Use

Accessibility documentation should be practical, specific and connected to real workflows.

A long policy document that nobody reads will not change delivery behaviour.

A short checklist used at the right moment can prevent dozens of issues.

A clear findings register can drive remediation.

A procurement requirement can prevent an inaccessible platform from being selected.

A system owner briefing can turn abstract risk into concrete action.

The value of an artefact is not its length.

The value is whether it helps the right person make a better decision at the right time.

Final Thoughts

Reviewing more than 243 accessibility issues reinforced a simple idea.

Accessibility is not about achieving perfection.

It is about continuously reducing barriers.

Every improvement makes a digital service easier to use. Every improvement helps more people complete important tasks. Every improvement reduces friction, risk and exclusion.

But the most important lesson was that sustainable accessibility is not created by audits alone.

It is created by building an operating model that helps accessibility move through the organisation: from audit findings to system owners, from technical leads to backlog items, from procurement requirements to vendor expectations, from policies to delivery checklists, from training to everyday practice.

The organisations making the greatest progress are not simply the ones finding the most issues.

They are the ones learning from those issues and building systems to prevent them from returning.

Accessibility is not just a testing activity.

It is governance, delivery, procurement, design, development, training and leadership working together.

That is what turns accessibility from a compliance requirement into an organisational capability.