Configuration

Every runner takes the same plain engineOptions object — no config file to maintain, no separate CLI-only flag surface to keep in sync. The CLI and every binding just build that object for you from their own flags or builder methods, so what you learn here applies everywhere you run a scan. Four things are worth getting right early:

Engine options

Scope a scan to exactly the rules you want — by naming a WCAG version and level (WCAG 2.2 AA in one option, best practices on top if you want them), by id, by tag, or by naming a conformance profile such as WCAG 2.1 AA, for any WCAG version and level — so a run reports what you're actually accountable for, nothing more and nothing less. Judge one scan by several profiles at once, WCAG beside WAI-ARIA or your own policy, and see what each makes of every finding. Core's EN 301 549 profiles still work but are deprecated: that standard now comes as a pack, and the Section 508 profile, only WCAG 2.0 AA under another name, gives way to wcag20-aa. Run only a few checks and still get the WCAG criteria they belong to, at the level you're held to, and list what a scan will report before it runs. Silence known-noisy widgets globally or for a single rule without losing coverage everywhere else, tune how aggressive the contrast checks are for a human auditor versus an unattended CI gate, and drop in an org-specific rule alongside the built-ins when the catalog doesn't cover something you care about, and hand the rules the CSS of a style sheet from another origin that the page can't read. See Engine options for the full reference.

Packs

Test against more than WCAG without forking the engine. A pack brings a national standard, your organisation's accessibility policy, or a few house rules from a package of its own, and the engine runs it as it runs its own rules: its profiles select what runs, its checklist items come back as one result each, and every report shows them beside the WCAG criteria. The same pack works from Node, every binding, the test matchers and the CLI, and npx surea11y-pack new writes one that passes its own tests as generated. A standard can file a rule's findings under the requirements they belong to, and a pack rule can tell a person how to answer what it leaves undecided, and how to assess each requirement by hand. Two standards are ready to install: EN 301 549, and WAI-ARIA 1.2, which fails what WAI-ARIA requires where WCAG only asks. See Packs to use one or write one.

CI integration

Get a working accessibility gate into your pipeline without writing it from scratch — ready-to-paste GitHub Actions and Bitbucket Pipelines templates gate a build on the CLI's own exit code, baseline an existing site's pre-existing violations so you only fail on genuinely new ones, and upload SARIF results straight into GitHub Code Scanning where your team already looks. GitLab CI and Azure DevOps recipes put results in their own test views as JUnit, written by the CLI in the same step, and a JUnit report can turn the undecided findings that lean fail into failures, so a likely failure doesn't pass as a skipped test. See CI integration for the full templates.

Locales

Ship findings your team can actually act on in the language they read fastest — every rule title and every occurrence's summary and hint resolve from a key-based dictionary, with graceful per-string fallback to English rather than a blank or an error. Five languages ship today (English, French, German, Spanish, Japanese), and a result always tells you exactly which locale it used, so nothing silently degrades without you knowing. The steps for answering an undecided finding ("How to check"), and the test procedures for assessing each criterion by hand, come in the same five languages. See Locales for coverage and how to supply your own dictionary.