top of page

28 August 2026

Accessibility Audit: What it is, How it works, and What it Covers

An accessibility audit is more than a scan. Here's how one is scoped, which standards apply, what the report should contain, and what it costs to have one done properly.

Introduction

This Privacy Notice aims to clearly and transparently explain which personal data we collect when you visit our website, why we collect it, how we use it, and what Your rights are.

We process your personal data in accordance with Regulation (EU) 2016/679 (GDPR) and applicable national data protection laws. We are committed to ensuring that all processing activities are carried out in accordance with the principles of lawfulness, fairness, transparency, data minimization, integrity, and confidentiality.

Specifically, in this notice you will find information about:

 

  • which data we collect about you and for what purposes;

  • the legal bases on which we process such data;

  • who we may share your data with;

  • how long we retain your data;

  • your rights and how to exercise them.
     

While we sometimes need Your data for example, to respond to your requests or improve our website), we do so with respect, care and only when truly necessary.

Our Privacy Promises

 

  • We deeply value your privacy, and for this reason, we guarantee that:

  • We treat your data as if it were our own.

  • We use your data only for the purposes outlined in this notice.

  • We retain your data only for as long as strictly necessary.

  • We do not share your data with third parties without a valid legal basis or your explicit consent.
     

1. Who Processes Your Personal Data

The Data Controller — that is, the entity that determines the purposes and means of the processing of Your personal data — is AccessiWay S.a.S., with registered office at 7 Rue du Général Henrion Bertier, 92200 Neuilly-sur-Sein registered with the Nanterre Trade and Companies Register under number 914 022 595.

AccessiWay is part of the team.blue group and, in certain cases, acts as joint controller together with team.blue NV, with registered office at Skaldenstraat 121, 9042 Ghent, Belgium. In this context, Your personal data may be shared within the group for statistical, administrative, operational, and service improvement purposes.

AccessiWay and team.blue have defined their respective roles and responsibilities under a joint controllership agreement pursuant to Article 26 of the GDPR, ensuring full compliance with data protection regulations.

For more information regarding joint controllership or to exercise Your rights, you may contact AccessiWay via email at the following email addresses:

📧 legal.fr@accessiway.com or info@accessiway.com.

2. Who This Privacy Notice Applies To

This notice applies to:

 

  • users who browse the website www.accessiway.com,

  • individuals who contact us through the form available on the website or via email;

  • users who interact with tools we have implemented (e.g. widgets, cookies);

  • individuals who, through the website or other channels, access external platforms or third-party entities through which they may submit a job application (e.g. recruiting portals or employment agencies).

  • In such cases, the privacy notices of the third parties involved — independent from AccessiWay — also apply.
     

3. What Data We Process

To manage your interaction with our website, we may process the following categories of personal data:

 

  • Identification and contact details such as name, surname, company, job title, email address, and phone number.

  • These data may be partially processed through our customer relationship management (CRM) system.

  • Data relating to your interaction with our services such as information collected via the website or through Hubspot, such as communication history, preferences, requests, and commercial or technical notes.

  • Technical data such as IP address, device type, operating system, browser, access times, and other data automatically recorded by our systems or servers.

  • Browsing data and preferences such as collected via cookies or similar technologies, in accordance with the choices expressed through the cookie consent banner.

  • Application data such as personal information included in your CV or other documents submitted through third-party platforms (e.g. professional experience, education, contact details).

  • These data are processed by AccessiWay only after being transmitted by the third party, which remains autonomous in the initial processing.
     

4. Purposes and Legal Basis of Processing

We process Your personal data in compliance with Regulation (EU) 2016/679 (GDPR) and applicable national data protection laws. Your data may be processed for the following purposes:

 

  • Technical operation of the website
     

We process technical data, using technical cookies and similar tools, to allow You to access the site, view it correctly, and ensure it functions properly (e.g. browsing, content loading, storing preferences).

