A five-check gate is the only docs accessibility test that will survive contact with CI

Ninad Pathak has published a documentation accessibility release checklist, on dev.to and on his own site, that sorts checks into two piles: repeatable source failures a parser can catch in generated HTML, and reader-path checks only a person can complete on the rendered page ^[1][4]. The useful part is not the advice, which is largely conventional, but the boundary: he wrote a narrow checker, ran it against a broken fixture and its repaired version, and named the small set of failures worth blocking a deploy over ^[2][3].

The script flags five things: missing image alternatives, vague link names, heading jumps, tables without header cells, and code elements without a language class ^[3]. That is five, and the number matters, because a five-check gate is short enough to run on every build and specific enough that a failure tells the author what to fix. It runs as a command line invocation against a rendered page file, from a disposable workspace, and prints a PASS line naming the file it checked; a failure is supposed to name the structural issue so the author does not have to guess ^[5][6][24].

Each of the five maps to a fact in the document model rather than an opinion about it. Google's guidance recommends descriptive headings in a logical hierarchy, and Harvard's structural guidance states the consequence plainly: assistive technology can navigate structure only when the markup carries it ^[7][8]. So one page title, then levels chosen in dependency order, never for font size, since CSS can change appearance without breaking the outline ^[9]. A data table needs header cells, and a table used for layout invents a relationship a screen reader will announce as data ^[11]. A code element needs the fence or class that declares its language, with prerequisites and the success signal in nearby text rather than an image caption ^[15]. Pathak's argument against screenshots of commands is mechanical, not aesthetic, and he cites Google's guide: text can be copied, enlarged, searched, translated, and read aloud ^[14].

Everything else in the checklist is a human job, and the article is honest that automation cannot do it. A parser cannot tell whether focus is easy to find or whether a code sample wraps into unreadable fragments ^[22]. It cannot tell that an alt attribute holds a copied caption instead of the information the reader needs, or that the screenshot's actual payload was a 200 response that belongs in adjacent text ^[18]. It cannot distinguish a decorative image, which should carry an empty alternative, from a complex diagram that needs adjacent prose or a data table, a distinction the article draws from Open edX's checklist ^[19]. It cannot notice that red is the only thing saying the request failed ^[20]. And it cannot read the headings without their paragraphs to check that a reader can find where to begin, what happens next, and where to verify success ^[10].

Watch the failure text, not the pass rate. A page can clear all five checks and still leave a reader unable to finish the task, which is the original failure mode the checklist describes ^[23]. Pathak points to the WCAG 2.2 Quick Reference for the underlying success criteria, while noting the standard is a reference point and not a substitute for attempting the page's real task ^[21]. Also watch scope creep: the moment the gate grows past defects with unambiguous repairs, it becomes the broad audit nobody runs.