Accessibility

Table of contents

1. 1. Our approach
2. 2. Assessment status
3. 3. Accessibility measures implemented
4. 4. Known limitations
5. 5. Report a difficulty
6. 6. Continuous improvement
7. 7. Related documents

Last updated: 23 July 2026

1. Our approach

As part of the AtypikHouse student project, particular attention is paid to the site's accessibility so that as many people as possible, including people with disabilities, can view the content and use the main features.

Accessibility is being built into the project progressively, particularly in navigation, forms, interactive components, and adaptation to different screen sizes.

2. Assessment status

No full audit against the RGAA (Référentiel général d'amélioration de l'accessibilité, the French accessibility standard) has been carried out on this version of the project.

No level of conformance is therefore claimed.

The measures presented on this page describe the improvements built into the project, but do not constitute a certification or an official RGAA conformance declaration.

3. Accessibility measures implemented

The following measures have been progressively built into the project and verified in the code before being listed on this page:

• keyboard navigation on the main interactive features (links, buttons, toggles, form fields, search assistant, filters panel);
• visible focus on links, buttons, toggles, and form fields;
• a skip link to go directly to the main content;
• pages organised with structured headings, with a single H1 per page;
• labels associated with the main form fields, grouped with fieldset/legend where relevant (for example the profile choice at sign-up);
• optional fields indicated in their label (for example "Phone (optional)") rather than by colour alone;
• understandable error and confirmation messages, announceable to assistive technologies via role="status" and aria-live="polite";
• alt text on the main meaningful images (stay photos) and an empty alt="" attribute for purely decorative images;
• icon-only buttons given an accessible name (visually hidden text or aria-label);
• the "Cookie settings" page toggle uses role="switch" and aria-checked, with an "On"/"Off" state shown in text, never by colour alone;
• the search assistant and filters panel windows have an accessible name, close with the Escape key, and move focus in on open and back to the trigger button on close;
• carousels usable by keyboard via real previous/next buttons, with no auto-scroll;
• Google Maps, Leaflet, and CARTO maps loaded only after explicit consent, and can be declined without blocking access to the rest of the site;
• respect for the system's reduced-motion preference (prefers-reduced-motion);
• layout adapted to desktop, tablet, and phone screens;
• the page's main language set with the lang attribute.

4. Known limitations

As the site is a student project still under development, some pages or features may still have accessibility issues.

Complex components, in particular interactive maps, some carousels, calendars, the booking flow, modal windows, and content provided by external services, may need further improvements.

External maps can be declined without blocking access to the site's other main features. When a map isn't loaded, the essential information remains available in text form where relevant.

After reviewing the code, the following limitations were identified:

• the availability calendar shown on listing pages is read-only: the cells representing each day are not themselves keyboard-navigable. Date selection is still possible via the form's native date fields, which remain accessible;
• in the search assistant and filters panel, focus correctly moves into the window on open and back to the trigger button on close, but is not strictly trapped inside it: the Tab key may allow moving out to the rest of the page while the window is still open;
• some short, repeated link labels (for example "Discover" on stay cards) may lack context when read in isolation by assistive technology, outside of their card;
• colour contrast has not been exhaustively checked with a dedicated measurement tool; attention is paid to the colours used, but there is no certification at this time;
• content provided by third-party services (Google Maps, Leaflet, CARTO) is not fully controllable by the project and may have its own accessibility limitations;
• the automated search assistant (chatbot) relies on a simple rules engine; how well certain assistive technologies track dynamic updates to the conversation has not been thoroughly tested.

5. Report a difficulty

If you have difficulty accessing content or using a feature, you can contact the project owner directly:

Quentin Seynaeve
AtypikHouse student project
Email address: contact@atypikhouse.fr

A response or an alternative solution will be sought where possible.

6. Continuous improvement

Accessibility is being addressed progressively as the project develops.

Fixes identified through testing, user feedback, and future updates may be incorporated into future versions of AtypikHouse.

When a new component, external service, or new feature is added, its accessibility must be checked before it is made available.

7. Related documents

• Privacy policy (French page)
• Cookie policy (French page)
• Cookie settings (French page)
• Legal notice (French page)
• Terms of use (French page)
• Terms of sale (French page)
• Cancellation policy (French page)

↑ Back to top