Accessibility

Courtesy translation. Only the Italian version of this document has legal value: if the two texts diverge, the Italian text prevails. Italian law applies to the relationship in any case.

Our commitment

We want anyone to be able to read these pages and complete a sign up, whatever the device, whatever the assistive technology, and whether a disability is permanent, temporary or situational.

Accessibility is not a feature bolted on at the end: it is part of how we write markup and stylesheets. When we get it wrong, we would rather write it here than hope nobody notices.

Reference standard

Our reference is the Web Content Accessibility Guidelines 2.1, level AA.

This is a stated target, not a certified conformance. We have not carried out a full conformance audit by an independent evaluator, and so we do not claim full level AA conformance.

We apply the four principles of the guidelines as design criteria: perceivable, operable, understandable, robust.

What we have already done

• Full keyboard navigation on every public page and through the sign up flow.
• A focus indicator that is always visible and is not stripped out by the stylesheets.
• Contrast ratios between text and background checked across the interface components.
• Respect for the system preference for reduced motion.
• Semantic structure with landmarks, a consistent heading hierarchy and a skip to content link.
• Live regions that announce form errors to people using a screen reader.
• Alternative text on images that carry information, and appropriate attributes on decorative ones.
• A layout that survives browser zoom and narrow widths without losing content.

Keyboard navigation

Every interactive element is reachable with the tab key and can be triggered with enter or space.

The first thing you meet when you press tab is a link that jumps straight to the content, so you do not have to walk through the menu on every page.

On small screens the menu opens and closes from the keyboard, closes with the escape key and returns focus to the button that opened it.

Tab order follows the visual order of the page: we do not use positive tab indexes to force different paths.

Contrast and readability

Text and component colours are chosen to meet the contrast ratios level AA requires, verified on the main components.

We never use colour as the only carrier of information: an error state, for example, comes with words, not just a red border.

Text scales with browser settings and measurements are relative, so enlarging does not break the layout.

Reduced motion

People who have set the reduced motion preference in their operating system get a version of the site without unnecessary animation and without wide transitions.

We use no flashing content and nothing that moves automatically without a way to stop it.

Nothing starts playing audio on its own.

Forms and errors

Every field has a label associated programmatically, not merely placeholder text inside the field.

Errors are announced in a live region, so someone using a screen reader hears them without having to hunt around the screen for where the message appeared.

Error messages say what is wrong and how to fix it, in plain language and without technical codes.

The sign up flow always shows which step you are on and how many are left.

Semantic structure

We use native HTML elements wherever they exist: a button is a button, a link is a link. We reach for ARIA attributes only where native markup is not enough.

Pages carry explicit landmarks for header, navigation, main content and footer.

Legal documents have a table of contents generated from the second level headings, with stable anchors that keep working when you switch language.

The page language is declared, so speech output pronounces it correctly.

Limitations we know about

Here is what we know we have not fixed yet.

• We have not run a full independent audit across every page: our checks are internal and cover the main journeys.
• Tables in the legal documents need horizontal scrolling on very narrow screens, which is not the most comfortable solution.
• Some third party pages reached during payment are outside our control and follow the accessibility choices of that provider.
• Content generated and published by customers on their own sites depends on their choices: we provide correct structure, but we cannot guarantee the final accessibility.
• We have not yet completed testing across every combination of browser and assistive technology in use.

How we test

Testing is done internally and combines three methods: automated checks on the measurable criteria, manual keyboard only passes, and speech output passes on the main journeys.

The journeys we treat as critical are reading the legal documents, reviewing the plans and completing a sign up.

When we ship a new feature, the keyboard pass is part of the release, not of a later review.

Reporting a barrier

If something stops you using the site, write to info@flarseo.com. It is the most useful report we can get.

1. Name the page and the part that does not work.
2. Describe what you were trying to do and what happened instead.
3. If you can, tell us which browser and which assistive technology you are using.

We take up the report and reply with a first assessment within a few working days, saying whether the fix is immediate or needs wider work. If the barrier stops you completing a sign up, we will complete it with you by email or phone in the meantime.

Go to contacts

Updates

This statement is updated when we fix a known limitation or discover a new one. Every version carries a number and a date.

If one day we complete an independent audit, this page will say so precisely, naming who carried it out and with what result. Until then it remains a statement of commitment and of work in progress.