pour-engine 1.31.3 → 1.33.0

package/config/project.config.js

@@ -6,6 +6,6 @@
 export default {
   engine: {
     name: 'pour engine',
-    version: '1.31.3',
+    version: '1.33.0',
   },
 };

package/engine/rules/wcag/1.3.1-definition-list.js

@@ -11,12 +11,28 @@ export default {
   selector: 'dl:not([role])', // a role attribute replaces the dl semantics
   evaluate(element) {
     const invalid = [...element.children].filter((child) => !ALLOWED.has(child.tagName));
-    if (!invalid.length) return { status: 'pass' };
-    const tags = [...new Set(invalid.map((child) => `<${child.tagName.toLowerCase()}>`))].join(', ');
-    return {
-      status: 'fail',
-      message: `This <dl> contains ${tags} directly — only <dt>, <dd> (optionally grouped in <div>) are allowed, otherwise the term/description pairing breaks.`,
-      fix: 'Restructure the list into <dt>/<dd> pairs, or use a different element.',
-    };
+    if (invalid.length) {
+      const tags = [...new Set(invalid.map((child) => `<${child.tagName.toLowerCase()}>`))].join(', ');
+      return {
+        status: 'fail',
+        message: `This <dl> contains ${tags} directly — only <dt>, <dd> (optionally grouped in <div>) are allowed, otherwise the term/description pairing breaks.`,
+        fix: 'Restructure the list into <dt>/<dd> pairs, or use a different element.',
+      };
+    }
+    // A <div> child is only a valid wrapper when it holds the dt/dd group
+    // ITSELF (HTML: each div contains one or more dt followed by one or
+    // more dd). Pairs buried another level down (dl > div > div > dt) fall
+    // out of the dl's content model, so the term/description association is
+    // no longer guaranteed to assistive technology.
+    const emptyWrappers = [...element.children].filter((child) =>
+      child.tagName === 'DIV' && ![...child.children].some((inner) => inner.tagName === 'DT' || inner.tagName === 'DD'));
+    if (emptyWrappers.length) {
+      return {
+        status: 'fail',
+        message: `${emptyWrappers.length} <div> wrapper(s) in this <dl> hold no <dt>/<dd> directly — the term/description pairing breaks when the pairs sit deeper than the wrapper.`,
+        fix: 'Make each <div> child of the <dl> contain its <dt>/<dd> pair directly, or flatten the pairs into the <dl> itself.',
+      };
+    }
+    return { status: 'pass' };
   },
 };

package/engine/rules/wcag/1.3.1-table-headers.js

