@ui @regression @a11y
Scenario: The inventory page has no serious accessibility violations
Given I am on the inventory page
Then the page should have no accessibility violations of impact "serious" or higher
bash
sdods lint -p demo-shop
text
features/inventory/a11y.feature:6
Undefined step: Then the page should have no accessibility violations of impact "serious" or higher
The phrasing is identical to the table in the step library reference, down to the quotes. What am I missing — a plugin, a dependency, a config flag?
Nothing. The step does not exist. Neither does the page should meet the performance budget.
I would rather say that plainly than let you spend an afternoon on the configuration. The accessibility guide and that row in the step library reference describe a design, not a build. What is real today is that @a11y and @perf are reserved in the tag taxonomy and that the project schema accepts accessibility and performance gates on a process. There is no axe hook in the runner and no budget check.
If you want the check anyway, the interim shape is yours to own:
Add the accessibility library to your own project's dependencies — nothing in SDODS pulls it in.
Write the step under projects/<slug>/steps/ with the phrasing you actually want, and assert on the result there.
Attach the JSON under sdods/a11y/<step>. That attachment name is already reserved in the contracts, so the run viewer and the ingest will file it in the right place even though nothing produces it today.
bash
sdods steps list -p demo-shop
is the fastest way to check whether a phrasing you read somewhere is really in your catalogue.
Before you build step 2, agree what "serious or higher" is going to mean to your team.
The impact field on an accessibility finding is a heuristic supplied by the rule engine, not a severity your product has agreed to. A rule set is not a policy. Teams that skip that conversation ship a gate that fails on a decorative image and passes a keyboard trap, and then quite reasonably stop believing it.