Digital accessibility: design, test and maintain a compliant, usable service

A page is not accessible simply because a scanner displays a green score. It is accessible when people can perceive the information, navigate, understand, act, correct an error and obtain the same service using their own tools and within their own constraints.

The definition that prevents regulatory misunderstandings

Digital accessibility means making content and services understandable and usable by disabled people, regardless of how they perceive, navigate or interact. It also benefits people facing temporary or situational constraints: an immobilised arm, a screen viewed in bright sunlight, muted audio, a slow connection, cognitive fatigue or an older device.

WCAG 2.2 is a W3C Recommendation organised around Level A, AA and AAA success criteria. In France, RGAA 4.1.2 provides a technical method comprising 106 criteria and tests for evaluating certain digital services. The European Accessibility Act, transposed into national law, has imposed requirements since 28 June 2025 on certain categories of products and services, including parts of e-commerce, banking, transport, telecommunications and media.

The applicable legal scope depends on the organisation’s status, service, size and any exemptions. Each business should obtain a qualified assessment of its obligations; this guide is not legal advice. Even where no legal duty applies, accessibility remains a requirement for usability and quality.

Key figures: complexity is growing faster than capability

WebAIM reports correlations: pages that use more ARIA also contain more errors, although ARIA is not necessarily the cause. More complex pages are more likely both to use ARIA and to contain defects. The sensible response is not to “remove ARIA”, but to favour native HTML and use ARIA correctly where it is needed.

Follow a complete task: nine points where accessibility is won or lost

1. Find the information

Distinct page titles, the correct language, a logical heading hierarchy, main regions and explicit links help people orient themselves. A screen-reader user can navigate by headings rather than reading every word; a person with a cognitive disability benefits from the same visible structure.

“Click here” links and unnamed buttons lose meaning outside their immediate context. WebAIM finds ambiguous links on 15.2% of pages and empty buttons on 30.6%. Write the action or destination, then inspect the computed accessible name in the browser.

Navigation check: Using only the keyboard and the screen reader’s lists of headings and links, a person can understand the structure and reach the main content.

2. Perceive text, media and states

Contrast must be checked on the actual combinations in use: normal or large text, background, hover, disabled, focus and error states. Colour must never carry information on its own. A red border around a field without an accompanying message gives no explanation to a colour-blind or blind person.

An informative image needs alternative text that reflects its function in that context. A decorative image uses an empty alternative. A complex infographic needs a summary and, where appropriate, a detailed description or its underlying data. Video and audio require captions, transcripts or audio description depending on the content and applicable obligations.

Perception check: Without colour, then without images and finally without sound, the essential information and action remain available through an appropriate alternative.

3. Enlarge and adapt

The service must support zoom, reflow and text-spacing adjustments without hiding content or forcing two-dimensional scrolling, except in specific cases. Test at 200% and at a width equivalent to 320 CSS pixels where the applicable criteria require it, using long text and error messages.

Avoid fixed heights, text embedded in images and components whose controls overlap. Users must be able to change font size, line height, and word and letter spacing. RGAA 4.1.2 sets out the conditions for test 10.12 in detail.

Adaptation check: The journey remains readable and operable after zoom and personalisation, in both portrait and landscape unless the orientation is essential.

4. Navigate without a mouse

Every action available with a pointer must also be available from the keyboard. The tab order follows the visual and semantic logic. Focus remains visible, is not hidden behind a banner and returns to the trigger after a modal closes.

Test menus, accordions, carousels, tooltips, date pickers, uploads and pop-ins. Escape closes what it should; no region traps focus. A skip link allows users to bypass repeated content.

Keyboard check: A person can complete the task using Tab, Shift+Tab, Enter, Space, the arrow keys and Escape without becoming trapped or losing context.

5. Understand what is required

Every field has a persistent label. Help, format, required status and purpose are provided before an error occurs whenever that information is needed. Group related fields with fieldset and legend where appropriate.

Reduce cognitive effort: one idea per sentence, familiar words, predictable steps and a summary before commitment. At certain levels, WCAG 2.2 also introduces requirements concerning redundant entry and consistent help.

Comprehension check: Instructions remain understandable outside the visual layout, and users know what information they need before they begin.

