Accessibility Statement

GoSavis is built to be usable by everyone, regardless of ability, device, or context. We treat accessibility as a baseline standard of build quality rather than a feature to be retrofitted, and we factor it into how we design, write, and build each new flow.

This statement is written to be checkable. Where it says something is tested, there is an automated check behind it that a change passes before it ships; where we have not done something yet, it says so rather than leaving the reader to assume otherwise. If you run into a barrier, telling us is the fastest way to get it fixed, and we treat every report as a defect rather than a stylistic preference.

We work to the Web Content Accessibility Guidelines (WCAG) 2.2 at Level AA. That is the standard we design and build against, and its four principles are the checklist we use in design and engineering review. It is a target rather than a claim of conformance: the platform has not been independently audited, and we do not publish a conformance report.

• Perceivable: Information and interface elements must be presented in ways that people can perceive, including those who rely on assistive technology

• Operable: The interface and navigation must be operable with a wide range of input methods, including keyboard only, switch devices, and voice control

• Understandable: The information and the operation of the interface must be understandable, with predictable behaviour and clear error recovery

• Robust: Content must be robust enough to be interpreted reliably by a wide variety of user agents, including current and future assistive technologies

These behaviours are built into the shared foundations the whole platform is assembled from, so a new flow inherits them rather than having to re-implement them.

• A visible focus ring on every focusable element, drawn by one global rule, shown for keyboard use and suppressed for a mouse click

• Semantic markup and page landmarks, so the header, the navigation, the main content and the footer are exposed as distinct regions

• Motion that honours your operating system reduced-motion preference, both as a global stylesheet rule and as a single guard read live inside every animation the product runs

• A required description on every photo uploaded to a listing, with the field explaining that it is read aloud to anyone using a screen reader

• Text labels on icon-only controls, so a control with no visible words still announces what it does

• Status messages announced politely, or assertively where the message needs immediate attention

• Interface colour drawn from one shared token set, so the text and button inks are chosen once for contrast rather than per component

• Layouts that reflow to phone widths rather than asking you to scroll sideways

• Plain-language copy through the booking and onboarding flows, with errors that name what went wrong and what to do next

Three checks run automatically in the test pipeline a change passes through before it ships.

• Colour contrast: Computed from the design tokens themselves rather than sampled from a screenshot, on the light theme: white on the primary ink of every colour palette we offer at 3:1 or better, and the tertiary text colour at 4.5:1 against the secondary surface

• Touch target size: Every visible, enabled control on the home, search, listing, saved and settings pages is measured against a 44 by 44 pixel floor, at a phone width in a touch context and at a desktop width, counting the area a finger can actually reach rather than the drawn box

• Keyboard operation: The date and time step of checkout is driven with the Tab key, the arrow keys, Enter and Space alone, from the month grid through to a chosen slot and on to the following step

What we have not tested

We have not tested GoSavis with screen readers or other assistive technologies. We hold no test matrix and publish no results for VoiceOver, TalkBack, NVDA or JAWS, and the platform has not been independently audited. Our automated checks run in one browser engine, Chromium, so we have not verified behaviour in Safari or Firefox, and we have not yet verified the layout at 320 pixels wide or at 200 per cent zoom.

What we do instead is the three automated checks above, building the behaviours listed earlier into the shared foundations so a new flow inherits them rather than re-implementing them, and acting on what people report to us. Assistive technology testing and an independent audit are work we intend to do and have not done; until they are done, this section is what we can honestly say about compatibility.

These are the shortfalls we already know about. They are recorded in our engineering backlog and treated as defects rather than held for an annual review, and they do not currently carry published owners or target dates.

• The plotted graphic in each business analytics chart is hidden from screen readers, and the axis labels sit inside it, so the heading and, on a doughnut chart, its legend are read while the figures themselves are not available to anyone who cannot see them

• The operating bar that reports connection, task and session status is exposed as a labelled region but does not announce its changes, so the status is visible without being spoken

• The touch target check records its findings rather than failing the build, and it is not yet reading clean at phone width

• A photo attached to a post takes its description from the caption, and a profile image takes the account name; neither is a description written for the purpose, which the listing gallery does ask for

• There is no skip link, so reaching the main content from the keyboard means moving through the page chrome first

If you find anything else, please tell us. We treat accessibility regressions as bugs, and we prioritise them alongside other defects.

If you encounter an accessibility barrier, please get in touch and we will prioritise a fix.

• Email: support@gosavis.com

• Response time: Within 2 business days

• What to include: The page or flow where the barrier occurs, the assistive technology and browser you were using, and a short description of what you expected to happen