RGAA audit: the week-by-week process, preparation and how to read the report

An RGAA audit measures, criterion by criterion, how far a website, an app or a software package complies with the RGAA, France’s General Accessibility Improvement Framework (Référentiel général d’amélioration de l’accessibilité). It is the mandatory basis of every accessibility statement in France, and that statement is what Arcom, the French regulator for audiovisual and digital communication, checks during its inspections. Most pages on the subject describe the method; this one shows how an RGAA audit actually unfolds, week by week, what your organisation needs to prepare, how the sample is built, what the deliverables contain and how to read the report without being a digital accessibility specialist.

RGAA audit: what it measures, and what it does not

The RGAA, currently at version 4.1.2, contains 106 criteria grouped into 13 themes: images, frames, colours, multimedia, tables, links, scripts, mandatory elements, information structure, presentation of information, forms, navigation and consultation. Each criterion is broken down into precise tests, which tell the auditor what to check in the code and in the rendered page. In this way the framework turns the requirements of the Web Content Accessibility Guidelines (WCAG) into a grid that allows two competent auditors to reach the same result on the same page. For an international reader, this is the key difference from a generic WCAG review: the RGAA does not leave room for interpretation on how a requirement is tested, which makes results comparable from one audit to the next and from one auditor to another.

An RGAA audit produces three things: a status for each criterion on each page assessed (met, not met or not applicable), a compliance rate for the service as a whole, and a located list of the defects to be fixed. It does not grade visual design, general usability or editorial quality. A website can achieve a good rate and still be tiresome to use for a blind person if the journeys are long and poorly designed; this is why a compliance audit is usefully complemented by testing with users with disabilities.

Nor is the audit a run of an automated tool. Browser extensions pick up some of the technical errors, but they cannot judge whether a text alternative is relevant, whether the reading order makes sense or whether a drop-down menu works with the keyboard. The official page on compliance assessment (in French) describes an assessment carried out criterion by criterion, on a representative sample: it is this assessment, and this assessment alone, that underpins the rate published in the statement. A score displayed by an automated checker, however high, therefore has no standing in a French accessibility statement.

Who needs to commission an RGAA audit

In France, article 47 of the law of 11 February 2005 requires accessibility and the publication of a statement from legal persons governed by public law, from private bodies entrusted with a public service mission or a mission of general interest, under certain conditions, and from companies whose turnover generated in France exceeds €250 million. For these organisations the RGAA audit is not optional: without an actual assessment, the only status the statement can display is “non-compliant”. The scope and the texts are set out on our page digital accessibility in France and in our analysis of French accessibility obligations. For an international group, the turnover test is the point to examine first, because a French subsidiary can fall within article 47 even when the group is headquartered in Luxembourg, Belgium or Switzerland.

A company covered by the European Accessibility Act without reaching that threshold follows a different logic: its obligations derive from the French Consumer Code (code de la consommation), with the European standard EN 301 549 as the technical reference, and they are enforced by the DGCCRF, the French government directorate in charge of consumer protection. An audit based on WCAG and the European standard, such as our compliance audit, answers that need more directly than an RGAA audit in the strict sense, even though the working method is very similar. Our article on the European Accessibility Act explains which services are concerned.

When to carry out an RGAA audit: the seven situations that trigger one

The question is not only whether you need an audit, but when. The RGAA sets deadlines for updating the statement, and each of them assumes a recent audit. Other situations, without being legal obligations, make an audit essential if you want to avoid publishing an incorrect status.

The fourth row deserves to be anticipated. DINUM, the French government’s interministerial digital directorate (Direction interministérielle du numérique), which maintains the RGAA, has announced the publication of RGAA 5, expected at the end of 2026 (in French). It incorporates WCAG 2.2 and will define criteria for mobile apps and office documents. DINUM states that work based on RGAA 4.1.2 must under no circumstances be suspended or postponed: an audit carried out today remains useful, its fixes will remain valid, and the statement that results from it will benefit from the eighteen-month transition period.

For supplier deliveries, the audit takes the form of accessibility acceptance testing: before signing off the delivery, you check that the templates and journeys delivered meet the criteria required by the contract. This is far more effective than discovering the defects during the next compliance audit, when the supplier has already moved on and the budget has been spent.

Preparing for an RGAA audit: the checklist for the organisation being audited

Most audit delays are not caused by the auditors but by access that is missing on the day testing starts: a locked test account, an unavailable staging environment, a payment step that cannot be passed. A few days of preparation save a week. Here is what we ask for, in practice, before the kick-off meeting.