6. Correct an error

An error must be identified, described in text and associated with its field. After submission, move focus appropriately or provide an accessible error summary that links to each problem. Preserve valid values; do not punish users by clearing the entire form.

For a legal or financial decision, provide appropriate review, correction and confirmation. Messages should explain how to resolve the issue, not merely state “invalid”.

Error-recovery check: With a screen reader and at high zoom, users are told that an error has occurred, which error it is and how to correct it.

7. Authenticate

Authentication must not impose a cognitive test without an alternative. Allow password managers, copy and paste, and accessible mechanisms; provide recovery that does not depend on a single sense or excessive memory.

CAPTCHAs can create a major barrier. Prefer invisible risk detection, rate limiting, honeypots and server-side controls, then provide a genuinely usable alternative if a challenge remains necessary. Security and accessibility share the objective of reliable access; they should not be treated as inherently opposed.

Acceptance criterion: The journey works with a password manager, keyboard, screen reader and a tested recovery method.

8. Accommodate time, motion and interruptions

Give users control over animation, carousels, autoplay media and flashing content. Respect prefers-reduced-motion. Time limits are announced, adjustable or justified; an expired session should be recoverable without excessive loss.

Important dynamic notifications use a proportionate live region without announcing every change. Content that appears on hover or focus must remain controllable, dismissible and pointer-accessible.

Acceptance criterion: Reduced motion, pause and time extension all work; no essential animation is imposed without an alternative.

9. Obtain the same outcome beyond the digital interface

Accessibility does not end at the “Submit” button. Confirmation emails, PDFs, attachments, customer portals, telephone support and manual procedures all belong to the service. A compliant form that generates an unreadable document still creates a broken experience.

Map every channel and supplier. Third-party content may fall within the compliance scope or require a clear statement and an alternative, depending on the context. Exemptions must not become an experience strategy.

Acceptance criterion: A person can receive, retain, understand and challenge the outcome through an accessible channel.

WebAIM, success criteria and components: read the numbers without manufacturing a score

An overall score attracts attention. It also oversimplifies. It hides blockers, conflates pages and quickly becomes outdated.

Suppose a scanner score rises from 72 to 94 after contrast and alternative-text issues are fixed. That is genuine progress on the rules the scanner detects. Yet modal navigation, focus order, the relevance of alternative text and the ability to correct a payment remain open questions that the score cannot answer.

Governance must therefore retain several levels of evidence. The first monitors automatically detectable defects in shared components. The second measures criteria checked manually across a sample. The third observes task success with relevant people and technologies. The fourth tracks feedback, remediation times and regressions after delivery.

Each level informs a different decision and none replaces the others. Together, they distinguish code improvements, better compliance and an experience that has become genuinely usable—without turning a scanner score into a certificate.

When an indicator improves while a critical task remains impossible with a keyboard or screen reader, the committee should treat the lived barrier as the priority signal, identify the responsible component and retain the overall score only as secondary information about automated rules.

One final safeguard: always publish the scope. A score without its pages, rules, date, tools and limitations is not usable evidence.

The production method: integrate before auditing

Inclusive scoping

Establish the obligations, audiences, critical tasks and assistive technologies. Add accessibility to procurement requirements and acceptance criteria. The budget must cover design, development, content, testing and maintenance.

Research with the people concerned

Include disabled people with a range of needs. The GOV.UK Design System combines tool-based testing, manual testing and inclusive user research. One person does not represent a disability category; recruit profiles that reflect the service.

An accessible design system

Use native components wherever possible, and document keyboard behaviour, focus, accessible names, states, errors, contrast and content. Test the implementation because an accessible design can still be coded in an inaccessible way.

Continuous delivery and control

Add linting and automated tests to pipelines without claiming they provide complete coverage. Manual reviews examine semantics, keyboard behaviour, zoom, screen readers and journeys. Block critical regressions before production.

Audit, then remediate

A formal RGAA audit uses a representative sample, tests the applicable criteria and produces documented findings. Remediation addresses root causes in components, content models or workflows, then a retest confirms the result. The audit should not be the first occasion on which a team learns what an accessible button is.

Tools, tests and what they prove