📌Legal basis: this processing is necessary to provide a service requested by the user, pursuant to Article 6(1)(b) of the GDPR. Your consent is not required for these cookies.

 

  • Handling contact or support requests
     

When you send us a request — via the contact form or by email — we process your data to respond and provide the information requested.

📌 Legal basis: this processing is necessary to take steps at your request prior to entering into a contract, pursuant to Article 6(1)(b) of the GDPR.

 

  • Compliance with legal obligations
     

In certain cases, we may need to process your data to comply with legal obligations, such as tax, accounting, or IT security requirements.

📌 Legal basis: this processing is based on compliance with a legal obligation, pursuant to Article 6(1)(c) of the GDPR.

  • Statistical analysis and website improvement
     

We use analytical tools (e.g. analytical cookies) to collect aggregated data in order to understand how the website is used and to improve its content and functionality.

📌 Legal basis: we process this data only with your freely given and specific consent, pursuant to Article 6(1)(a) of the GDPR.

  • Marketing and Profiling
     

If you authorize us to do so, we may use your data to send you promotional communications or provide personalized content (e.g. through profiling cookies).

📌 Legal basis: this processing is carried out only with your explicit consent, pursuant to Article 6(1)(a) of the GDPR. You may withdraw your consent at any time without affecting the lawfulness of processing based on consent before its withdrawal.

 

  • Management of job applications through third parties
     

We may receive job applications via third-party platforms (e.g. job portals) or through recruitment agencies. In such cases, we process the submitted data to assess your suitability for the proposed role.

📌 Legal basis: this processing is necessary to take steps at your request prior to entering into a contract, pursuant to Article 6(1)(b) of the GDPR.

Note: the privacy policies of the third-party platforms or agencies involved also apply, independently of AccessiWay.

5. Cookies and Tracking Tools

This website uses a cookie management system provided by iubenda, which allows you to:

 

  • view a full and transparent list of the cookies in use;

  • modify or withdraw your consent at any time;

  • access the complete Cookie Policy, integrated in the cookie widget.
     

You can manage your preferences by clicking on the cookie widget icon located at the bottom left corner of every page on the site.

Technical cookies are necessary and therefore enabled by default. Other non-essential cookies (analytical, profiling) are only enabled with your consent.

For more information, please refer to the full Cookie Policy accessible from the cookie widget.

6. Use of accessWidget

This website integrates accessWidget, an automated accessibility tool developed by accessiBe Ltd. and distributed by AccessiWay. The widget allows users to personalize their browsing experience based on their needs.

When the user activates the widget, their IP address is technically transmitted, but:

 

  • it is not stored, tracked, or associated with identifiable individuals;

  • it is anonymized via a proxy located in the European Union;

  • it is not used for profiling or marketing purposes.
     

📌 Legal basis: provision of a service requested by the user (Article 6(1)(b) of the GDPR).

7. Data Security

We adopt appropriate technical and organizational measures to ensure the security, integrity, and confidentiality of the personal data we process. These measures are designed to prevent unauthorized access, loss, disclosure, or alteration of your data. In particular, we implement:

 

  • secure connections via HTTPS (SSL/TLS);

  • authentication systems and access control;

  • access limitation and internal access tracking mechanisms;

  • regular audits and verification procedures;

  • continuous updates to systems and security measures according to the level of risk.
     

8. Data Retention

Your personal data is stored only for the time strictly necessary to achieve the purposes for which it was collected. Specifically:

 

  • Contact data: up to 10 years if relevant for contractual or legal purposes;

  • Technical and browsing data: according to what is outlined in the Cookie Policy;

  • Marketing data: until consent is withdrawn.
     

9. Your Rights (Data Subject Rights)

