Method

How to tell if your website is accessible in 5 minutes?

Five simple checks can quickly identify accessibility barriers on a web page. They do not prove that it is compliant, but they provide an initial assessment before an automated scan and a manual audit.

The Short Answer

To find out whether your website is accessible, navigate it using the keyboard, zoom to 200%, disable images, examine the contrast, and review the link labels. These checks reveal common barriers without requiring any installation. However, they cover only some of the WCAG and RGAA criteria. Supplement them with an automated analysis, followed by manual testing that includes assistive technologies.

This quick check can be performed on an important page of your website, such as the home page, a contact form, a login page, or a checkout step. Ideally, choose a representative page containing several types of components: navigation, buttons, fields, images, links, and structured content. In five minutes, the goal is not to draw up an exhaustive list of issues, but to identify the most obvious barriers and determine whether an in-depth analysis is necessary.

An apparently satisfactory result does not mean that the page is compliant. Conversely, a single major barrier, such as a menu that cannot be used with a keyboard or a form that cannot be understood, is enough to warrant a priority fix. Accessibility must be assessed across complete user journeys and in context, not solely on the basis of a page’s overall appearance.

Five tests to perform in five minutes

• Use Tab and Shift plus Tab to navigate through interactive elements. Start at the top of the page and see whether you can reach links, buttons, menus, and form fields without using the mouse. Check that a visual indicator always shows which element has focus and that the navigation order remains logical.
• Zoom the page to 200% and check that the content remains readable. Text must not disappear, overlap other elements, or require complex actions. The main functions must remain available, even if the page layout adapts to the reduced width.
• Disable images and look for information that is no longer available. An informative image must have a relevant alternative or be accompanied by equivalent content. A purely decorative image must not add unnecessary noise for people using a screen reader.
• Identify text that is clearly difficult to distinguish from its background. Pay particular attention to small text, light gray content, buttons, error messages, and elements displayed on hover or focus. Insufficient contrast can make information unreadable despite an otherwise appropriate layout.
• Read links out of context and check that their destination remains understandable. Labels such as “click here,” “learn more,” or “read more” become ambiguous when repeated. Prefer wording that clearly indicates the relevant page, document, or action.

Spend about one minute on each check and immediately record any obstacles you observe. To obtain a more useful result, describe each problem by specifying the relevant page, the affected element, and the resulting effect. For example, “The menu button cannot be reached with the Tab key on mobile” is more actionable than “Keyboard navigation does not work properly.”

If a modal window, consent banner, or menu opens during the test, also check that you can close it using the keyboard and resume navigating. Focus must not disappear or remain trapped behind overlaid content. These components are common and can prevent access to the entire page.

What each check can reveal

Keyboard testing often reveals problems that remain invisible when using a mouse. A component may appear to work perfectly while relying on an interaction that is unavailable from the keyboard. Missing or overly subtle focus also creates a significant difficulty: users may be able to activate elements but not know where they are on the page.

Zooming makes it possible to observe how well the layout adapts. At 200%, a menu may cover the text, a button may extend beyond the screen, or a column may become impossible to view. Horizontal scrolling is not always prohibited, particularly for certain complex content, but it should not be necessary to read every line of ordinary text.

Disabling images helps identify information that is exclusively visual. This may involve a chart, a useful photograph, an icon used as a button, or an image containing text. The expected alternative depends on the role of the image in its context: a simple literal description is not always sufficient.

A visual review of contrast provides only an initial warning. Reliable measurement requires a tool capable of precisely comparing the colors of the text, background, and components. The different states of an element must also be considered, for example when idle, hovered over, focused, selected, or displaying an error.

Finally, reading links out of context provides a quick way to assess their clarity. People navigating with assistive technologies may view a list of links separately from the surrounding content. Each label must therefore remain sufficiently explicit while avoiding unnecessarily long or repetitive wording.

What these tests do not demonstrate

A page that can be used with a keyboard may still have an incorrect heading structure, poorly labeled forms, or unusable error messages. Alternative text may also be present but useless, redundant, or inappropriate for the context.

These tests therefore constitute a screening process, not a complete RGAA or WCAG compliance test. They replace neither code review nor real-world use with different assistive technologies.

A quick check also cannot properly verify how content is rendered by a screen reader, the accessible names of components, the relevance of roles, or the announcement of dynamic changes. An interface may be visually navigable with a keyboard while remaining incomprehensible when rendered audibly.

It also does not cover all multimedia content. A video may require captions, a transcript, or audio description, depending on its content. A downloadable file, such as a PDF document, must also be examined separately: the accessibility of the page offering the download does not guarantee the accessibility of the document.

Results obtained from a single page cannot automatically be generalized to the entire website. Different page templates, components, or user journeys may present their own barriers. To evaluate a service, a representative sample must be created that includes key pages, frequently encountered content, and steps that are essential to the user.

The next step: the automated scan

An automated scan reproducibly examines technically verifiable rules: missing attributes, invalid structural relationships, measurable contrast ratios, or markup errors. Inclaria lets you analyze one page for free in a real browser and prioritize findings by severity.

Automation alone cannot determine whether alternative text accurately describes an image, whether the reading order is logical, or whether an instruction is understandable. Therefore, no automated result is sufficient to declare a website compliant.

After the five quick checks, the scan helps turn an impression into more structured findings. It can detect multiple occurrences of the same issue and provide useful technical guidance to the team responsible for remediation. This reproducibility also makes it possible to rerun the analysis after a change to verify whether automatically detectable errors have disappeared.

The results must be interpreted with discernment. Some alerts require human validation, while the absence of errors does not mean the absence of barriers. A tool does not always understand the intent of the content or the user’s actual journey. It can confirm that an attribute exists without accurately assessing its relevance.

To prioritize remediation, start with issues that block an essential action, affect many pages, or concern components reused throughout the website. Fixing a defect in a menu, shared form, or common template can improve several user journeys simultaneously. Then document the results to track regressions and fixes over time.

Why Finish with a Manual Audit

A manual audit checks the criteria that require judgment, context, and complete user journeys. In particular, it covers navigation consistency, screen reader output, forms, modal dialogs, and dynamic changes.

For services covered by the European Accessibility Act since 28 June 2025, the analysis must be aligned with the applicable legal scope. This content is for informational purposes and does not constitute legal advice; a lawyer can review a specific case.

The auditor selects a representative sample of the website, examines the applicable criteria, and documents the results precisely. The audit does not merely identify isolated errors: it checks whether users can understand the interface, find their way around, correct their errors, and complete the intended actions without encountering barriers.

Testing with assistive technologies provides insights that a visual review alone cannot offer. In particular, it makes it possible to hear the reading order, the name announced for buttons, the heading structure, and the information conveyed when validation succeeds or fails. Depending on the service being assessed, several environments may be required.

The audit must result in actionable fixes. Each finding should specify the element concerned, the issue encountered, its impact, and a possible solution. Once the changes have been made, targeted verification confirms that they effectively remove the barrier without introducing regressions.

The five-minute check therefore remains an excellent starting point. It raises team awareness, quickly identifies barriers, and helps determine the next steps. However, establishing a level of compliance, publishing a statement, or safeguarding an essential user journey requires an appropriate audit methodology and verifiable evidence.