# Lessons learned and follow-up work

## Outcome

The final two bounded runs completed all six public pages across two organizations. Page content hashes and all deterministic category counts matched between the two runs. The final baseline records 48 static-markup signals: 32 high-impact leads and 16 moderate-impact leads. These are review leads, not confirmed WCAG failures or organization-wide ratings.

Five bounded development and verification runs were made in total: 30 ordinary GET requests, one per manifest URL per run, sequentially with a delay. No links were crawled and no other site paths, forms, accounts, transactions, protected resources, or personal data were accessed. The last two runs are the preserved evidence pair.

## What worked

- An explicit host allowlist, HTTPS-only validation, redirect guard, 20-second timeout, and 2.5 MB response ceiling kept the run narrow.
- A candidate manifest made selection reasons, non-goals, prohibited actions, and denominators reviewable before execution.
- Removing script, style, and inactive template blocks before markup analysis eliminated 17 false-positive signals from embedded code.
- Wrapped-label detection removed two additional false-positive form-control signals.
- Content hashes plus a second clean run made page drift distinguishable from scanner inconsistency.
- Machine-readable results and a plain-language report separate full evidence from maintainer triage.

## Recurring signals to verify manually

- The three NPS pages each returned five social links whose static anchor markup did not expose an accessible name to this parser. A browser accessibility-tree review should confirm whether CSS or client code supplies an equivalent name.
- Wikimedia pages returned app-store or image links without a static accessible-name signal; the `What we do` page also returned six image elements without an `alt` attribute.
- Several heading-level jumps and duplicate IDs were stable across both runs. Component-source inspection should determine whether hidden responsive variants explain any duplicate IDs.
- Donation or mailing-list controls may be visually hidden or labeled after client rendering. Their static label signals are leads with explicit limitations, not final defects.

## What remains outside this baseline

Keyboard focus order, visible focus, modal behavior, screen-reader announcements, client-rendered names, color contrast, zoom/reflow, captions, and real assistive-technology behavior require browser and human review. No legal or conformance conclusion should be drawn from this artifact.

## Executable follow-up task specs

### 1. Browser confirmation pack for high-impact static signals

**Owner:** qualified accessibility reviewer.  
**Inputs:** `audit-results.json`, exact page URLs, and current content hashes.  
**Deliverables:** browser/version matrix, accessibility-tree screenshots or exports, keyboard notes, and criterion-level confirmation table.

Acceptance criteria:

1. Re-check every unique high-impact pattern, deduplicated by component signature.
2. Cover current Chrome, Firefox, and Safari plus at least one screen reader.
3. Record whether page content hashes changed before testing.
4. Mark each signal confirmed, not reproduced, changed, or blocked with evidence.
5. Make no organization-wide or legal conformance claim.

Verification: a second reviewer can trace every decision to a URL, component signature, environment, and evidence item.  
Out of scope: security testing, authenticated flows, form submission, or contacting maintainers.

### 2. Accessibility baseline parser fixture suite

**Owner:** automation contributor.  
**Inputs:** synthetic, license-clear HTML fixtures representing script templates, nested labels, icon links, decorative images, duplicate responsive IDs, and heading jumps.  
**Deliverables:** fixture corpus, expected-results JSON, test runner, and false-positive/false-negative report.

Acceptance criteria:

1. Include at least 30 synthetic fixtures across all eleven baseline categories.
2. Include positive and negative cases for embedded scripts/templates and wrapped labels.
3. Achieve 100% agreement with the committed expected-results file.
4. Run offline without network access or third-party page content.
5. Document unsupported dynamic accessible-name computation.

Verification: run the documented test command twice and compare result digests.  
Out of scope: vulnerability scanning, full HTML specification conformance, or legal WCAG certification.

### 3. Community-project artifact completeness gate

**Owner:** OpenTask platform/documentation contributor.  
**Inputs:** contribution lifecycle schema and examples of accepted contributions with missing `artifactUrl`/`payload`.  
**Deliverables:** proposed validation rule, UI/API copy, migration-safe behavior, and test cases.

Acceptance criteria:

1. An accepted contribution must retain at least one reviewable artifact URL, non-empty evidence payload, or platform-stored file reference.
2. Existing accepted records remain readable and are labeled `legacy_evidence_unavailable` when evidence is absent.
3. Decision UI shows the evidence state before acceptance.
4. API errors identify the missing evidence field and recovery action.
5. Tests cover create, submit, changes-requested, accept, legacy, and revoked states.

Verification: schema tests and lifecycle fixtures pass without rewriting historical decisions.  
Out of scope: changing grant eligibility retroactively or exposing participant-private evidence.

### 4. Drift-aware accessibility rerun summary

**Owner:** reporting-tool contributor.  
**Inputs:** two baseline result JSON files.  
**Deliverables:** deterministic comparison CLI and Markdown summary of content-hash changes, count deltas, added/resolved signals, and incomparable pages.

Acceptance criteria:

1. Match pages by normalized requested URL.
2. Report content-hash stability separately from finding stability.
3. Show category-level count deltas for every page.
4. Never label a changed page as scanner regression without evidence.
5. Include at least twelve positive and negative fixtures.

Verification: expected comparison output matches byte-for-byte on two clean runs.  
Out of scope: automated maintainer outreach or accessibility certification.

## Maintainer outreach draft — not sent

No message was sent. If separately authorized, a maintainer could receive this neutral draft:

> We ran a narrow, public-only static accessibility baseline on several pages and found a few recurring markup signals that may merit confirmation. The report is not a legal or conformance audit and includes exact URLs, timestamps, content hashes, limitations, and suggested checks. We have not interacted with forms or private systems. If useful, we can share the evidence for your team to validate against current component source and browser accessibility trees.