Accessibility statement

We target WCAG 2.2 Level AA across SiteUpdate, with the capture widget held to the highest bar — it embeds into your website, in front of your visitors, so its accessibility becomes part of yours. The dashboard, reporter status pages, and this marketing site are built to the same standard. Conformance is a target we test against and keep working toward, not a one-time certificate; this page describes what the widget actually does today.

The whole capture flow works without a mouse — including pointing at the part of the page you want changed:

• Element picking by keyboard.While picking, Tab (or the arrow keys) cycles through the page's visible headings, links, buttons, and images; Shift+Tab cycles backwards; Enter selects the highlighted element. The cycle ends with the panel's own escape-hatch buttons, so nothing is reachable by mouse only.
• Focus is managed, not lost. The panel is a proper modal dialog: when a step opens, focus moves into it, and Tab / Shift+Tab stay trapped inside until you leave. Closing with unsent work asks for confirmation before discarding.
• Escape always works. Esc backs out of picking and closes the panel at any step.
• Visible focus, adequate targets. Every focusable control shows a visible focus ring, and interactive targets meet the WCAG 2.2 minimum of 24×24 CSS pixels — primary buttons are 44px tall.

The widget announces what's happening through a polite live region, in plain words rather than markup-speak: each step is introduced with its instructions (“Step 1 of 3. Click the part of the page you want changed…”), and while cycling candidates the highlighted element is described the way a person would say it — “Heading: Pricing”, “Button: Add to cart”, “Image: (no description)”. The panel itself uses standard dialog semantics, and the discard confirmation is announced as an alert dialog.

Pointing at an element is never required. The picking step always offers “It's not on this page” and “It's about the whole page” — both part of the keyboard cycle — so a reporter can simply describe the problem in words. The technical context (page, browser, and diagnostic data) is still captured automatically, so choosing the non-visual path never produces a second-class report.

The widget has exactly one entrance animation, and it is disabled entirely when your operating system asks for reduced motion (prefers-reduced-motion). There is no parallax, no autoplaying media, and nothing that flashes.

In the spirit of an honest statement: keyboard element-picking cycles through headings, links, buttons, and images — the elements requests are almost always about. A mouse or touch user can select any element on the page. If the thing you need isn't in the keyboard cycle, the describe-it-in-words path above covers it, and widening the candidate set is on our roadmap. If you hit a barrier this page doesn't acknowledge, we want to know.

Accessibility reports go to the front of the queue. Email accessibility@siteupdate.io and it will be handled on a priority track. If you're a signed-in customer, the dashboard's Contact us form reaches us the same way. Either way, tell us what you were trying to do and what assistive technology you were using.