What's changed

The gate now reads the code and the server as well as the pages. Eight more rules are settled by a machine: the block file triple, JavaScript hooks on data attributes, BEM naming, REST routes against the handover's public-route list, upload types and the uploads directory's execution rule read off the server, the enforced CSP baseline, structured-data values against the page they describe, and staging parity with production. Five of them move to automatic; the REST and upload checks read a project's own handover document, so they stay assisted.

A form's real response is now followed. The gate sends a marked probe the site recognises only off production and only with a secret the staging config holds; the form answers it as it would a real submission and stores and sends nothing. Before it sends one, the server has to acknowledge the probe on a request that cannot store.

Two measurements the gate was getting wrong are fixed. PageSpeed's image-delivery insight reads correctly sized responsive images as oversized under its mobile emulation (a known Lighthouse bug), so every image it flags is now re-measured from its own slot in Chrome. And eight smaller gaps from the last round are closed, from reading fonts in imported stylesheets to requiring a form page and a listing page before the accessibility scan can pass.

The gate now opens every sampled page in a real browser. Until today it read the HTML the server sent and never ran the page, so every rule about what a visitor actually sees after the scripts have run was left to a person. It now drives Chrome, and a rule it checks this way is settled whole or not at all: no Chrome, a timeout or a page that did not load reads NOT CHECKED, never pass. Forms are pressed with every submission caught before it leaves the browser, so a staging site stores and sends nothing because of it.

Moved to machine checks: the automated accessibility scan at WCAG 2.1 A and AA (run after scrolling, so content that fades in is measured as a visitor reads it) and the page landmarks. Five form rules follow: inputs large enough that a phone does not zoom, the right keyboard and autofill on every name, email and phone field, errors shown when a field is left rather than while typing, errors announced with focus on the first bad field, and no personal detail ending up in a web address after any form is sent.

And five about how the site behaves: tap targets large enough on a phone, a console with no errors and no failed requests, nothing left invisible after following a link to the middle of a page or pressing back, page changes that clean up after themselves, and a page reached by a transition that matches the same page loaded fresh.

Two more are read straight off the page the server sends: link text that makes sense on its own (no bare "read more", and no two links with the same words going to different places), and web fonts kept small, in the modern format, with only one loaded ahead of time.

The speed snapshot now keeps more of what Google's PageSpeed reports, so five speed rules are read from it: nothing holding up the first paint beyond the site's own styles, images sized and compressed for where they are shown, video kept off the first load, every third-party script accounted for, and the largest image on screen fetched first while the rest wait until they are scrolled to.

The three security rules that cite OWASP now cite the current version of it. The Application Security Verification Standard moved from 4.0.3 to 5.0.0, every chapter was renumbered, and this standard was still quoting the old one. It now quotes 5.0.0, with the clause, the level and the sentence checked against the document on the day.

Two of the three read better for it. Our rule against executable uploads asks that a PHP file dropped into the uploads folder cannot run; 4.0.3 only forbade files running as HTML or JavaScript, so the part that matters most sat on inference. 5.0.0 says "server-side program code" outright, and separately names SVG files carrying scripts, which is the specific way this goes wrong on a site that lets contributors upload artwork. Our rule against error pages leaking the install greps for the words "Stack trace"; 4.0.3 asked only for a generic message, and 5.0.0 names stack traces itself.

One reads worse, and it is worth stating plainly. The rate-limit rule used to rest on the only hard number in the whole of ASVS 4.0.3. 5.0.0 removes numbers as a matter of policy and asks instead that you document your own thresholds and then implement what you documented. So the figure in that rule, 20 attempts a minute, is now ours alone with no outside standard behind it. That is a fair trade rather than a loss, because a standard that writes its thresholds down is exactly what the new clause asks to exist, but nobody should read the citation as OWASP endorsing the number.

Checking the move turned up something else: the old links claimed to be pinned to an immutable version tag and were pointing at a branch, which had already moved on three years. Nothing we quoted had changed, so no citation here was ever wrong - but the reason given for why it could not go wrong was. The new links name a real tag.

