Accessibility Statement

Loctarim should be usable by everyone, including people who navigate by keyboard, use a screen reader or magnifier, need larger text or higher contrast, or are sensitive to motion.

We aim to meet WCAG 2.2 Level AA. We are not claiming we have fully met it — see what we know is not right yet. This statement describes the position as of the effective date above, and is written to be checked rather than to reassure.

Keyboard and focus

• Every page starts with a “Skip to main content” link as the first tab stop.
• One focus ring is defined for the whole application, so a control cannot ship without a visible keyboard state. It is a two-pixel outline offset from the control, not a colour change.
• Anchor targets and skip-link destinations are offset below the sticky header, so following a link does not land the reader under it.
• All functionality is reachable without a mouse. There are no drag-only or hover-only actions.

Forms

• Every field is built through one shared component, which guarantees a real <label for>, hints and errors associated with the input via aria-describedby, and aria-invalid set when validation fails.
• Required fields are marked with CSS rather than a literal asterisk in the label text, so a screen reader announces “Description, required” instead of “Description star”.
• Errors are shown as text next to the field they belong to, never as colour alone, and never only as a summary at the top.
• Submit buttons report their busy state while a form is in flight.

Content and structure

• Pages use one <h1> and a nested heading order below it.
• Every listing photo carries alternative text — currently derived from the listing title — and the generated placeholder artwork is labelled by category. No image is ever left with an empty alt.
• Navigation landmarks are labelled, so a screen reader can jump between them.
• Text is real text, not text baked into images.

Colour, contrast and motion

• Light and dark themes are both first-class. The theme is applied before the page paints, so there is no white flash for someone using dark mode for light-sensitivity reasons.
• The palette is checked for contrast against WCAG AA, with an automated test that fails the build if a token pair falls below the required ratio.
• Status is never conveyed by colour alone — every badge carries a word as well.
• prefers-reduced-motion is honoured. Animation collapses to an instant state change rather than disappearing, so feedback is not lost.
• Nothing flashes, blinks or auto-plays.

Zoom and reflow

• Layouts reflow to a single column at 320px and at 400% zoom without horizontal scrolling.
• Sizing is relative, so the browser's text-size setting is respected.

Listed because a statement without this section is not worth reading. These are open items, not accepted limitations.

• No third-party audit. Accessibility here comes from construction and internal review, not from an independent conformance evaluation. No VPAT or ACR has been produced.
• Limited assistive-technology testing. The application has not been systematically tested end to end with VoiceOver, NVDA, JAWS, Dragon or a switch device. Individual surfaces have been reasoned about carefully; that is not the same thing as being used by someone who depends on them.
• No automated accessibility checks in the test suite. Contrast is covered by a unit test; there is no axe pass over rendered pages in the end-to-end suite, so regressions elsewhere would not be caught automatically.
• Dynamic updates may not always be announced. Some content that changes after an action — filtered result counts, some inline confirmations — may not be announced by a screen reader, because live regions have not been applied consistently across every surface.
• Photo alternative text is generated, not written. It is built from the listing title — “Folding trestle table — photo 2” — which satisfies the requirement for non-empty alternative text but does not describe what the photo actually shows. Owners should be able to write their own, and cannot yet.
• The date and availability calendar needs review. Choosing a rental period is the most complex interaction in the product and the most likely to be awkward with a screen reader. Dates can also be typed.
• Third-party pages are outside our control. Card details are entered on our payment processor's hosted pages, whose accessibility is theirs to state.

Tell us and we will fix it. Email accessibility@[YOURDOMAIN.COM] with the page, what you were trying to do, and the assistive technology and browser you were using if you know them. A rough description is fine — we would much rather have a vague report than none.

We aim to acknowledge within five working days and to tell you either:

• that it is fixed, and when it shipped; or
• when we expect to fix it, and how to do the thing in the meantime.

If a barrier stops you completing something time-sensitive — a rental you need to accept or cancel — say so, and we will do it with you rather than making you wait for the fix.

If you are unhappy with our response, reply and ask for it to be escalated. If it is still unresolved, you may be able to complain to the equality or disability body in your country.

By internal review during development: keyboard-only walkthroughs of the main flows, inspection of the generated markup for labelling and heading structure, an automated contrast test over the colour tokens, and manual checks at 320px and 400% zoom.

It has not been assessed by an external accessibility specialist or by a panel of disabled users. Both are the right next step and are recorded in the project backlog rather than quietly omitted here.