Cost, timeframe and scope decisions

Cost depends on the number of templates and components, interactive complexity, multimedia content, documents, third parties, debt and the level of evidence required. Fixing a design system and its shared components creates leverage; fixing pages one by one costs more and leaves the root causes intact.

Logiks estimates, not statistical benchmarks: a targeted assessment may take a few days; a formal audit may take several days to several weeks depending on the sample and complexity; substantial remediation often requires several delivery cycles. The schedule should separate the audit, remediation and retest.

Do not promise “100% accessible in two weeks” without an inventory or testing. The required legal level, third-party content, possible exemptions and the accessibility statement must be reviewed by the appropriate specialists.

Logiks recommendations: prioritise without abandoning compliance

1. Fix task blockers first, followed by repeated components and high-volume content.
2. Assign every defect to its source: design, code, content, tool or governance.
3. Add a non-regression rule before correcting the hundredth occurrence.
4. Publish known limitations and provide a contact channel that is genuinely monitored.
5. Measure remediation time, reopened issues and coverage, not only an aggregate score.

Prioritisation organises remediation; it does not turn a failed criterion into a passed one.

30 / 60 / 90-day roadmap

Days 1 to 30: understand the service

• establish obligations and scope with legal counsel;
• inventory pages, templates, components, documents and third parties;
• test three tasks with a keyboard, at high zoom and with a screen reader;
• review support feedback;
• fix critical blockers and appoint an owner.

Days 31 to 60: fix the system

• address contrast, labels, alternatives and structure;
• make navigation, focus, modals and forms reliable;
• document components;
• integrate automated tests and manual reviews;
• train design, content, development and CMS contributor teams.

Days 61 to 90: produce the evidence

• define the sample and conduct the appropriate audit;
• link every gap to a correction and an owner;
• retest;
• update the statement and action plan where applicable;
• establish a review before every major launch.

FAQ

What is the difference between WCAG and RGAA?

WCAG 2.2 is an international W3C standard. RGAA is the French framework that provides a technical method, criteria and tests for evaluating certain services. Legal obligations depend on the applicable framework.

Can an automated tool certify a website?

No. WebAIM emphasises that the absence of detected errors indicates neither accessibility nor compliance. Many criteria require human judgement, keyboard testing, assistive technologies and contextual analysis.

How much does accessibility work cost?

Cost depends on the existing debt, components, interactions, content, documents and third parties. Building accessibility in from the start generally costs less than late remediation. Request separate work packages for assessment/audit, remediation, retesting and governance.

Should an organisation target Level AA?

WCAG defines Levels A, AA and AAA. Frameworks often use A and AA as their reference, but the legally required level depends on the service. The W3C advises against requiring Level AAA for an entire website because some content cannot meet every criterion at that level.

Does the European Accessibility Act apply to every SME?

Not in the same way. It covers certain categories of products and services and provides for specific provisions or exemptions under national law. Obtain a precise assessment of the activity, organisation size, service and relevant contract dates.

What is the difference between making a service accessible and conducting an RGAA audit?

Accessibility work designs and corrects the service. An audit tests criteria across a sample and documents its status. A sound programme does both, then maintains the controls after the retest.

Conclusion

Digital accessibility is a property of the complete service, not a layer added to its interface. It is built into the words, hierarchy, components, code, documents, channels and the way the team accepts delivery.

The regulatory framework makes evidence necessary. Usability makes the work indispensable. Once accessibility becomes part of the production system, it stops being a one-off correction and becomes a maintainable standard of quality.

Main sources

1. WebAIM: The WebAIM Million 2026, February 2026 data.
2. W3C: Web Content Accessibility Guidelines 2.2, W3C Recommendation.
3. W3C WAI: What’s New in WCAG 2.2, accessed 13 July 2026.
4. DINUM: RGAA 4.1.2, accessed 13 July 2026.
5. DINUM: RGAA criteria and tests, accessed 13 July 2026.
6. DGCCRF: European Accessibility Directive, 1 July 2025.
7. GOV.UK Design System: Accessibility strategy, accessed 13 July 2026.
8. GOV.UK Service Manual: Testing for accessibility, accessed 13 July 2026.