Every rule now says what goes wrong without it. One sentence on all 163, on the row, in both lists, in the spreadsheet and in the printable document. It is the question the standard never answered: it could tell you what to do, how it would be checked and which document it came from, and not why you should care.

They are not written from opinion. Each one comes out of the audits behind the last three revisions - what the source actually requires against what we added, and what the two delivered builds we measured really do. An adversarial re-read changed 18 of them, and those corrections are the useful part: four stated a mechanism backwards, six made a claim the source does not support, and eight named a failure that belonged to a different rule. Three examples of what came out: an invented byte ratio, a penalty that applies to an enforcement route most clients are not on, and the word "unreadable" attached to a measurement of 4.37:1, which is under the bar but not illegible. Overstating a case in our own favour is the failure we watch for hardest.

Twelve new explainers, all in the two sections that had none: consent records, the cookie banner and the tag that fires before it, email deliverability, submissions that survive a dead mail relay, validation and spam, the page before the JavaScript arrives, the admin you actually receive, colour that passes, what a WordPress site hands out before anyone logs in, an enforced Content-Security-Policy, production data on a laptop, and backups and recovery. 42 rules now carry one.

The decisions we take on our own authority are published, at /decisions/. It was the only kind of source on this site you could not open, which is backwards: a rule backed by WCAG survives being taken on trust and a rule backed by nothing but our judgement does not.

And the page budget rule was changed rather than waived a sixth time. It capped DOM elements, which is a stand-in for how much work a browser does, and this standard already measures that work directly. A page whose length is set by how much content it holds can now pass by measurement instead. This site is the first thing measured under it and the figures are on the self-check page.

Every rule now names the exact clause it rests on - the success criterion, the article, the documentation page - and links straight to it. 163 of 163, with the document's own sentence recorded behind each one so anybody can check it rather than take our word for it.

The finding is worth stating plainly before you read further: 99 of the 100 citations are partial. Not one rule in this standard says exactly what an outside document says. Every one adds a ratio, a threshold, a viewport, a tool or a deadline that WCAG, the GDPR, Google or the HTML specification does not carry. That is what a delivery standard is for - but it means this document is an argument rather than a summary of anybody's requirements, and it should be read as one.

Checking them changed things. Ten rules turned out to cite a document that does not contain them and were moved to documents that do. One was withdrawn outright: the account-inventory rule cited the Twelve-Factor App, which is about application architecture and says nothing about domain registrars, and nothing else backed it either. It is on the not-adopted page with the reasoning, and your handover item now shows as partly covered rather than fully.

And four rules were wrong about accessibility law in our own favour. The worst: we asked for a pause control on media over five seconds, where WCAG sets three seconds for auto-playing audio at Level A. We were requiring less than the law while citing it. Fixed, along with a misstated tap-target spacing test and a claim that WCAG 2.1 requires the autocomplete attribute, which it never mentions.

The accessibility bar - WCAG 2.1 AA, the European Accessibility Act, and which French regulator enforces what - is now stated on the sources page instead of being buried.

Every item in both your documents now says what became of it, on one page: /checklist-map/. Mariya's checklist is 186 boxes and the technical SEO grid is 159 control points. 290 of them became rules, 29 were declined in public with the reason, 4 are half of each, and 28 are carried by nothing in this standard - and that last column is why the page exists. Nine of the 28 are gaps worth closing, including a per- image byte cap, X-Robots-Tag on non-HTML URLs, and requiring exactly one sitemap source. The rest are controls this standard deliberately refuses, and each one says so.

The page reads backwards, and that is the point of it. Every other page here starts from a rule and names its source, which looks finished from the rule's side however much of the document nobody read. An item nobody acted on can only surface from this direction.

48 rules rested on one of your documents and none of them named the item. All 48 do now. 11 quote it exactly, 34 say "in part" because the standard sets a measurable the document does not, and 3 turned out to cite something their source does not contain - those were re-sourced rather than quietly kept. Two now cite our own delivered work, labelled as a house rule; one found its real source in the SEO grid and is better cited than before. Clause coverage went from 14 rules to 62.