@@ -26,11 +26,13 @@ export default {
     if (!isGrid || textCells < 4) return { status: 'pass' }; // likely layout or trivial
     // Nested tables are the signature of legacy LAYOUT markup, not data —
     // asserting "missing headers" there flags email-style scaffolding. A
-    // human can tell in a glance; the machine can't.
-    if (!element.querySelector('th') && element.querySelector('table')) {
+    // human can tell in a glance; the machine can't. The signature reads in
+    // both directions: a table INSIDE another table (Hacker News's story
+    // list inside its page-scaffold table) is the same legacy layout.
+    if (!element.querySelector('th') && (element.querySelector('table') || element.parentElement?.closest('table'))) {
       return {
         status: 'incomplete',
-        message: 'This table has no header cells but contains nested tables — a layout-table signature. If it really presents data, mark its header cells with <th>; if it is layout scaffolding, add role="presentation".',
+        message: 'This table has no header cells and is part of a nested-table structure — a layout-table signature. If it really presents data, mark its header cells with <th>; if it is layout scaffolding, add role="presentation".',
       };
     }
 

package/engine/rules/wcag/1.4.1-link-in-text-block.js

@@ -51,11 +51,38 @@ export default {
       // A clear weight difference is a non-colour distinction too.
       if (Math.abs(weight(s) - weight(parentStyle)) >= 300) return { status: 'pass' };
     }
+    // A weight step of 200–299 (600-semibold links in 400 prose, the common
+    // case) is a REAL non-colour cue, just not a clear one: whether it reads
+    // as "bolded" (F73's word) depends on the face and the size, which is a
+    // judgment by eye, not arithmetic. Adjudicated on the 2026-08-16 corpus
+    // run (PostgreSQL ×32, visibly semibold): asserting fail overclaims,
+    // passing waves through faces where the step is invisible — so it goes
+    // to review. Below 200 the step is imperceptible at body sizes and earns
+    // nothing.
+    const weightStep = Math.max(...cueBearers.map((s) => Math.abs(weight(s) - weight(parentStyle))));
 
     const linkColor = parseColor(style.color);
     const textColor = parseColor(parentStyle.color);
     if (!linkColor || !textColor) return { status: 'pass' };
 
+    // A link styled to look NO different from the surrounding prose is not
+    // a 1.4.1 failure — Understanding 1.4.1, in its own words: "a hyperlink
+    // which has been styled to appear no different than neighboring static
+    // text would not fail this success criterion, as there would be no
+    // color differentiation between the actionable hyperlink text and the
+    // adjacent static text." Colour conveys nothing when there is no colour
+    // difference. A terrible link, but no WCAG criterion requires links to
+    // look like links, and asserting one invents spec text (measured live:
+    // hsbc.co.uk's footer, rgb(215,216,214) on both link and prose).
+    // Channel equality, NOT the luminance ratio: a hue-only difference at
+    // equal luminance also lands at 1.00:1, and that is the clearest F73
+    // failure there is — the two cases are opposites and the ratio cannot
+    // tell them apart.
+    if (linkColor.r === textColor.r && linkColor.g === textColor.g
+      && linkColor.b === textColor.b && (linkColor.a ?? 1) === (textColor.a ?? 1)) {
+      return { status: 'pass' };
+    }
+
     const ratio = contrastRatio(linkColor, textColor);
     // WCAG technique G183: 3:1 against the surrounding text is a sufficient
     // colour difference for identifying a link.
@@ -89,6 +116,13 @@ export default {
       }
       if (!sharesLine) return { status: 'pass' };
     }
+    if (weightStep >= 200) {
+      return {
+        status: 'incomplete',
+        message: `This link has no underline and only ${ratio.toFixed(2)}:1 colour difference from the surrounding text, but its font weight differs from the prose by ${weightStep}: a visible non-colour cue that falls short of a clear bold step. Judge by eye whether the weight alone identifies it as a link in this face and size; if it does not, this fails SC 1.4.1.`,
+        fix: 'Underline links inside text (text-decoration: underline), raise the weight difference to a clear bold step, or add another non-colour indicator.',
+      };
+    }
     return {
       status: 'fail',
       // The measured fact is the ratio against G183's threshold, and that is
@@ -97,7 +131,7 @@ export default {
       // staying perfectly distinct to most people, including most red-green
       // colour blindness, where the red darkens and the gap widens.
       message: ratio < 1.01
-        ? 'This link has no underline and the same colour as the surrounding text, so there is nothing at all to mark it as a link.'
+        ? 'This link has no underline and its colour differs from the surrounding text in hue alone, with no luminance difference: the distinction disappears entirely without colour vision, the exact failure F73 describes.'
         : `This link has no underline and only ${ratio.toFixed(2)}:1 colour difference from the surrounding text, below the 3:1 WCAG technique G183 asks for when colour is the only thing marking a link.`,
       fix: 'Underline links inside text (text-decoration: underline), or add a non-colour indicator.',
     };

package/engine/rules/wcag/2.5.8-target-size.js

@@ -98,7 +98,22 @@ function reachableRects(element, rect) {
     if (x < 0 || y < 0 || x >= win.innerWidth || y >= win.innerHeight) continue;
     const stack = doc.elementsFromPoint(x, y);
     const index = stack.indexOf(element);
-    if (index < 0) continue; // this fragment isn't hit-testable; try the next
+    if (index < 0) {
+      // The probe ran and the stack came back without the element.
+      // elementsFromPoint reports covered elements too, so for a light-DOM
+      // element this is not don't-know but a definitive no: nothing at this
+      // point accepts a pointer for it. The sr-only WRAPPER pattern makes
+      // exactly this shape — the clipped 1×1 box is the wrapper, the skip
+      // link inside keeps its full-size rect, and every self-applied hiding
+      // check (own rect, own opacity, own clip) passes; that phantom rect
+      // crowded frame.work's 160×21 header wordmark out of the spacing
+      // exception its layout plainly earns. Shadow-tree elements are
+      // invisible to the document's hit-test by design (the stack shows
+      // their host), so absence proves nothing there and the fragment keeps
+      // the benefit of the doubt.
+      if (element.getRootNode() === doc) testable = true;
+      continue;
+    }
     testable = true;
     // Anything above it that is part of the same control is not an
     // obstruction: a button's own icon paints over the button, an overlay
@@ -107,9 +122,9 @@ function reachableRects(element, rect) {
       reachable.push(fragment);
     }
   }
-  // Nothing could be probed at all (entirely out of viewport,
-  // pointer-events: none, nothing laid out): the OCCLUSION question is
-  // unanswerable, and don't-know must not silence a finding — but the
+  // Nothing could be probed at all (entirely out of viewport, or a
+  // shadow-tree element the document's hit-test cannot see): the OCCLUSION
+  // question is unanswerable, and don't-know must not silence a finding — but the
   // fragment GEOMETRY is measurable regardless, so the fragments stand,
   // never the bounding box. A wrapped link's box is mostly leading and
   // line-gap no pointer can activate; counting that empty space as

package/engine/rules/wcag/4.1.2-aria-allowed-attr.js

@@ -68,7 +68,7 @@ export default {
     const names = disallowed.map((n) => `aria-${n}`);
     return {
       status: 'incomplete',
-      message: `${names.join(', ')} is not supported on role "${role}", so the browser drops it and assistive technology never sees it. Nothing is announced wrongly, but nothing is announced at all. Does this element really have that state? If it does, it is invisible to a screen reader and this is a 4.1.2 failure. If it does not, the attribute is simply stray and no one is affected.`,
+      message: `${names.join(', ')} is not supported on role "${role}", so the browser drops it and assistive technology never sees it. Nothing is announced wrongly, but nothing is announced at all. Does this element really have that state? If it does, it is invisible to a screen reader and this is a 4.1.2 failure. If it does not, the attribute is simply stray and no one is affected. Invalid markup is not by itself a WCAG failure: the criterion that policed validity, 4.1.1 Parsing, was removed in WCAG 2.2 (w3.org/WAI/WCAG22/Understanding/parsing.html), so what decides this is whether the state reaches users, not the syntax.`,
       fix: `Move ${names.join('/')} to the element whose role supports it, usually the control that toggles this one, or remove it if the element has no such state. Adding a role to this element to make the attribute legal is rarely right: the host language restricts which roles each element may take.`,
     };
   },

package/engine/rules/wcag/4.1.2-aria-label-misuse.js

@@ -72,7 +72,7 @@ export default {
         })();
     return {
       status: 'incomplete',
-      message: `${attempt} on a plain <${element.tagName.toLowerCase()}> is prohibited by ARIA: this element's role does not support naming, so although many browser and screen reader pairings announce the label today, that support is not guaranteed anywhere and can differ between assistive technologies. Where it is announced it replaces the element's visible text; where it is not, users get the visible text alone. Check both presentations read correctly, and that nothing here relies on the label being heard.`,
+      message: `${attempt} on a plain <${element.tagName.toLowerCase()}> is prohibited by ARIA: this element's role does not support naming, so although many browser and screen reader pairings announce the label today, that support is not guaranteed anywhere and can differ between assistive technologies. Where it is announced it replaces the element's visible text; where it is not, users get the visible text alone. Check both presentations read correctly, and that nothing here relies on the label being heard. Prohibited markup is not by itself a WCAG failure: the criterion that policed validity, 4.1.1 Parsing, was removed in WCAG 2.2 (w3.org/WAI/WCAG22/Understanding/parsing.html), so what decides this is what users actually hear.`,
       fix: 'If this element must reliably announce something of its own, give it the role it is playing (a landmark, group, or widget role) so the name is legal and exposure is guaranteed — or move the spoken text into visible or visually-hidden real text. If the label is stray, remove it. Do not add a role solely to legalise the label.',
     };
   },

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pour-engine",
-  "version": "1.31.3",
+  "version": "1.33.0",
   "description": "Accessibility (WCAG 2.2) audit engine written from the W3C specifications — runs entirely in the browser, no dependencies.",
   "type": "module",
   "main": "engine/index.js",