Accessibility and Disability – Steps Towards a Compliant Digital Product

According to the World Bank, over a billion people worldwide—about 15% of the global population—live with some form of disability. Many face challenges when using websites or mobile apps, often due to inadequate digital accessibility.

An accessible interface ensures that all users, regardless of disability, can easily interact with your digital services and content. To achieve this, product teams must implement key steps that integrate accessibility into the design process. At onepoint, accessibility is a fundamental part of how we craft inclusive digital experiences.

As Anna Cook highlighted at the 2021 Figma Config conference, ” Accessibility is a form of inclusive design that focuses on users with disabilities. It has been proven to enhance experiences for all users and drive innovation in product design.”

You might be thinking about digital accessibility but aren’t sure where to start, or even what it truly means. What matters is recognising that both your product and organisation need to take action.

With a few simple steps, you can start by auditing accessibility and measuring whether it’s considered in your product. In this article, we break down the implementation of accessibility in your product into four steps:

·       Awareness

·       Assessment

·       Strategy

·       Implementation

These phases aren’t set in stone—they can be adapted depending on how mature your product is in terms of accessibility.

What is Digital Accessibility?

Product teams often design, build, and launch digital products based on user experiences, but they don’t always consider the entire audience. This can unintentionally exclude people with disabilities—around 12 million in France alone. That’s why integrating digital accessibility into product development isn’t just beneficial—it’s essential.

Since 2012, all public websites must comply with accessibility regulations, ensuring they meet the full set of RGAA criteria. This means your web product must include an accessibility statement, a multi-year accessibility plan, and a visible indicator of its accessibility status.

According to WebAIM, “97.4% of homepages contain detectable accessibility issues (WCAG 2), a slight improvement from 98.1% in February 2020”.

Creating an accessible digital product means making web services usable for people with disabilities. This involves:

·       Perceptibility – Ensuring content can be perceived both visually and audibly, such as by providing text alternatives and presenting content in multiple formats without losing structure or meaning (e.g., a simplified layout)

·       Usability – Helping users navigate, locate content easily, and giving them enough time to interact with it (e.g., ensuring interface elements are keyboard-accessible)

·       Understandability – Making pages function predictably and supporting users in correcting input errors (e.g., auto-completing form fields).

·       Robustness – Ensuring compatibility with current and future technologies, including assistive tools (e.g., enabling screen reader functionality).

In summary, accessibility isn’t just about ticking compliance boxes—it’s about designing products that work for all users.

 

Step 1: Building Awareness of Digital Accessibility

Educating key stakeholders on accessibility is essential. When digital products are designed with accessibility in mind, they foster social inclusion for people with disabilities.

The first priority is training—helping teams understand the human, legal, and technical aspects of accessibility. At onepoint, we provide regular accessibility training, covering:

·       The needs and tools used by people with disabilities.

·       The legal framework and methodologies that improve accessibility and enhance usability.

Beyond initial awareness, accessibility should be integrated into product development. Appointing an accessibility lead within each team or organisation can help maintain focus.

 

Step 2: Identifying Scope and Legal Obligations

Once the product team is aligned on accessibility, it’s important to ask the following questions to identify the actions, roles, and areas impacted by compliance

Does my organisation need to comply?

Accessibility requirements apply to:

·       Public sector organisations (government departments, local councils, etc.).

·       Organisations and companies with a public service mission (public transport, energy, etc.).

·       Not-for-profit organisations of public interest (e.g., tourism offices).

·       Private companies with annual revenue exceeding €250 million.

 

What parts of my product need to be accessible?

The following must be accessible to people with disabilities:

·       Websites, intranet, and extranet platforms

·       Mobile apps

·       Web-based softwares

·       Digital public infrastructure

Some exemptions apply (e.g., live videos, third-party content).

 

What are the compliance requirements?

Your product must meet RGAA 4.1 standards and include:

·       An accessibility statement

·       A compliance status: non-compliant (<50%), partially compliant (>50%), or fully compliant (100%)

·       A multi-year accessibility plan

