feat(atomic-a11y): openACR schema validation#7164
Draft
y-lakhdar wants to merge 4 commits intofeat/a11y-openacrfrom
Draft
feat(atomic-a11y): openACR schema validation#7164y-lakhdar wants to merge 4 commits intofeat/a11y-openacrfrom
y-lakhdar wants to merge 4 commits intofeat/a11y-openacrfrom
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds schema validation to the OpenACR pipeline. Every generated
openacr.yamlis now validated against the official GSA JSON Schema before VPAT generation proceeds.Why validation over type generation
2 approaches were evaluated to stay aligned with the official Open ACR schema, and chose runtime schema validation. Here's why:
Type generation solves the wrong problem. It ensures our TypeScript compiles against the schema shape at build time, but doesn't verify that our actual YAML output conforms at runtime. A refactor could introduce a bug where
resolveConformance()returns an unexpected value or a required field is conditionallyundefined, types wouldn't catch it, validation does.The generated types are too loose to be useful. The GSA schema marks almost everything optional (
required: ["title", "product", "author"]). Auto-generated interfaces would havestring | undefinedon nearly every field, forcing us to either accept loose types everywhere or maintain manual extensions on top — partially defeating the purpose.The schema is stable. OpenACR is at v0.1.0 and hasn't changed since 2020. Adding a code generation pipeline, a build step, and a generated file to track a spec that doesn't move is overhead with no payoff.
Validation gives a stronger compliance guarantee. The pitch: "Every OpenACR YAML we produce is validated against the official GSA schema. If it doesn't conform, the pipeline fails and no VPAT is generated." That's a concrete, auditable guarantee — not a compile-time hope.
What changed
scripts/validate-openacr.mjs— Fetches the official GSA JSON Schema, loads the generatedopenacr.yaml, validates with Ajv, and exits with code 1 on failure (listing all validation errors).package.json— Addedajv@8.18.0as a devDep. Added standalonea11y:validatescript. Wired validation intoa11y:vpatbetween YAML generation and VPAT rendering.Pipeline flow
Usage