Accessibility statement

What cloudroute.net does today, what still gets in the way, and how to tell us when something breaks.

Our commitment and the target

We are working towards WCAG 2.2 Level AA across cloudroute.net — every page, including the long technical articles in Insights and the checklists in Guidelines. That is the standard we design and review against, not a badge we are claiming; this statement describes where the site stands, including where it falls short.

We treat it the way we treat routing: as something you measure rather than assume. A page that renders correctly on a wide screen with a mouse tells us nothing about how it behaves under a screen reader at 200% zoom, so we check that case explicitly. The FAQ covers other practicalities.

What is built in

These are properties of the current build, not aspirations:

  • Semantic HTML. Headings descend one level at a time, lists are lists, tables use real header cells, and every page has a single h1. Structure is what assistive technology navigates by, so it carries meaning, not styling.
  • A skip link. The first focusable element on every page jumps past the header and navigation to the main content. It is hidden until focused.
  • Keyboard operability. Navigation, the menu toggle, links, buttons and carousel controls are operable from the keyboard alone, in an order matching the visual reading order.
  • Visible focus states. Focus is drawn with a clear outline and an offset so it stays legible against text and card backgrounds alike. We do not remove the focus ring.
  • Colour contrast verified against AA. When the site moved to a light colour scheme, every text and interface colour pair was re-checked rather than assumed to carry over. The decorative glow effects inherited from the dark theme were removed: on a light background they cut the contrast of the text on top of them.
  • Alt text. Images that carry information have alternatives describing the information, not the picture. Decorative images are marked so assistive technology skips them rather than announcing filenames.
  • Reduced motion is respected. When your operating system reports prefers-reduced-motion: reduce, transitions and animations are suppressed rather than merely shortened.

Known limitations

We are not claiming full conformance. These are the barriers we know about:

Diagrams and code samples in older articles

Some diagrams in earlier insight articles convey topology through layout — which box sits upstream of which, which path is the failover path — and the prose does not always restate that relationship in words. If you cannot see the layout, the argument is harder to follow. The same applies to configuration samples whose meaning depends on indentation. We are rewriting these as we revise each article, so the diagram supplements the text rather than carrying it.

Wide tables on small screens

Comparison tables with several columns exceed the width of a phone screen. They sit inside a horizontally scrollable container that is keyboard-scrollable and does not force the page itself to scroll sideways — but reading a wide table on a narrow screen still takes more work than it should.

How we test

Two passes, because neither is sufficient alone. Automated checks run during development and catch mechanical failures — missing alternative text, unlabelled controls, contrast below threshold, broken heading order. Then manual passes: navigating a page start to finish with the keyboard only, and listening to it with a screen reader to check that headings, links and tables announce something useful.

Automated tools catch only a fraction of real barriers. They can tell you an image has an alt attribute; they cannot tell you the text inside it is useless. A clean report is a floor, not a result.

Reporting a barrier

If something on this site blocks you, email [email protected]. There is no form to fill in — see contact for how we handle email. What helps us reproduce the problem quickly:

We reply within one business day, during Mon–Fri, 9:00–18:00 Pacific. Quick fixes we ship and tell you about. If it will take longer — a rewritten diagram, a restructured table — we say so and describe a workaround meanwhile, so you are not left without a route to the content. Our editorial policy covers corrections generally, and the terms cover the site as a whole.

Why this matters for infrastructure documentation

Most of what we publish gets read under pressure. An engineer opens a page on BGP convergence or DNS TTL selection because something is failing right now and they need one detail out of two thousand words. Anything that makes a page harder to scan costs time directly: a heading structure a screen reader cannot jump through, a table whose header cells are not tied to their columns, a diagram that carries the answer when nothing else does.

Keyboard access matters for the same reason. During an incident, hands stay on the keyboard and the second screen is running a terminal; a page needing precise pointer work gets abandoned. Building for assistive technology and building for an SRE at 03:00 turn out to demand the same things.

Found something that does not work?

Tell us what happened and what you were using. We reply within one business day.

Start a conversation Read the technical insights