Neither document is named to a client here any more. The SEO grid is an outside agency's audit of one delivered site, and until today this site published the site's domain on four rule rows and a file path from one laptop on /sources/. Both are gone.

The standard now covers the wp-admin your client receives. It had 156 rules and not one of them was about the screen the client actually opens every day, for years after we stop being paid. Everything in it described what a visitor sees, what a crawler sees or what a server sends. Five new rules close that: the admin is trimmed and the trim can always be undone, what the client must not do is refused rather than hidden, field definitions live in code, one control writes one setting, and on a multilingual project the admin reads in the language the editor set.

They come from our own delivered work rather than from a specification, and they say so on the row: every one is labelled a house rule, which is the weakest kind of authority here. The section states its own limit too, because both the builds it came from state it - hiding a menu is not a security boundary, the screen is still there at its own URL.

Two more rules came out of the same pass. Every published URL has to answer at its own address: a page can be published, listed in the sitemap, linked from the main navigation and still return 404, and nothing else in a build reports it. And a deliberate code split has to be asserted in the build, because a bundler exits 0 on an import it cannot resolve, so a broken split ships green and ships smaller - passing the byte budget on the way past.

163 rules now, 47 of them blockers.

Every rule now says where it came from, and you can click through to it. Each one opens with the kind of authority behind it - law, a regulator, a published standard, vendor documentation, a client document, or our own house practice - then names the document and links it where a reader can follow the link. The new Sources page lists every document once, with the rules it authorises.

That distinction is the point. Of the 156 rules, 7 rest on law and 3 on the regulator, 35 on published standards, 45 on vendor documentation, 48 on a document Colibrity wrote, and 18 on our own repositories. Those last two are the ones worth arguing about, and until today nothing on the page told you which was which.

Six rules name the exact clause they rest on. The other 150 say "clause pending" rather than leaving a blank, and the count is printed on the Sources page. Filling them in is the next piece of work, and it is deliberately visible until it is done.

Also: every rule now shows whose job it is and who can prove it, and both are filterable. The intake at the top of the checklist explains what each toggle actually switches off. Two questions there were narrower than the rules behind them - one about CRMs that would have quietly dropped a blocker on any project posting to a webhook, and a no-JavaScript blocker that disappeared if you said the site had no scroll animations. Both fixed.

The standard is no longer a front-end standard. It now covers a project from the design handoff to the day the client takes the keys, and it went from 69 rules to 156 across four sections: front-end, SEO and indexation, delivery and compliance, and security, operations and environments.

Most of it comes from two documents Colibrity supplied. Mariya's website checklist is the source of the whole delivery section, including its design and UI-kit rules, which are the only part of this standard written for a designer rather than a developer. A third-party technical SEO audit of one delivered site is the source of the new indexation rules, and it stays the test those rules have to pass: a grid that cannot rediscover a real audit's findings is not a grid.

Two new fields on every rule. role says who does the work, so a designer can filter to the nine rules that are theirs instead of reading past 130 that are not. owner says who can prove it: the build, the agency, or the client. Fourteen rules are the agency's and eight are the client's, and each of those names the artefact that settles it, because a rule nobody can settle sits unverified forever and drags every project's verdict down with it.

Thirty requirements from those two documents did not become rules, and they are published at /not-adopted/ with the reason for each. A requirement quietly skipped is one the client still believes is being met. Three are worth reading: the IP address in the consent log, the Core Web Vitals thresholds, and rel=prev/next.

The whole standard is now downloadable as one document and as a CSV, and /print/ is a single page built for Print to PDF. Same registry, so none of them can disagree with the site.

A project can now be graded against the standard, and the first one has been. There is a record per project at /projects/, and Vocalcom is on it.

It is the same mechanism this site already used on itself. Every rule has to be named - as proved, not applicable, waived, unverified, or failing - and the build refuses to publish until all of them are. There is no default, so nothing passes by nobody having looked at it. A project's record lives in that project's own repository, beside the code that satisfies the rules, which is what stops it becoming a document somebody updates twice and then forgets.