As a data subject, you may exercise the rights provided under Articles 15–22 of the GDPR at any time. In particular, you have the right to:

 

  • Obtain confirmation as to whether or not your personal data is being processed and access such data (right of access);

  • Request the rectification of inaccurate personal data or the completion of incomplete data (right to rectification);

  • Request the erasure of your data, if the conditions set out in the GDPR are met (right to erasure);

  • Obtain restriction of processing where applicable (right to restriction);

  • Object to the processing of your data, in whole or in part, under certain circumstances (right to object);

  • Receive your data in a structured, commonly used, and machine-readable format, and, where technically feasible, have it transmitted directly to another controller (right to data portability);

  • Withdraw your consent at any time, without affecting the lawfulness of processing based on consent before its withdrawal.
     

📧 You can exercise Your rights at any time by contacting us at: legal.fr@accessiway.com.

🔗 If you are located in France and believe that the processing of your personal data violates applicable law, you have the right to lodge a complaint with the French Data Protection Authority (Commission Nationale de l’Informatique et des Libertés – CNIL) via the website: www.cnil.fr.

*If you have difficulty accessing our form, please feel free to contact us. Send an e-mail to info@accessiway.com

An accessibility audit is a structured evaluation of a website, app, portal, document, or other digital experience against agreed accessibility criteria. It combines automated checks with expert manual assessment, assistive-technology testing, and, where in scope, testing informed by lived experience. What you get back is a prioritized set of findings with practical recommendations.

In this article

How does an accessibility audit work?

A strong audit uses complementary methods, because no single one finds every barrier or tells you whether an experience works in practice. That’s what Accessiway does as well.

Method

Particularly useful for

Important limitation

Automated testing

Some missing labels, low contrast, structural barriers, and repeatable checks.

It can’t reliably decide whether content is meaningful, understandable, or usable in a task.

Expert manual testing

Assessing content, components, code, and interactions against agreed criteria.

It depends on a well-defined scope, suitable environments, and specialist judgment.

Assistive-technology testing

Keyboard navigation, focus behavior, screen-reader output, and interaction with relevant tools.

One tool or environment can’t represent every user configuration.

Testing informed by lived experience

Identifying barriers people meet in practice and where tasks break down.

It complements standards-based evaluation, and no individual represents every access need.

The proportions are worth knowing before you plan a program around a scanner. Automated testing identified 57.38% of accessibility barriers in Deque’s Automated Accessibility Coverage Report, measured across more than 13,000 pages and page states and nearly 300,000 findings. That’s a useful head start, and it leaves the harder half to people. We’ve covered where manual and automated testing each earn their place in more detail.

A typical audit follows five steps.

Step 1: Prepare the scope and test environments

Confirm the sample, the criteria, the browser and assistive-technology combinations, the test accounts, and the data. Anything left unresolved here turns into a caveat in the final report.

Step 2: Explore the product and run automated checks

Scanners map the territory and flag repeatable failures fast. An auditor reviews every result by hand, because tools miss barriers and flag things that aren’t barriers at all.

Step 3: Assess content, components, and journeys manually

Auditors work through the sample against each applicable criterion, covering the interaction states that automated checks never reach.

Step 4: Test keyboard and assistive-technology behavior

Run the keyboard pass, then test with the agreed screen readers. Behavior differs between tools and between platforms, so the environments you settled in Step 1 shape what this stage finds.

Step 5: Record findings so teams can act on them

Findings go into a format your delivery team can work from, which is what the next section covers.

Why conduct an accessibility audit?

An audit gives your team evidence instead of an ambition: a list of barriers, ranked, with a fix direction for each.

Fix a barrier in a shared component and you’ve improved every page that uses it.

The value runs past compliance. Semantic structure, meaningful link text, alt text, and captions are the same signals search engines read, so accessibility and organic performance move together. It also shapes how people see you. Apple has spent two decades treating accessibility as a product standard rather than a feature request, and that reputation is now part of what the brand is worth.

The people who benefit are a wider group than most teams expect. Alongside people with disabilities, an accessible journey works better for older users, for people with low digital literacy, and for anyone dealing with a situational limit: bright sunlight, a noisy train, a borrowed device, one hand free or ADHD. Designing for those conditions means designing for everyone.