• The exact scope: address of the service, subdomains included or excluded, logged-in areas, mobile apps, downloadable documents;
• the accessibility statement currently in force, the multi-year plan and the action plan, even if they are old, to measure the gap and reuse whatever can be reused;
• audience statistics for the most visited pages, which help make the sample representative;
• the list of templates or page types (article, information sheet, search results, form, dashboard) and of shared components (menu, search engine, carousel, modal windows);
• test accounts for each user profile, with realistic data: an empty account shows neither a dashboard nor a history;
• a way to get through sensitive steps: a test payment card, a strong authentication code sent by a contact who can be reached, a temporary bypass of a captcha in the staging environment;
• the downloadable documents used in online procedures: PDF forms, notices, invoices, minutes;
• the list of modules supplied by third parties (appointment booking, payment, mapping, chatbot) and the name of their vendor;
• a technical contact available during testing, and the date from which changes are frozen: a website that changes during the audit produces inconsistent results;
• the calendar of constraints: planned go-live, inspection deadline, steering committee at which the results must be presented.

Two points are often underestimated. The first is third-party modules: an appointment booking tool bought from a vendor is part of your service, since you chose it and you pay for it. It is audited like everything else, and its defects appear in your statement. The second is the environment: auditing in pre-production is possible and often preferable, provided that this version is identical to the one that will be published and that the statement clearly refers to the live online service.

For organisations working across borders, a third point is worth adding: if the service exists in several language versions, decide at the scoping stage which version is audited. The French version is the one covered by article 47, but a shared template means that a defect found there will usually also exist in the English, German or Dutch versions, and fixing it once in the template benefits all of them.

Building the RGAA audit sample: the official rules and an annotated example

An audit does not cover every page of a website: it covers a sample, and the result applies to the entire service. This is why the composition of the sample is the most important decision in the audit. A convenient sample produces a flattering rate that will not survive the first page an inspector opens at random.

What the method requires

The official method first requires the audit to include, where they exist, the home page, the contact page, the legal notice, the Accessibility page, the site map, the help page and the login page. To these are added at least one relevant page for each type of service, search included, at least one relevant downloadable document for each type of service, every page of a process (a multi-step form or transaction) and pages that look substantially different or contain substantially different content: tables, multimedia, forms. Pages chosen at random must make up at least 10% of the pages in the sample. No total number of pages is set; for a mobile app, each screen is treated as a page.

One rule follows from this construction and changes everything for user journeys: a criterion is only met for a page within a process if it is met for every page of that process. If the third step of an online application contains a field with no label, the criterion concerned is not met across all the steps of the journey. In other words, a single weak step pulls the whole process down, which is exactly what a user relying on a screen reader experiences: if one step blocks them, the application cannot be submitted at all.

Example: the user area of a public body

Take the website of a public body that offers general information and a logged-in area where users submit an application for financial support and follow its progress. A defensible sample might look like this.

This sample contains around twenty pages and screens, including the four steps of the application. It illustrates a reflex worth keeping: every task a user must be able to complete independently (logging in, applying, tracking, downloading) appears at least once. Leaving out the dashboard or the PDF because they are hard to test means removing from the audit precisely what blocks users.

The list of pages audited is then included in the accessibility statement, with their addresses. It becomes public: any user, and Arcom, can check that the sample really does include the processes. Our article on the accessibility statement explains how to present this list and the calculation that follows from it.

How an RGAA audit unfolds, week by week

At our firm, the average time for an audit is three weeks between kick-off and delivery of the report. This varies with the size of the sample, the number of journeys and platforms, and the availability of access. The process below corresponds to a website of ordinary complexity, with a logged-in area.

1. Before kick-off: scoping. A one- or two-hour discussion sets the framework and its version, the scope, the provisional list of pages in the sample, the test environment and the contacts. You send the items on the preparation checklist. The auditor checks the access straight away and flags anything that is missing.
2. Week 1: validating the sample and first tests. The sample is agreed with you, including the pages drawn at random. The auditor starts with the mandatory pages and the shared components (header, menu, footer, search engine): a defect in a common component is repeated on every page, and identifying it early avoids describing it twenty times.
3. Week 2: journeys, forms and assistive technologies. Processes are audited step by step, using the test accounts. Dynamic components (drop-down menus, tabs, modal windows, error messages, content that appears on hover) are checked with screen readers and with the keyboard. Downloadable documents are reviewed. An interim check-in flags any major blocking issues, without waiting for the report.
4. Week 3: consolidation, report and debrief. The results are consolidated at service level, the compliance rate is calculated, and each non-compliance is described with an example and a recommendation. An internal review checks that statuses are consistent from page to page. The debrief presents the results to the business and technical teams, then the report, the grid and the draft statement are handed over.
5. After delivery: fixes and the follow-up audit. Your teams or suppliers make the fixes, following the action plan. A shorter follow-up audit checks the fixes on the same pages, and the statement is updated with the new rate.

