Accessibility Statement

1. Scope and status

This statement covers the status pages IsItStillUp publishes on behalf of its customers, and the dashboard at www.isitstillup.com, operated by Nancy Sahu.

Our target is WCAG 2.1 Level AA. We consider published status pages to be substantially conformant and the dashboard to be partially conformant, with the known gaps in section 4.

This is a self-assessment carried out by the team that builds the product. We have not commissioned an independent accessibility audit and we do not publish a VPAT. If your procurement process requires either, tell us — we would rather discuss what is realistic than let you assume we have one.

2. Why the public page starts from a good place

The accessibility of a status page matters more than most pages, because people arrive at it under stress and often on whatever device is to hand. Ours is built in a way that helps by default:

• It works without JavaScript. The page is pre-rendered HTML served as a static file. Nothing on it requires a script to run in order to be read, which removes an entire category of assistive-technology failure rather than working around it.
• It is semantic HTML. Headings, lists, tables and landmarks describe the structure, so a screen reader can navigate by heading rather than reading top to bottom.
• Status is never colour alone. Every component state carries a text label as well as a colour, so “degraded” is readable to someone who cannot distinguish it from “operational”.
• It respects your theme. Light and dark are driven by your system preference, and both palettes are chosen to meet AA contrast ratios for body text.
• It is small. A page that loads over a poor connection is an accessibility property too, and it is the one that matters most during an outage.

3. What we test

Keyboard navigation, focus visibility, heading structure, form labelling, and colour contrast against the AA thresholds, on the surfaces our customers and their customers use most: the published status page, the subscribe and preference-centre flows, sign-in, and the incident-editing screens.

Testing is manual, by us, on current versions of the major browsers with the platform screen reader. We do not currently run automated accessibility checks in CI. That is a gap in our process rather than in the product, and we are stating it rather than leaving you to guess how the testing happens.

4. Known gaps

We would rather list these than have you find them. Each is real as of the date at the top of this page.

• Dashboard data tables. Some of the denser tables in the dashboard — audit log, subscribers, metrics — scroll horizontally on narrow viewports and are harder to navigate by keyboard than the rest of the interface.
• Charts. Uptime bars and metric charts convey their detail visually. The underlying numbers are available as text and via CSV export and the API, but the graphics themselves are not a full alternative for a screen-reader user.
• Customer customisation. Customers can set their own brand colours and custom CSS on their status page. We cannot guarantee the contrast of a palette we did not choose. Our defaults meet AA; if you change them, the resulting page is yours to check, and we would encourage you to.
• No independent audit or VPAT. As stated above.

5. Reporting a barrier

If something here is unusable for you, please tell us at support@isitstillup.com. Describe what you were trying to do, the page, and the assistive technology and browser if you know them.

What happens then

We aim to acknowledge within 2 business days and to tell you either when it will be fixed or, honestly, that it will not be soon and why. An accessibility report from a person trying to use the product takes priority over most other work, including in the free tier.

If you are not satisfied with our response, you may raise the matter under the applicable accessibility or equality law in your jurisdiction. Our contact details are on the contact page.