When should you conduct an accessibility audit?

A baseline audit is a good starting point for any accessibility program, and it’s especially valuable before a redesign, a platform migration, a product launch, a major release, a procurement process, or a market expansion.

Prioritize an audit when you’re:

  • Introducing or significantly changing a high-value journey, such as checkout, login, booking, application, payment, consent, or support.

  • Receiving accessibility feedback from customers, employees, or support teams.

  • Adding a third-party service that affects an important journey.

  • Preparing to meet a relevant accessibility, procurement, or market requirement.

How do you prepare for an accessibility audit?

Start by agreeing what the assessment is for. You might want a baseline, a better conversion journey, support for a redesign, readiness for procurement, or a view of where you stand against applicable requirements. That purpose sets the criteria, the platforms, the journeys, and the depth of testing.

Before testing begins, identify:

  • The digital assets in scope, including public websites, portals, web and mobile apps, documents, media, forms, and third-party tools.

  • The user journeys that matter most and the teams responsible for them.

  • Test accounts, realistic test data, and suitable environments.

  • The devices and assistive technologies most relevant to your users.

  • Third-party touchpoints, such as payment, booking, chat, consent, and video services.

Two of these deserve attention early.

Third-party services

They can create barriers inside an otherwise accessible journey, and they’re usually the barriers you can’t fix yourself.

Post-login areas

Account management, document access, and self-service tend to live behind authentication, and including them changes the size of an audit more than anything else on the list. Settle this before anyone quotes you a price.

How is an accessibility audit scoped?

An audit’s scope covers representative templates, reusable components, priority journeys, relevant content types, and meaningful interaction states.

Reviewing a form without its validation, error, confirmation, and time-out states shows you only the part that already works. A navigation component needs assessing the way people actually use it, including with keyboard focus and relevant assistive technologies.

The World Wide Web Consortium (W3C) publishes a repeatable framework for this, the Website Accessibility Conformance Evaluation Methodology (WCAG-EM): define the scope, explore the target, select a representative sample, evaluate it, and report the findings. Auditors still tailor the approach to the product and to what the audit is for.

Scope area

What may be included

Digital assets

Websites, portals, web and mobile apps, documents, media, and other agreed products.

Reusable elements

Templates, navigation, forms, dialogs, search, alerts, tables, and design-system components.

User journeys

Registration, login, search, booking, application, payment, document access, and support.

Content and states

Text, images, charts, documents, media, errors, success messages, pop-ups, and dynamic updates.

Environments

Agreed browser, device, operating-system, and assistive-technology combinations.

Third parties

Embedded or vendor-provided services that affect an in-scope journey.

What does an accessibility audit test?

An audit assesses whether an in-scope experience meets the agreed criteria and works for people with different access needs. The categories below show common areas of investigation, and they illustrate a test plan without replacing one. If you’re new to the underlying criteria, our guide to what makes a website accessible covers them at a slower pace.

Coverage area

Illustrative checks

Structure and content

Heading hierarchy, page titles, language, semantic structure, meaningful links, labels, text alternatives, and clear instructions.

Visual presentation

Color contrast, non-color cues, text resizing, reflow, responsive behavior, and visible focus.

Interaction and forms

Keyboard access, focus order, control names and states, form labels, validation, error messages, dialogs, and time limits.

Media and documents

Captions, transcripts, audio description where relevant, accessible documents, and access to information in images or charts.

Assistive technology

Whether controls, structure, and dynamic updates reach screen readers and other relevant tools in a useful form.

Task completion

Whether people can complete a priority journey from start to finish, including error recovery and confirmation.

Accessibility audit vs. automated scan vs. user testing

These three activities are related, and they answer different questions.

Activity

Main question

Primary outcome

Automated scan

What machine-detectable barriers can this tool flag?

Tool results that need human review, context, and prioritization.

Accessibility audit

Does the agreed scope meet defined accessibility criteria?

Evidence-based findings, relevant criteria, priorities, and remediation guidance.