Two factors almost always lengthen this schedule: access that is missing when the second-week tests begin, and a production release during the audit. The first is solved by preparation; the second by a freeze on changes or, failing that, by stating in the report the date of the version that was audited.

The interim check-in in week 2 deserves particular attention from project managers. If a blocking defect is found on a payment or authentication step, your teams can begin to analyse it while the audit continues, rather than discovering it three weeks later in the report. On projects with a fixed go-live date, those days often make the difference between fixing before launch and launching with a known defect.

What the auditor actually does: tests, tools and environment

For each page in the sample, the auditor goes through all 106 criteria. A large number are not applicable on a given page (no video, no table, no frame); the others are checked test by test, in the code and in the rendered page. As soon as a single element on the page fails a test, the criterion is not met for that page.

An example: the online application form

On a single step of a form, the auditor checks, among other things, that each field has a label (criterion 11.1) and that buttons have an explicit name (criterion 11.9); that input validation reports errors and required fields in a perceptible way, including to screen readers (criterion 11.10); that scripts that show or hide fields are compatible with assistive technologies (criterion 7.1) and usable with the keyboard (criterion 7.3); that the focus remains visible (criterion 10.7); that the tab order is consistent (criterion 12.8); and that the user is never trapped by the keyboard (criterion 12.9). The auditor measures the contrast of the text (criterion 3.2) and of field borders (criterion 3.3), and checks that information is not conveyed by colour alone, for example a field in error that is simply outlined in red.

This breakdown explains why a single defect can be costly for the rate: an error message that is missing or not properly associated with its field means criterion 11.10 is not met on the page, and therefore across the whole process, and therefore for the service. It also explains why the same poorly designed component, repeated in every form on the website, can be fixed in one go.

Tools and the test environment

The auditor works with the browser’s code inspector, a contrast analyser, checking extensions that speed up the detection of repetitive errors, and systematic keyboard navigation. For dynamic components, the auditor checks how they are rendered by assistive technologies. The RGAA publishes a reference test environment (in French): on desktop, combinations pairing NVDA or JAWS with Firefox, and VoiceOver with Safari; on mobile, TalkBack with Chrome on Android and VoiceOver with Safari on iOS. A component is considered compatible if it works fully with at least one combination; for a consumer-facing website consulted on mobile, the framework recommends testing in both environments.

The combinations used, the tools and their versions are then stated in the report and in the statement. This is a safeguard for you: a result obtained with an undocumented combination would be difficult to reproduce during the follow-up audit.

RGAA audit deliverables: report, grid, action plan and statement

DINUM provides an audit kit (in French) that includes a report template, a statement template and the RGAA 4.1.2 audit grid in spreadsheet format; the same page presents Ara, an online tool that structures the recording of results and generates the report and the statement. Ara is not an automated tool: it assumes an auditor who knows the 106 criteria. A professional audit relies on these templates or follows their structure, which makes it possible to compare two successive audits.

The official audit report template (in French) organises the description of errors by theme. For each non-compliant criterion, it provides for a brief presentation of the criterion, a representative case with a screenshot where necessary, a description of the problem and a technical recommendation. Its conclusion includes an opinion from the auditor, written for a non-technical audience, and a prioritisation of fixes along three lines: essential features and content, criteria that block access, and ease of implementation. The audit grid, in the appendix, gives the results page by page.

Insist that each non-compliance is located (page, component, element) and accompanied by a recommendation a developer can act on. A line such as “criterion 1.1 non-compliant” with no example forces your teams to redo part of the audit to find the defects. For groups whose development teams work in English, it is also worth agreeing at the scoping stage on the language of the recommendations: the statement itself must follow the French format, but the technical findings are only useful if the people who fix them can read them.

Reading an RGAA audit report without being an expert

A fifty-page report can be daunting for a director or an elected official. Yet it can be read in ten minutes if you know where to look, and in what order.

