These are the kinds of features that sound small until you try to make them useful on real pages without being annoying.
Language, headings, and structure work are scattered across A11Y Cat’s later history, and I think that is because they are deceptively awkward areas.
On paper, headings and language checks can sound straightforward. Does the page have a sensible outline? Does the content language match expectations? Are there mismatches in labels or text? In reality, once you put those checks in front of people on real pages, you start running into short UI terms, aria-label text, alt text, body text containers, ordered outline presentation, and the difference between a structural warning and a definite problem.
The commit history reflects that. The language tab gets fully wired on April 11. Then there are fixes for false negatives. Then heuristics get hardened for short UI terms. Then language-localization audit metadata gets refined. Then mismatch detection is fixed for body text containers, aria-labels, and alt text. That is not the path of a feature that was finished on the first try.
The headings side looks similar. There is work on ordered outline handling, deterministic structural checks, and later a simplification of the headings tab into a structure-first pass/fail view. That feels like a product UI learning loop as much as an algorithmic one. It is not just about detecting issues; it is also about how much internal detail the tool should surface before it becomes noisy.
I think these subsystems reveal a lot about the builder. They are not the splashiest features in the README, but they keep getting tuned because they matter for real page review. This is where a tool stops being a headline engine wrapper and starts trying to help with page comprehension.
There is also a good honesty lesson here. Not every structural oddity is a bug. Not every content mismatch should be treated like a hard deterministic failure. The later issue-type and trust-model work make more sense when you look back at these features, because they live right on the edge between useful automation and overstatement.
Visual evidence
There is no reliable dedicated historical screenshot in the repo that isolates the language or headings tab at the exact points discussed here. The closest visible evidence is the general scan-results surface from the extension era:
What I was really learning here
I was learning that “content and structure checks” are not one simple class of work. To make them useful, I had to keep adjusting both the detection logic and the way the UI framed what those checks really meant.
Evidence
- Commits:
b506753– language mismatch and spelling scans wired fullycbfaa90– language false negatives fixed15cd925– short UI-term language heuristics hardened79d1074– language localization audit metadata refinede0c78b0andb70c381– mismatch detection fixed for body text, aria-label, and alt textfdcd694,f4c04da,eed038d– headings and dashboard hierarchy simplified
- Files:
../../src/runtime/modules/language-analysis.js../../src/runtime/modules/headings-analysis.js../../src/runtime/modules/section-order.js../../tests/playwright/representative-pages.spec.js../../README.md