User testing

Can people complete real tasks, and where do they meet barriers?

Observations about task completion, usability, and barriers experienced in practice.

An automated scan is a useful input to an audit. User testing adds experiential insight that standards-based evaluation can’t produce on its own, and it belongs alongside that evaluation.

Which standards and legal requirements are relevant?

Agree the benchmark before testing begins. WCAG, EN 301 549, and the EAA are connected, and they aren’t interchangeable.

The Web Content Accessibility Guidelines (WCAG) is the international technical standard. It organizes around four principles, known as POUR: perceivable, operable, understandable, and robust. Success criteria sit at levels A, AA, and AAA, with AA the working benchmark for most organizations. WCAG 2.2 is the current version and stays backward compatible with 2.1.

EN 301 549 is the European standard for accessibility requirements in information and communication technology (ICT) products and services. It draws heavily on WCAG and includes requirements beyond a WCAG-only assessment, so WCAG conformance shouldn’t be presented as automatically equivalent to meeting every relevant EN 301 549 requirement.

The EAA is EU legislation, and it isn’t a technical test checklist. The obligations that apply and the technical routes available depend on the product, the service, the market, and national implementation.

Context

Practical audit implication

International digital products

Agree the WCAG version and conformance level that fit your objectives, your users, and your context.

EU products or services in scope

Consider relevant EAA obligations, national implementation, and the applicable EN 301 549 context alongside WCAG.

US state and local government entities

The Department of Justice’s ADA Title II rule uses WCAG 2.1 Level AA for covered web content and mobile apps. As of 27 August 2026, deadlines are 26 April 2027 for entities with a total population of 50,000 or more, and 26 April 2028 for smaller entities and special districts.

Other markets and sectors

Confirm the relevant legal and technical framework with qualified local advice where needed.

Note: This article provides general information, not legal advice. Requirements depend on the organization, the offering, the jurisdiction, and the circumstances.

What should an accessibility audit report include?

It should help decision-makers see the overall picture and help delivery teams act on specific barriers.

Each finding should include:

  • The barrier and the affected page, screen, component, or journey.

  • The relevant criterion and reproducible evidence or context.

  • The likely user impact and the priority assigned to it.

  • Practical remediation direction a developer can act on.

An executive summary should pull out the material themes, risks, and next steps. Prioritization weighs user impact against journey criticality: a blocking barrier in ecommerce checkout or account access may need urgent attention even when it appears on a single screen, while a component-level barrier can affect an entire product.

What happens after the accessibility audit?

The report starts the improvement cycle. Three things follow.

Fix at source

Agree on owners and priorities, then work through the barriers that stop people completing important journeys. Where a barrier comes from a shared template, component, or design-system pattern, fixing it there improves several experiences at once.

Validate every change

Re-test each fix in the environment and journey where it was found. That confirms the barrier is resolved and that the change hasn’t introduced a new focus, announcement, layout, or interaction barrier.

Close the gap between audits

A formal audit is a snapshot. Between them, build accessibility into everyday work:

  • Design reviews

  • Developer guidance

  • Quality-assurance checks

  • Ongoing monitoring

  • Accessible publishing practices

Our guide to making a website accessible, from audit to fixes covers that side in more depth.

How Accessiway can help

An audit happens, a report arrives, findings get exported to a spreadsheet, and months later the cycle repeats while risk builds up in between. Our digital accessibility platform is built to end that cycle.

Our specialists define the platforms, templates, and user journeys in scope, then combine automated testing with manual assessment, keyboard and screen-reader testing, and testing informed by lived experience. The findings land on a live dashboard instead of a static PDF, prioritized by severity, referenced to the relevant guidelines, and connected to your development team’s existing workflow through our Jira integration. Continuous monitoring tracks what changes between audits. You always know where your accessibility stands, and your team has a structured way to act on it. As next steps Accessiway can train your team and help you to be independent in the long run.

Frequently asked questions about accessibility audits