1. The overall compliance rate. This is the ratio between the criteria met and the applicable criteria, calculated across the whole sample: (criteria met ÷ applicable criteria) × 100. A rate of 100% means the service is fully compliant, a rate of at least 50% that it is partially compliant, and below that it is non-compliant. It is this rate, and this rate alone, that appears in the statement.
2. The average rate. This is the average of the rates for each page. It is almost always higher than the overall rate, because an isolated error only affects one page. Useful for tracking progress, it never replaces the overall rate.
3. The number of applicable criteria. A very low number of applicable criteria should raise questions: either the service really is simple, or content has been left out. Criteria can only be justifiably marked as not applicable if the content does not exist, if it is exempt, or if it benefits from a derogation with an accessible alternative.
4. Blocking issues, before the number of defects. Look in the summary for the defects that prevent a task from being completed: logging in, paying, submitting an application, downloading a notice. A contrast defect on a secondary mention and a submit button that cannot be used with the keyboard each count as one criterion, but they do not have the same effect.
5. Shared components. Identify the defects that come from the template, the menu or the component library: fixing them improves every page at once.
6. Content outside your control. Note the defects attributable to a vendor’s module. They are dealt with through the contractual relationship, not by your developers.

Take a sample in which 52 criteria are applicable and 39 are met: the rate is 75%, and the service is partially compliant. If the average rate per page reaches 88%, most of the 13 failing criteria fail on only one or two pages, often within the same journey. The right reading is therefore: a service that is broadly sound, with one journey to be reworked as a priority. The detailed calculation and its pitfalls are covered in our article on the accessibility statement and the compliance rate.

When you present these results to a board or an executive committee, it helps to keep the two readings side by side: the overall rate, which is the figure the law looks at, and the list of blocking issues, which is what users experience. A plan that raises the rate without removing the blocking issues will look good on paper and change little for the people who rely on assistive technologies.

What an Arcom inspection reveals about the quality of an audit

Since 2023, Arcom has monitored compliance with article 47. Its decision No. 2026-358 of 24 June 2026 concerning impots.gouv.fr, the French tax administration’s website (published in the Journal officiel, France’s official gazette (in French)), is instructive for anyone preparing an audit, because the defects it identified concern exactly the kind of content that convenient samples leave out.

• a tax notice in PDF downloadable from the personal area, with no title, no defined language, no tagging and no accessible alternative (criterion 13.3);
• in the secure messaging service, a “Write” section that could not be reached with the Tab key and whose information was not rendered by screen readers (criterion 10.8);
• in the same messaging service, a drop-down menu for choosing the tax year that only appeared with the mouse, and was therefore unusable with the keyboard (criterion 12.11);
• in the online income tax return form (in the section on non-professional furnished lettings), a table whose cells were not associated with their headers (criterion 5.7);
• a service whose statement gave no rate at all, for lack of an audit.

Documents downloaded from a logged-in area, messaging, dynamic selectors, tables within a form: all this content sits behind authentication. An audit limited to public pages does not see it. The authority granted nine months to fix the accessibility defects and two months to bring the accessibility statements into line and publish the action plan for the current year. For the public sector, these requirements fit together with public procurement and the programme management described on our public sector page.

The lesson for a large organisation is straightforward. An inspector does not stop at the home page: the decision shows that the logged-in journeys, the documents users download and the tools they use to correspond with the organisation are examined in detail. If your sample does not include them, your published rate describes a different service from the one an inspector will test.

After the RGAA audit: fixes, follow-up audit and statement

The audit improves nothing on its own; it is the fixes that change users’ lives and the rate. The period after the report is delivered determines the value of the investment.

Publish an accurate status straight away

As soon as the report is delivered, publish the statement that corresponds to the results, even if they are unfavourable, and align the notice on the home page. An accurate “partially compliant” statement fulfils the transparency obligation; waiting until the fixes are finished before publishing means leaving an incorrect status, or no statement at all, online for months.

Fix in the right order

Start with blocking issues on essential journeys, then shared components, and finally isolated defects. Build each fix into the normal development workflow, with an acceptance criterion that reproduces the RGAA test: this is what prevents regression in the next release. When the defects stem from the front-end architecture, support in accessible development avoids fixing page by page what can be solved in the component library.

Follow-up audit and update

The follow-up audit checks the fixes on the pages of the original sample. It is shorter than the audit, but it must be just as rigorous: a criterion fixed on one page but still failing on another remains not met. The new rate is entered in the statement, with the date of the update. Defects that have not been fixed feed into the year’s action plan, which is attached to the multi-year plan.

Train so that it does not happen again

An audit almost always reveals defects linked to working practices: image alternatives written without a method, PDFs exported without tagging, components copied from one project to another. Role-specific training (content editing, design, development, procurement) durably reduces the number of defects at the next audit.

Internal or external RGAA audit: how to choose and compare offers

