Methodology · scan → diff → PR

How a Sigil pull request lands.

Sigil turns source into evidence. The scanner walks your theme, template, and CSS source and emits a FindingsReport — a list of axe-core diagnostics tagged with the WCAG 2.2 success criterion, the EN 301 549 clause, and a SHA-256 evidence hash, all reproducible against the commit. From that report, Sigil files a single pull request against your own repository: the original line, the proposed fix, the diagnostic that motivated it, and the criterion it meets.

The /methodology page is the citable artifact EU enterprise procurement and counsel ask for before signing. Four sections, one screen, all of it copy/paste-able into an RFP response or a 2025 complaint reply.

Back to homeRequest a pilot →

§ 1 · Reference table

Sigil scanner ↔ WCAG 2.2 SC ↔ EN 301 549

Every rule in the registry is the same row: the axe-core rule fired, the WCAG 2.2 success criterion that maps to it, and the matching EN 301 549 clause. Procurement and counsel can lift this table straight into a 2025 RFP questionnaire.

axe-core ruleDescriptionWCAG 2.2 SCEN 301 549Level
color-contrastText / UI must have sufficient color contrast against its background.1.4.11· Non-text Contrast (AA)§ 9.1.4.11AA
image-altImages and decorative SVGs need an alternative accessible name.1.1.1· Non-text Content (A)§ 9.1.1.1A
labelForm fields have a programmatic label (label[for], aria-label, or wrapping label).4.1.2· Name, Role, Value (A)§ 9.4.1.2A

Compass: WCAG 2.2 cues already in the platform — color-contrast, image-alt, label — drive the closed cohort pilot; later rules extend the same row shape.

§ 2 · Diagnostic format

axe-core diagnostic format + the assistive-tech trace layer

Every Sigil finding carries the axe-core diagnostic fields: a rule id, an impact rating, the criterion tags it maps to, the help text, the help URL, and the rendered snippet that triggered it. The fields are emitted in the order axe-core itself emits them, so a 2025 plaintiff — or a 2025 market-surveillance authority — can compare the Sigil artifact against the open-source reference.

On top of the diagnostic, Sigil stamps a small assistive-tech (AT) trace layer. The trace is not a separate product: it is the provenance metadata that says which screen reader, on which browser, against which operating system, the fix was verified against. Counsel and procurement can copy this into the record without re-validating.

axe-core diagnostic · canonical shape

json · canonical

{
  "id":          "color-contrast",
  "impact":      "serious",
  "tags":        ["wcag2aa", "wcag111"],
  "help":        "Elements must have sufficient color contrast",
  "helpUrl":     "https://dequeuniversity.com/rules/axe/4.10/color-contrast",
  "description": ["color: #aaaaaa;"]
}

# sha256Hex(canonicalize(diagnostic))
# => 7669dce41008043b85f57ebd0d7c2f0874efb41124f8944d5c449f324105a70c
Screen readerBrowserOSWhy it is in the trace layer
NVDAFirefoxWindows 11Attempt notes — the most-cited Windows screen reader at audit.
VoiceOverSafarimacOSAttempt notes — the default macOS reader cited by EU counsel.
VoiceOverSafariiOSAttempt notes — the mobile reader cited by every 2025 iOS RFP.

The AT trace layer is provenance metadata, not a separate product. It tells counsel "this regex was verified against NVDA on Windows / Firefox" — the language a 2025 audit goes after.

§ 3 · PR & commit-message convention

PR & commit-message convention

Sigil files one pull request per remediation, against your own repository, on its own branch — the same cadence your team already runs. The commit message and PR body are written so a defender can read the closure from the git log alone, without opening the Sigil UI. The shape is short and constant so procurement can scan it on a single screen.

commit · subject line

conventional commits

<type>(a11y/<criterion>): bump contrast to meet AA · <short-sha>
The subject names the criterion so a defender reads the closure from the git log alone. The short-sha footer is the first 12 chars of stableId().

pull request body

example remediation

Criterion: WCAG 2.2 SC 1.4.11 (level AA) · EN 301 549 § 9.1.4.11
axe-core rule: color-contrast
Evidence hash: 7669dce41008043b85f57ebd0d7c2f0874efb41124f8944d5c449f324105a70c
Source: tests/unit/sigil/fixtures/sample-theme/global.css:2
Patch: `color: #aaaaaa;` → `color: #0a0a0a;`

Reproduce:
  $ git checkout 1ec4858f
  $ pnpm test:sigil

This commit closes the SCC finding for this criterion; the VPAT / ACR row
for 1.4.11 is reissued on the next deploy.

§ 4 · Immutable evidence trail

Immutable evidence trail · what Sigil hands the regulator

“Every axe-core diagnostic is canonically serialized, SHA-256 hashed, and recorded against the commit. The artifact Sigil hands the regulator is reproducible from the diff alone.”
Sigil evidence-trail contract — every finding is canonically serialized, hashed, and recorded against the commit.

The evidence trail is the artifact Sigil hands the regulator. It has three pieces, and each one is reproducible from the commit without trusting Sigil:

  1. 01

    SHA-256 of the canonicalized diagnostic

    sha256Hex(canonicalize(diagnostic)) — keys sorted, JSON-encoded, hashed. Two runs of the same diff produce the same 64-character hex string; tampering breaks the hash.

  2. 02

    stableId(source/file/line/ruleId/severity)

    A 64-character id derived from where the diff lands and which rule fired. Counsel can replay it from the commit, no server lookup required.

  3. 03

    Audit trail: the hash in the commit footer + PR body

    The evidence hash is recorded twice — as the commit-message footer and as the first line of the PR body — so a defender can read it from either artifact without re-running the scanner.

Tail call

A 30-minute pilot scope, scoped to your repo.

We triage every request by stack, repo, and jurisdiction. Three audit-grade engagements per quarter — bring a procurement record or a 2025 complaint and we will show you the same record the Sigil scanner produces in your own repo.

Request a pilotOpen /how-it-works