RGAA Accessibility: Understanding France's Web Accessibility Standard
This article explains RGAA Accessibility, France's practical checklist for implementing WCAG in public digital services. It gives a step-by-step audit process, common failure points, a simple audit table, and practical advice for prioritising and documenting fixes.
RGAA Accessibility: what it is and why it matters
RGAA Accessibility refers to the French accessibility reference used to check websites and apps against recognised accessibility rules. It is the practical checklist many organisations in France use to implement the Web Content Accessibility Guidelines from the W3C and to meet national accessibility obligations.
How RGAA links to WCAG and French policy
RGAA translates technical WCAG requirements into a national checklist and test method. Public authorities in France use it to demonstrate compliance under national laws and European accessibility requirements. Think of RGAA as a national adaptation and test plan built on the W3C standards.
Who uses RGAA Accessibility?
Typical users include public administrations, agencies that deliver digital public services, suppliers who build public sector sites and mobile apps, and auditors who must produce formal accessibility reports. Private organisations may also use RGAA when they need to align with French contracting rules.
How to run an RGAA audit: step by step
Follow these steps to produce a practical RGAA audit and remediation plan.
- Define scope: list domains, subdomains, templates and mobile apps. Note excluded content and why.
- Gather artifacts: page templates, code samples, CMS access, design files and existing test reports.
- Automated scans: run multiple automated checks to find low-hanging issues such as missing alt attributes and broken headings.
- Manual testing: keyboard navigation, form labelling, focus order, visible focus, and ARIA usage must be checked by hand.
- Assistive technology tests: test with at least one screen reader and keyboard-only. Add mobile screen reader checks for apps.
- Write findings: produce an itemised report using RGAA references and tie each finding to the underlying WCAG success criterion.
- Produce the accessibility statement: include scope, compliance status, contact details and planned fixes.
- Plan remediation and monitoring: prioritise fixes, assign owners, and schedule follow-up audits.
Common RGAA failures to check first
- Low contrast on text and interface components
- Missing or meaningless alternative text for images
- Non-labelled form fields and unclear error messages
- Keyboard traps and inconsistent focus order
- Incorrect or unnecessary use of WAI-ARIA roles that break native semantics
Tools and techniques for practical checks
Use a mix of tools. Automated scanners catch many surface issues. Manual tests reveal semantics problems and real user impact. Include at least one screen reader, a keyboard-only pass, and a contrast checker in every audit.
Suggested test types
- Automated scan across a crawl of key pages
- Template-based manual checks for header, footer, and common components
- Task-based user testing with assistive technology for high-value user journeys
How to document findings: a simple audit table
Track findings in a table that links RGAA items to WCAG and to remediation tasks. The table below is a minimal template to include in reports.
| Item | RGAA reference | WCAG success criterion | Test method | Result | Remediation |
|---|---|---|---|---|---|
| Logo image | RGAA item | WCAG SC | Automated + manual | Fail | Add descriptive alt text or role=“presentation” |
Writing the accessibility statement and roadmap
An accessibility statement should be clear, specific and usable. Key elements are:
- Scope: which sites and apps are covered
- Current compliance status and known major issues
- How users can report barriers and request content
- Timetable for fixes and contact point for complaints
Prioritisation framework for fixes (practical angle)
Organisations often have limited resources. Use a simple impact-versus-effort matrix to order work.
- High impact, low effort: fix first. Examples include missing alt text and incorrect form labels.
- High impact, high effort: plan and budget these, such as redesigning a complex form.
- Low impact, low effort: batch these into regular sprints.
Traceability: link RGAA tests to WCAG
Make a traceability matrix so each RGAA test refers to the matching WCAG success criterion. This creates transparent evidence for auditors and for procurement teams. Track test method, test date, tester name and remediation status for every item.
Common audit mistakes and how to avoid them (information gain)
- Relying only on automated tools. Fix this by adding manual template checks and assistive-technology runs.
- Testing only a homepage. Instead, test representative templates and high-traffic user journeys.
- Using ARIA as a shortcut. Prefer native HTML semantics and only use ARIA where necessary.
Next steps for teams starting with RGAA Accessibility
Start with a scoped pilot audit. Use the audit table above and the prioritisation framework to produce a 90-day roadmap. Keep the accessibility statement alive and set regular audits into the release cycle so accessibility is not a one-off project.
Where to get official guidance
Refer to the official RGAA documentation and the W3C WCAG materials for definitive requirements and test procedures. For legal questions, consult a specialist in French accessibility law.