A service is accessible when people can really use it.

From error to person

An error in the code becomes important once we understand which barrier it creates for a person. This translation is what makes a check useful: without it, it remains just a list of findings.

1. 01

   Step 1: Requirement

   A technical criterion is not met on a page, in a component or in a document.

2. 02

   Step 2: Barrier

   That unmet criterion creates a concrete obstacle: an element that cannot be reached, information that cannot be perceived, an action that cannot be understood.

3. 03

   Step 3: Person

   The obstacle affects someone: people navigating by keyboard, using a screen reader, zooming in, or needing clearer language.

4. 04

   Step 4: Impact

   We understand what they cannot do: find information, fill in a form, authenticate, complete a transaction or continue the journey.

5. 05

   Step 5: Priority

   We compare the impact with the affected journey, how widespread the component is, and the applicable framework.

6. 06

   Step 6: Solution

   We indicate the fix and, when possible, the point to act on so the same barrier does not reappear elsewhere.

7. 07

   Step 7: Re-verification

   We check that the barrier has really disappeared and that the fix has not introduced new ones.

Digital, cognitive and physical accessibility

These are three connected dimensions: the first concerns how the interface can be perceived and used, the second how much the service can be understood and completed, the third the concrete possibility of reaching and using in-person spaces, workstations and services.

There is no single "cognitive user" and no single solution that works equally well for everyone: choices need to be tailored to the real service and to the people using it.

Zero automated errors does not automatically mean zero barriers.

None of these tools, taken alone, necessarily tells the whole story.

A fix must be verified.

Fixing is only half the work: a change can solve the reported problem, leave it untouched for people using another technology, or introduce a new one.

1. Step 1

   Problem

   We describe the barrier in a reproducible way: where it is and under which conditions it occurs.

2. Step 2

   Impact

   We explain what it prevents and for whom, so the fix makes sense to every role involved.

3. Step 3

   Guidance

   We indicate the direction of the fix, calibrated to the technology and the real context of the project.

4. Step 4

   Implementation

   We support whoever is intervening: development, design, content editing or an external supplier.

5. Step 5

   Re-verification

   We verify the outcome: the barrier has been removed and no new ones have appeared.

When possible, a fix should also prevent the same barrier from being reproduced elsewhere: acting on a shared component or a design system avoids solving the same problem dozens of times.

Standards and regulations: it depends on the case

Depending on the entity, the product and the context, the framework can include, when applicable:

• WCAG
• European standards
• Italian Law 4/2004
• European Accessibility Act
• AgID guidelines
• Contractual or procurement requirements

Before speaking of compliance it is necessary to establish which framework really applies to the product, the service and the organisation.

It's not just the website

• Websites
• Apps
• Digital services
• Software
• Documents
• PDF
• Word
• Presentations
• Forms
• Authentication
• Multimedia
• Content
• Physical environments and spaces
• Routes and signage
• Workstations
• In-person events and activities
• Public-facing services
• Assistive technologies

An accessible journey can also break down outside the web page.

Illustrative scenarios

Examples built to make the reasoning concrete: not real VIVALDI18 cases.