How this site is tested

The checks

Here they are, grouped by when they run.

Before the browser opens

• The build stops if a text field in the source is empty or missing.
• The pages are rebuilt from the source and compared with what's committed, so a hand edit to a generated page or a forgotten rebuild fails the pipeline.
• Every generated page and the 404 page pass HTML validation with html-validate.
• The robots.txt file, the sitemap, the 404 page and the redirects at /en/ and /work/ are in place, robots.txt doesn't block the site, and the sitemap lists exactly the pages of the site.
• The case-study pages on disk match the ones in the source, so a renamed page can't be left behind.

In a real browser, on the home page and every case study

• No sideways scrolling at six screen widths, from 320 to 1920 pixels.
• No JavaScript errors and no console errors.
• No requests to other servers.
• Every link to a section or to another page of this site points to something that exists, and so does every file the page loads. The check runs on the folder that gets published, so a file left out of the deploy fails it.
• No ID is used twice on a page.
• One h1 per page, and no skipped heading levels.
• A title, a description of the right length, the correct canonical URL, the page language and one block of structured data, with no other language versions claimed.
• A share preview of the right type, with an image file that exists, is 1200 by 630 pixels and shows the page's current headline.
• Contrast of at least 4.5:1 (WCAG AA) for every piece of visible text, in light mode and again in dark mode.
• Menu links, buttons, breadcrumb links and the next-case link at least 24 pixels tall on phone screens.
• Every link that opens a new tab has rel="noopener" and tells screen readers that it opens a new tab.
• The Skip to content link lands on the main content.
• The menu highlights the section you're reading on the home page, and marks Work on the case studies.

The 404 page is opened in the browser too, and gets the same checks for screen width, errors, requests to other servers and contrast.

When every check passes on the main branch, the site is deployed to GitHub Pages. A version that fails never goes live, so the Audit passed label on the home page holds for every published version.

What the checks don't cover

The browser checks run in Chromium only, so a layout bug that appears only in Safari or Firefox would get through. None of it replaces trying the pages with a screen reader.

Outside the gate

External links are checked every Monday, and whenever the copy changes, in a separate workflow that never blocks a deploy. A bad minute at GitHub or LinkedIn shouldn't stop a small text fix from going out, but I still want to find a broken link before anyone else does.