Vocalcom reads FAIL, and that is the record working rather than the project being bad. Two blockers are open. One is the primary button's contrast, which is already with you as a decision - Figma's own light label on Corail measures 3.17:1 against the 4.5:1 the rule asks, and the hover and pressed states are lighter still. The other is a single inline event handler on an internal styleguide page. Eleven rules are proved with the evidence named, and fifty-six are unverified, each with the specific thing that would settle it - a build three weeks old with no production host yet has not been measured for speed, validated, or run through an accessibility tool, and saying so is more use than a number that flatters it.

A fifth verdict had to be added to say that. The four this site used - proved, n/a, waived, unverified - had no way to state a blocker that is open, because this site can always fix or waive one before publishing. A project under review cannot, and "unverified" would have understated a defect that has been measured. This site still may not declare a failure of its own; a test enforces it.

Three corrections came out of reading the above, and two of them are ours. This site had been declaring its own noindex as a waived blocker while How this runs says a blocker cannot be waived - two published pages contradicting each other. It is graded as not applicable now, which is the honest reading: the rule asks that production be indexable and staging not, and this is a review artefact with no production stage at all. The worked example of a waiver is still here, on seo.robots-txt, which is a required rule and legitimately waivable.

colibrity.filter-url-state was asking for the wrong thing on its own row. The measurable read "replaceState, cleared parameters deleted" while the instruction and the acceptance test underneath it described the outcome and said outright that client-rendered and server-rendered listings get there differently. They do: on a server-rendered filter the form submit pushes its own history entry regardless, so replaceState cannot deliver the rule's own acceptance test and the starter component uses location.replace() instead. The row now states the outcome. Nothing about what the rule requires has changed.

And a rule now has to state an outcome rather than name an API. Enforced by the test suite, on the measurable only, because a rule may legitimately be about an API in its acceptance prose. That is the guard the first one needed and did not have.

It is a checklist you can work down now, not a document you read. Same rules, same ids, rebuilt around actually using them on a project.

The site opens on the checklist itself. There were three pages of prose about how the standard is generated before you reached a single rule, and the sections had a page each, so you had to know which one owned your question before you could look it up. Both are gone: one list, ordered the way a project is built, from the design stage through to handover. The section a rule belongs to is a tag on the row.

Every rule is one line with a tick box. Its name, the measurable next to it - 4.5:1 body, 3:1 large text and UI rather than "meets AA" - and the one badge that changes what you do about it. The instruction, the acceptance test and the explainer are all still there, one click down. Ticks are remembered against a project name you type once, and there is a button that copies the whole list out as markdown for a repository, a pull request or a ClickUp task.

Say what the project has, and the rest disappears. Around a fifth of the rules only apply to a project with filters, pagination, more than one language, video, a modal, or a site it replaces. Switch those off at the top and both the list and the count follow. Nothing is hidden until you say so.

Two of Michael's original asks survive unchanged: two lists generated from one set of rules, and the same id on both sides. The old addresses redirect, one hop each.

Corrections, found by checking rather than by reading. Three things this document said were wrong, and it publishes them, so they are recorded rather than quietly fixed.

The accessibility section named ARCEP as the French enforcement body. ARCEP regulates telecoms. Digital accessibility sits with ARCOM, under article 47-1 of the 2005 disability law, created by the ordonnance of 6 September 2023. The same paragraph gave a single penalty of EUR 75,000, which is not a figure that exists anywhere: it is ARCOM's two real maximums, EUR 50,000 for non-conformity and EUR 25,000 for the declaration obligations, added together. It also implied ARCOM was the relevant body for a typical client, when for most it is the DGCCRF under the consumer code.

The site also failed two of its own rules. Not one of its 25 table header cells carried scope, which html.lists-and-tables requires, and every page shipped the same meta description, which seo.title-description forbids. Both are fixed.

