Why these rules

The pass bar is WCAG 2.1 Level AA. That is not a preference - it is the technical benchmark behind EN 301 549, which the European Accessibility Act has referenced since 28 June 2025. There are two enforcement routes in France, and a typical client is only on one of them. The EAA route is the DGCCRF, under the consumer code. It covers services sold to consumers and exempts only businesses with fewer than ten staff AND turnover or a balance sheet at or under EUR 2 million, so most clients are inside it. The other route is article 47 of the 2005 disability law, enforced by ARCOM since the ordonnance of 6 September 2023: that one covers public bodies and private companies with French turnover above EUR 250 million, and its penalties are up to EUR 50,000 for non-conformity plus up to EUR 25,000 for failing to publish the accessibility declaration, renewable if the breach persists past six months. Automated scanning finds roughly a third of WCAG failures. An axe-clean run is a floor, never a pass. The eye-verified rules in this section are the ones that actually decide whether a site is usable, and they cannot be delegated to a tool.

House rules that are specific to how Colibrity builds, as opposed to general web standards. This section is seeded from the two examples in the 2026-08-11 brief and grows as more are confirmed. Anything here overrides a generic recommendation elsewhere in this document.

Markup that is valid, semantic and predictable. Most accessibility and SEO failures further down this document are really HTML failures caught late, which is why this section comes first in the build order.

Thresholds are the Core Web Vitals "good" boundaries measured on mobile, because mobile is where these sites lose. How to measure, before any number is quoted. Use the PageSpeed Insights API against the live URL, not a local Lighthouse run, which measures the reviewer's laptop. Take the median of at least three runs and quote the spread - identical bytes have scored 59 and 95 minutes apart, and every wrong performance conclusion on record came from trusting one run. Bust the report cache with ?cb=N, never ?p=N, which is a reserved query variable in WordPress and redirects, so you measure the redirect. Warm the cache with curl --compressed, because a cache keyed on encoding otherwise warms an entry the test never requests. The score weights are FCP 10, Speed Index 10, LCP 25, TBT 30, CLS 25. Read them before picking a target: when TBT and CLS are already zero, more than half the score is banked and only LCP is worth the work.

Craft and hygiene: the things that decide whether the next developer can work on this project without archaeology, and whether it survives its first content update. Several of these exist because they went wrong on a real delivery.

Technical SEO only - the parts a developer owns and can be held to. Keyword strategy and copy are not in scope here. Most of this section is machine-checkable and most of it is already emitted by the starter theme, so on a well-scaffolded project it should read as confirmation rather than work.

What a crawler can reach, and what it should do when it gets there. Ordered so the decisions that are cheap before launch come before the ones that are expensive after it.

Applies when the project replaces a site that is already live and already indexed. Everything here has to happen before launch, because the input is the old site, and the old site stops existing the moment the new one goes up. Volume 1 already carries seo.redirects-on-launch, which says map the URLs. This section is the part that decides what it costs: how many URLs there are, who counted them, and what "mapped" has to mean before anyone signs it off.

What a page tells a crawler about itself, kept out of the crawl dimension because folding them in would make that label a lie.

Until 2026-08-25 this standard had 156 rules and not one of them was about wp-admin. Everything in it described what a visitor sees, what a crawler sees or what a server sends. The screen the client actually opens every day, for years after we stop being paid, was not mentioned once. Every rule here rests on our own delivered work and nothing else. No client asked for them and no specification requires them; they are what our builds already do, found by auditing the builds against this standard rather than by writing down what we meant to do. That is the weakest kind of authority here and it is labelled house on every row so it is never mistaken for one of the others. The builds are also one lineage: the second is a port of the first, and the third, which joined the ledger on 2026-09-09 for the rules it introduced, stands on a starter extracted from both. A practice in all of them is one decision that survived being carried forward, not independent confirmations. The one thing to carry out of this section: hiding is not a boundary. Removing a menu takes a screen out of the sidebar and does nothing else at all. The screen is still there at its own URL and the REST route is still answering. A tidy admin reads like a locked one, which is exactly why it has to be written down, where the hiding is configured, that it is not. One clause here is not from the two builds. admin.client-mode originally asked for the single site-wide toggle both of them ship, and Vocalcom had removed exactly that the day before, for a reason worth keeping: WPML will not let an editor open a translated post at all, so Colibrity's own people were given administrator accounts, and the toggle exempted administrators by design. It had become a no-op for the only people it existed to help. The rule asks for the outcome now, and the sentence about not exempting the client's own role is the scar.

Where the data goes once the form is submitted, and how anyone knows it arrived. Most of these are owned by the client or the agency rather than the build, so each one names the artefact that settles it - a header on a received message, a record read back, a countersigned line.

The last day, and the one after it. What gets tested, what gets handed over, and who holds the keys. The credential inventory here is what resolves the owner field for every client-owned rule elsewhere in the standard.

The handoff itself, and the only part of this standard written for a designer rather than a developer. It comes from Colibrity's own checklist, in their words. A rule here is settled by opening the design file, not the repository, so every one of them names the artefact that settles it.

Everything after the label. Accessibility of the field itself is Volume 1's; this is validation, anti-spam, what happens on submit, what happens when submit fails, and where the data goes. Three of these have no component behind them and say so.

Consent, and the record that proves it. The densest section by severity in the whole standard, because the failures are the kind that carry a fine rather than a lower score. Where a rule cites the RGPD or CNIL it says which part is law and which part is guidance, because getting that wrong is worse than omitting the rule.

What the interface has to show when there is nothing, when it is working, when it is broken, and when the visitor is already somewhere. These are the screens nobody designs and everybody ships, and they are where a build stops looking finished.

Local, staging and production, and the traffic between them. This section exists because a copy of a site is a site: the highest-value finding in the audit that seeded this standard was four unprotected copies of a live client site answering on sibling hostnames.

What happens after launch, and whether anyone finds out. Backups nobody has restored, alerts nobody receives and cron nobody watches are all indistinguishable from working ones until the day they are not.

Whether the site can be broken into, defaced, or made to leak what it holds. None of it is visible on the page, which is what makes it easy to skip and expensive to skip: an open write endpoint and a working site look exactly the same.