Accessibility Statement

1. The standard we target

We build and test this site against the Web Content Accessibility Guidelines version 2.2 at level AA. Accessibility requirements are part of the definition of done for a component rather than an audit at the end, which is the difference between a site that conforms and one that was made to pass a checker.

2. What that means in practice

• Keyboard operation. Every interactive element is reachable and operable with a keyboard, in an order that matches the visual layout, with no keyboard traps.
• Visible focus. Focus is always visible and uses a contrasting outline rather than being removed for aesthetic reasons.
• Target size. Interactive targets meet the minimum size so they can be operated without precision pointing.
• Contrast. Colour pairs are chosen and recorded as design tokens rather than checked afterwards, so text meets the contrast minimum in both light and dark rendering.
• Colour is never the only cue. Status and meaning are carried by text or position as well as hue.
• Semantics. Headings describe structure, landmarks are used correctly, and interactive controls are real controls rather than styled containers.
• Forms. Every field has a label, errors are associated with their field and announced, and nothing relies on placeholder text as a label.
• Motion. Animation is subtle and honours the reduced motion preference. No content moves or updates automatically in a way that cannot be stopped.
• Text. Content reflows without horizontal scrolling and remains usable when text is enlarged.
• Skip link. A skip to content link is the first focusable element on every page.

3. How we test

Automated checking catches contrast, labelling and structural problems. It cannot judge whether a keyboard path makes sense or whether a screen reader announcement is useful. Browser checks exercise navigation, filters, forms and preferences. A complete screen reader assessment across assistive technologies has not been completed.

Architecture and workflow explanations use readable text and numbered steps, rather than requiring visitors to interpret a diagram or an image.

4. Known limitations

Browser testing cannot establish compatibility with every assistive technology. Please report barriers using the contact method below.

5. Tell us when it is wrong

If something on this site is difficult or impossible to use, email support@sawhorsesoftware.tech and describe what you were trying to do. Tell us the page and, if you can, the assistive technology and browser you were using. We treat accessibility defects as defects rather than as suggestions.

6. Accessibility in what we build

We build client software to the same standard. Accessibility is specified per component during design, with contrast pairs, focus order, target sizes and screen reader semantics recorded rather than inferred, and it is part of the acceptance criteria rather than a separate project.