Accessibility

• Skip to content. The first thing a keyboard reaches on every page is a link past the navigation, so you are not tabbing through a dozen rail links to reach what you came for.
• A visible focus ring on everything focusable, in both light and dark themes. Nothing in this product removes the browser’s focus outline.
• Reduced motion is respected. If your system asks for less motion, the fades, the drifting background shapes and the smooth scrolling all stop.
• Real semantics. Headings in order, one main region per page, and real buttons and links rather than clickable divs.
• Every field has a name. Every input, dropdown and text area in the product was checked, and the ones a screen reader would have read as “blank” are named. A test fails the build if a new one is added without a name.
• The assistant reads back sensibly. A reply is announced once, when it is finished, rather than being re-read every few hundred milliseconds while it types. The “Thinking…” and “Finding local pros…” captions are announced as they change, so you know it is working rather than stuck.
• Ordering without dragging. Where you can drag something into order — arranging a contractor profile, for instance — the arrow keys do the same job, because a drag is not available to everyone.
• Text that scales. Sizes are relative, so browser zoom and a larger default font size work rather than clipping the layout.
• Light and dark follow your system, and can be set by hand.

Stated plainly, because the alternative is you finding out the hard way:

• No independent audit has been carried out, and no conformance level is claimed.
• We have not tested with every screen reader. Anything you find is genuinely new information to us.
• Colour contrast has not been checked systematically across every surface. Some quieter text may fall below the usual threshold.
• The calendar is the part we would least expect to work well with a screen reader. It is a grid of positioned blocks, and reading a week through one has not been tested.
• Field names have been checked. The ORDER a long form is read in, and how validation errors are announced, have not.
• Documents a contractor uploads — a photo of a quote, a scan — carry whatever accessibility the original had, which is usually none. We cannot fix that for them.
• Emails we send are plain and simple, but they have not been tested against accessibility checkers.

Write to support@gable.pro or bug@gable.pro. Tell us what you were trying to do, which page, and what you use to browse — the last one is the part we cannot guess and the part that makes a report fixable.

If something blocks you from doing what you came to do, say so and we will treat it as urgent rather than as a backlog item. If we cannot fix it quickly, we will tell you a way round it in the meantime.

The specific things listed above are checked by our own tests, so they cannot quietly regress: the skip link, the focus ring, and the reduced motion rule each fail a build if they are removed. That is a much smaller promise than an audit, and it is one we can actually keep.

This page will be updated when either half changes — when something is fixed, and when we learn about a problem we had not listed.