Non-compliance may result in fines of up to €20,000 per site.

 

Step 3: Reviewing Design and Conducting Audits

Before running an accessibility audit, review your product’s technical specifications, functional design, and UI components to integrate accessibility considerations.

 

Basic Accessibility Checks

Simple checks can help identify accessibility issues early. Key areas include:

Page Titles

Page titles are essential for easy navigation between open pages in a browser. They are the first element that screen readers announce when the user switches to a new page.

·       The page title accurately and concisely describes the content.

·       The title is unique across the site and effectively differentiates the page from others.

There is some flexibility in defining a correct page title. The best practice is to start with the most important and unique identifying information.

Alternative Text (Alt Text)

From a technical perspective, alternative text (alt text) conveys the purpose of an image or icon. Alt text is essential for users who cannot see images, such as blind individuals using screen readers, as it allows them to hear a description of the image through these tags. Alt text is not typically visible on a webpage; it is embedded in the webpage’s code in the following format:
<img src=”image.png” alt=”alternative text”>.

To go further, the Wave tool can help detect missing alt tags as part of its overall accessibility audit for your webpage.

Checks:
·       If an image provides useful information for interacting with or understanding the webpage content, it must have alternative text.

·       If an image is purely decorative and does not convey essential information, it should have a null alt attribute (alt=””).

Using appropriate alternative text is not an exact science. The image description should be functional rather than a literal depiction of the image. It is up to you to decide whether to provide a detailed description or a more concise one.

Heading Hierarchy

Web pages often contain sections separated by visual headings. To ensure accessibility, these headings must be tagged properly in the HTML source code using <h1>, <h2>, <h3>, etc. This allows all users, including those navigating with a keyboard or screen reader, to easily move between sections.

Checks:
·       Text that appears as a heading is correctly marked with the appropriate heading tag.

·       The page should ideally begin with an <h1> tag, which usually matches the page title.

Heading levels should follow a hierarchy using <h1>, <h2>, <h3>, and <h4> tags. These tags provide instructions to different browsers on how to generate an outline from the headings of a page.

Contrast Ratio

Some users cannot read content if the contrast between the text and background is insufficient (e.g., light text on a light background). This includes many older adults who experience reduced contrast sensitivity.

While some individuals require high contrast, others, such as people with reading disorders like dyslexia, may struggle with highly bright colors and need lower luminance.

Your product should ensure accessibility by allowing users to navigate your site without issues, following WCAG 2.1 standards. Color Contrast Checker tool can help test the contrast of your chosen colors.

Checks:

·       Small text under 24px (or bold text under 19px) must meet a minimum contrast ratio of 4.5:1.

·       Larger text over 24px (or bold text over 19px) must meet a minimum contrast ratio of 3:1.

Unfortunately, your users do not perceive colors in the same way, as some have different conditions (visual impairments, color blindness, dyslexia, etc.). This is why paying attention to the accessibility of your products, websites, and services is essential.

Keyboard Access and Focus

Many users rely on the keyboard to interact with the web. Some use the keyboard directly, while others depend on assistive technologies that rely on keyboard commands. An accessible web product ensures that users can access all content and functionalities (links, forms, controls, etc.) using only a keyboard.

Checks:

·       Tab Navigation: Verify that all elements, such as links, form fields, buttons, and media controls, are accessible via tabbing. Ensure the tab order follows a logical reading flow.

·       Visual Focus: Ensure the focus is clearly visible when navigating between elements, so users can easily identify which element is selected.

Keyboard navigation should be clearly visible and follow a logical order across the page elements. The focus can be highlighted with a border or background colour, visually moving as you navigate through the page, as shown in the example below.

Multimedia Alternatives

Information in videos and audio content is often inaccessible to individuals with disabilities. The solution is to provide alternative formats, such as subtitles, text transcripts, or descriptive audio.

Checks:

·       Control of Auto-play: It is preferable that sound or video does not start automatically when a web page is opened.

·       Accessible Subtitles: Videos on your product should have subtitles that can be toggled on or off. They should not be automatically generated, as this is insufficient for accessibility.