How much does an accessibility audit cost?

Cost tracks the scope you agree. The variables that move it most are the number of instances (each domain or subdomain audited as an independent unit), the number of templates and priority journeys, whether there’s a post-login area, how many languages you ship, how many environments you cover, and which deliverables you need.

At Accessiway the audit sits inside a platform plan rather than being sold on its own, and annual plans start from €1,000 a year. Every tier includes an expert manual audit and an accessibility statement with a Voluntary Product Accessibility Template (VPAT).

  • Bronze covers a basic audit against WCAG 2.2 AA, with the platform and multilingual dashboard.

  • Silver adds a comprehensive expert audit against WCAG 2.2 AA and RGAA, a WCAG 2.2 AA and EAA report, weekly automated scans, remediation guidance, an accessibility badge, and two expert review hours a month.

  • Gold moves scans to daily, adds retesting after every remediation, raises review hours to eight, and brings governance across sites and touchpoints with a quarterly compliance review.

  • Enterprise is scoped to your digital ecosystem.

Specialist work is priced separately at every tier, with usability testing involving people with disabilities from €1,200 a session and document remediation from €5 a page.

How long does an accessibility audit take?

Timing depends on the agreed scope: the number of platforms, templates, components, journeys, content types, languages, and environments. A well-defined scope tells you more than a generic time estimate, and the scoping call is where that gets settled.

Which tools do accessibility auditors use?

Auditors combine scanners, assistive technology, and inspection tools. Common automated tools include axe DevTools, WAVE, Lighthouse, and Accessibility Insights for Web. Manual testing uses screen readers such as NVDA, JAWS, VoiceOver, and TalkBack, alongside contrast checkers and browser developer tools. Document work uses Adobe Acrobat Pro and PAC.

Can an in-house team conduct an accessibility audit?

Yes. Internal teams can and should build accessibility checks into everyday delivery. A specialist-led assessment adds focused expertise, an independent perspective, and structured testing across an agreed scope, which is usually what procurement and conformance documentation ask for.

Does an automated scan prove that a website is accessible?

No. Automated tools find some barriers efficiently, and they can’t assess every requirement or judge whether a task is understandable and usable. Combine them with manual and assistive-technology testing.

Does an accessibility audit guarantee legal compliance?

No. An audit assesses an agreed scope against agreed criteria and provides remediation guidance. Legal obligations depend on the jurisdiction, the sector, the product, and the circumstances.

Does an accessibility audit include PDFs, video, and third-party services?

It can, and inclusion depends on the agreed scope. Identify these assets during preparation, because they’re often essential to a user journey and each needs its own assessment approach. Auditors evaluate PDFs against PDF/UA as well as WCAG.

Do mobile apps need a separate accessibility audit?

Native mobile apps need their own evaluation, and a responsive website viewed on a phone stays part of the web audit. WCAG is scoped to web content, so auditors assess native apps through WCAG2ICT or through EN 301 549 Chapter 11, which adapts the same criteria to software. The testing doesn’t transfer either: mobile screen readers use gesture navigation instead of tab order, platform accessibility APIs differ from the web, and keyboard testing needs an external keyboard connected to the device.

What is screen-reader testing?

Screen-reader testing examines how people who use screen readers receive and interact with digital content. It checks whether controls have meaningful names, whether the structure is clear, and whether dynamic updates are announced usefully.

You can start with a free accessibility scan for an initial view of where your site stands.

Editorial Board

New digital accessibility statistics from a 6,599-person survey across five European countries reveal why 68% of users abandon a purchase.

Digital Accessibility

Editorial Board

Social media managers think about everything: is the tone of voice right? Does the image represent my brand? Who is my ICP?. Yet social media accessibility is still a major marketing gap.

Digital Accessibility

Author

An accessible video lets anyone follow it, regardless of disability. That means accurate captions and transcripts, clear audio description, and enough contrast between text and background.

Digital Accessibility

Related Articles

bottom of page