And the self-check page was flattering itself. Any rule nobody had written about counted as a pass, which put 33 unexamined rules in the passing column on a page whose whole argument is that it declares its own record. There is no default now: every rule has to be graded, and unverified - the same verdict the gate uses, which never counts as a pass - is what 22 of them honestly are until they are re-checked against the rebuilt page.

The SEO section is open. The second section of the standard is live at /seo/, and it starts deliberately small: three rules, all blockers, all about the two things that cost a client an index rather than a score.

One of them comes from an audit rather than from us. A technical SEO audit of a live client site this July found four hostnames - admin, dev, ETL and a project subdomain - all serving full, unprotected, indexable copies of the production site. The site itself was correct. The defect was entirely outside the repository anyone was working in, which is why it survived to an external audit. That is now crawl.sibling-hosts.

The other two are about replacing a site that already exists: counting its indexed URLs before anyone estimates the job, and mapping every one of them to a single 301. The front-end section already said to map the URLs. These say how many there are and what mapped has to mean, because that is the part that decides what the work costs.

More SEO rules follow after mid-September. The section is honest about being unfinished rather than padded to look complete.

It is no longer a front-end standard. The document is now one standard with a section per area of delivery, and front-end is the first of them. SEO is being written next, and back end will follow. Nothing in the front-end rules changed: both checklists are identical to yesterday's apart from their title line.

What this means in practice is the address. The site now lives at https://standard.tastysites.pl/ and the front-end checklists moved to /front-end/build/ and /front-end/gate/. The old address redirects, so an existing link still works.

One real bug was found while moving things. On all twelve explainer pages, the "Applies to" links back to the checklist pointed one directory too high and had been returning 404 since the site first went up. They work now, and a test fails if it happens again.

The filtering component now exists. The correction below said two starter components had been claimed before they were built. Both are now built, verified and named again: the reduced-motion helper, and today the filtering and pagination component. The production gate no longer lists anything as still being built.

Building it also improved two rules. Both said to use history.replaceState for filter changes. That is right when the filtering happens in the browser, but wrong when the server renders the filtered page: there a filter change is a real navigation, and replaceState cannot stop the back button filling up. Both rules now say so and name the alternative. What the rules require has not changed - only the advice on how to meet them got more accurate.

Correction. Two rules said a component in my starter theme already handles them for you. I audited the theme against all nine such claims and two were not true: the filter URL-state module and the shared reduced-motion helper do not exist yet.

Those claims are removed. The rules are unchanged and still stand - they just have to be met by hand until the components ship, and the production gate now lists what is still being built so it is visible rather than assumed.

The audit was worth running for its own sake. Five claims checked out, one of them stronger than described, and it found a real accessibility bug in the theme: decorative looping animation kept running for visitors who ask for reduced motion. Being fixed in the same work.

Every open question now has its own Answer question N link, so the things blocking this document are as easy to respond to as a wording note.

Feedback is moving off email. The plan is one publicly shareable ClickUp form: no account and no login to comment, the link carries the rule id for you, and each comment becomes a task with the rule, the page and your proposal already on it. That puts the review history in the same place as the project template.

One thing blocks it, and it is now question 9: my ClickUp access to your workspace is guest-level with a single list shared, and a guest cannot create the list or the form. The same limit blocks building the project template there. Until it is sorted the comment links still open an email, which works but makes me the middleman.

First published version. 66 rules across six dimensions: HTML structure, SEO, front-end practices, Colibrity internal practices, accessibility and performance.

Two things worth flagging before you read further.

The internal practices section is the shortest one, because it is seeded from the two examples in your brief and nothing else. It is the section that needs you most - see the open questions.

Your pagination example needs a pattern change, not a parameter. The listings I have built for you use an offset load-more button, which has no pages at all, so there is nothing to put a number on and everything past the first batch is invisible to search engines. The rules below specify real server-rendered pagination with load-more layered on top. That is more work than adding a parameter, so it is worth confirming that is what you meant.

The filter example, by contrast, is already solved in one of the delivered projects, and that implementation is what the rule now describes.