The official method accepts self-assessment as well as an audit entrusted to a third party, provided it is reliable and representative: the organisation ensures the reliability of its statement by any means, whether an external provider, trained internal experts or cross-audits. Companies covered by paragraph 4° of article 47, those above the turnover threshold, may even use a different testing method, provided it can be communicated on request, is accompanied by a mapping table to the standard and is stated in the accessibility statement. For international groups that already run a WCAG-based testing programme, this is an option worth knowing, as long as the mapping is documented.

An internal audit makes sense if you have auditors trained in the RGAA, who use assistive technologies in practice and who are not the people who designed the website. An external view limits the risk of an overstated rate and provides evidence of independence that is useful in the event of an inspection. Many organisations combine the two: an external audit every three years or at each redesign, and internal checks at each release.

Questions to ask before choosing an auditor

• Does the audit assess all 106 criteria manually, page by page, or does it rely on an automated tool?
• Does the proposed sample include the mandatory pages, complete processes, downloadable documents and at least 10% of pages drawn at random?
• Which assistive technology combinations will be used, and are they stated in the report?
• Do the deliverables include the full grid, a prioritised action plan and the draft statement?
• Is each non-compliance located and accompanied by a recommendation for fixing it?
• Is a follow-up audit included, on what scope and within what timeframe?
• Are the auditors independent of the teams that designed or developed the service?

On budget, there is no reference price: the cost depends on the number of pages and templates, the complexity of the journeys, the number of platforms, the documents to be assessed and the associated services. To compare two quotes, check that they cover the same sample, the same framework and the same deliverables. The simplest approach is to describe your service to us through the contact page: we set out the sample and the timeframe in our proposal, after a scoping discussion.

The errors that distort an RGAA audit

The following errors appear in many reports and in published statements. Each one leads to a rate that does not reflect what users actually experience.

1. Auditing only public pages. Online procedures, logged-in areas and the documents downloaded from them are where blocking issues concentrate.
2. Choosing pages instead of drawing them at random. The rule of 10% random pages exists to reveal overlooked templates.
3. Splitting up a process. Auditing the first and last steps of an application is not enough: every step is part of the sample.
4. Overusing “not applicable”. A criterion is only not applicable if the content does not exist, if it is exempt, or if it benefits from a derogation with an accessible alternative.
5. Confusing a tool score with the compliance rate. An automated score covers only some of the criteria and does not judge relevance.
6. Ignoring third-party modules. A tool that has been bought and integrated is part of the service audited.
7. Auditing a moving target. Without a freeze on changes, the results for a page no longer describe the live version.
8. Not documenting the environment. If the test combinations are not stated, the follow-up audit cannot reproduce the results.
9. Publishing the average rate instead of the overall rate. The compliance status is derived solely from the overall rate.
10. Treating the audit as an end in itself. Without an action plan, fixes and a follow-up audit, the next audit will give the same result.

RGAA audit in Belgium, Luxembourg and Switzerland: what is the equivalent

The RGAA is a French framework. Outside France the working method remains very similar, but the grid changes, and an RGAA audit is not always the best evidence of digital accessibility compliance.

In Luxembourg, RAWeb follows the RGAA’s logic of criteria and tests, adapted to the EN 301 549 standard; mobile apps fall under RAAM, which we apply in our RAAM audit of iOS and Android apps. In Belgium, the reference is the European standard, in all three Regions. In Switzerland, the eCH-0059 standard serves as the reference for public administrations. For a group present in several countries, a pivot framework avoids multiplying audits: our article on digital accessibility standards explains how to choose one, and the articles devoted to Belgium, Luxembourg and Switzerland set out the local obligations.

In practice, the shared foundation makes coordination easier than it first appears. Because all these frameworks rest on WCAG, a defect found on a shared template during an RGAA audit of the French site will usually be a defect under the Belgian, Luxembourg or Swiss reference as well. What differs is the reporting: the French statement follows the RGAA format, while the other countries have their own documents and authorities, which is why each country’s results should be presented in the format its rules require.

Typical timeline: from the decision to audit to the published statement

For a service of ordinary complexity, here is a realistic timeline. It assumes that access is ready at kick-off and that fixes are scheduled as soon as the debrief takes place. It fits into the overall approach described in our guide to digital accessibility.

The time needed for fixes varies much more than the time needed for the audit: a few weeks when the defects are concentrated in a few components, several months when the front-end architecture has to be reworked. If you would like to plan your audit, our RGAA audit page describes the content of the service, and large companies subject to article 47 will find the same deliverables there.

Frequently asked questions