The best practice is to provide both subtitles and textual or audio transcripts, even if not always required. Transcripts offer numerous benefits, both for people with disabilities and for general users of your product.

ARIA (Accessible Rich Internet Applications)

To go even further in terms of technique, the ARIA (Accessible Rich Internet Applications) standard is a specification that provides ways to help make dynamic content accessible, especially for assistive technologies. These attributes should not duplicate alt attributes. They consist of a number of HTML attributes that typically begin with aria-. To go further, the tool A11yproject can help you trace whether your site needs to use these attributes.

Checks:

·       If a dynamic element on your website requires an alternative textual description to assist with understanding via non-visible text, you should define the aria-label=”My label” attribute.

·       ARIA attributes assist only screen reader users in better understanding the dynamic information on your web page.

It is essential to understand that your product might appear to pass these basic accessibility steps, yet significant barriers to accessibility may still exist. Once these steps are validated, a more thorough audit with experts is necessary to evaluate accessibility in greater depth, using a more detailed checklist and various tools (such as Axe, Wave, Web Developer, etc.).

 

Audit of Your Product

Once these steps are completed, it is necessary, in collaboration with an accessibility expert, to define the audit and select the pages for obtaining your accessibility certificate.

·       Internal Audit: Conducted by a quality service not involved in the development of the site (preparation, regular monitoring, updating the compliance statement, etc.).

·       External Audit by Independent Third Party: Performed by a specialised provider (expert support, qualification, certification, etc.).

A RGAA 4.1 accessibility audit is based on digital accessibility rules defined by the World Wide Web Consortium (W3C), as part of the WAI (Web Accessibility Initiative). The goal of WCAG 2.1 is to provide equal access to your product for people with disabilities.

 

Representation of Accessibility Standards:

The Web Content Accessibility Guidelines (WCAG) are technical recommendations that are translated into success criteria to meet compliance requirements. These are divided into three levels:

·       Level A: The basic A-level ensures access to information and basic usability: 80% of criteria. The site offers overall access to the information contained within web documents for an acceptable level of accessibility.

·       Level AA: The double A level contains improvements and supports specific contexts. The site’s accessibility is improved, optimized, and access to the information it contains is greatly facilitated.

·       Level AAA: The triple-A level cannot be applied to all types of content and situations. The site’s accessibility is excellent, and the browsing comfort is optimal for all site users.

In addition, it may be worthwhile to use dedicated tools to automate certain tasks in an accessibility audit, such as LEIYA, developed by onepoint and its teams in Bordeaux.

Fourth Step: Publication of Mandatory Elements

Once the accessibility audit and compliance are completed, you will need to publish three mandatory elements on your web interface:

Accessibility Declaration

The accessibility declaration is the result of an effective evaluation of your online public communication service’s compliance with the reference standard. It should include a compliance status and must be updated:

·       When there is a substantial modification or overhaul of the site.

·       3 years after the publication date of the declaration.

·       18 months after the publication of a new version of the reference framework.

 

Multi-Year Plan

The multi-year plan lasts a maximum of three years and presents the entity’s policy on digital accessibility. It should be accompanied by an annual action plan detailing the actions planned to improve accessibility.

Both documents should be accessible online on the entity’s site, and links to these documents should be included in the accessibility declaration. These documents must be published in an accessible format.

 

Accessibility Status

The accessibility status must be included in the footer of all pages on your product. It should reflect your product’s compliance status according to 3 values:

·       Full compliance: If all the RGAA criteria are met.

·       Partial compliance: If at least 50% of the RGAA criteria are met.

·       Non-compliance: If no valid audit has been performed or if less than 50% of the RGAA criteria are met.

In addition to this mention in the footer, it’s crucial to allow users to report an accessibility issue through a help section on your product.

 

Conclusion

Awareness and design are key starting points for addressing accessibility issues from the outset. By integrating inclusive design into your user interface and experience, you can make a meaningful impact even before development begins. The goal isn’t perfection, but rather a proactive approach to continually enhancing accessibility.