Rule Categories

TestKase runs axe-core under the hood. Axe groups rules by category (what they check) and by tag (which standard / enablement status they're part of). The three toggles in Scan Settings each select a different slice of that.

The Website Scanner and the Chrome Toolkit both run axe-core 4.13.0. The toolkit carries its own copy inside the extension, but it is the same version, so a page checked with the same settings gives the same results in both.

Advanced rules (advanced)

• Default: On.
• What it is: a fixed list of 23 axe-core rules that are disabled by default in axe but that TestKase force-enables. It is a TestKase list, not an axe tag.
• Why leave on: you typically want to catch these issues.
• Why turn off: rarely — only if your program has decided a specific rule produces too much noise. The toggle is all-or-nothing; you cannot drop a single rule from the list.

The 23 rules, in full, so you can audit exactly what the toggle adds:

There is a second consequence. Rules that pass are counted for the score without that tag filter, so the 18 rules above still add passes to your score even when their failures could never be reported. Advanced rules therefore nudges a score slightly upwards on a scan where Best practices is off.

Best practices (bestPractices)

• Default: Off.
• What it is: the rules carrying axe's best-practice tag — they improve UX and accessibility but are not WCAG success criteria. Examples: heading-order, image-redundant-alt, label-title-only.
• Why turn on: you want to produce friendlier, more consistent interfaces and you're OK with findings that don't map to formal WCAG failures.
• Why leave off (default): you want a report that's exclusively WCAG conformance-driven, e.g., for an audit.

Needs review (needsReview)

• Default: On.
• What it is: axe-core's incomplete results — checks axe could not decide automatically. Example: whether a custom control has an accessible keyboard handler when the handler isn't statically analyzable.
• How TestKase stores them: as issues, with severity moderate unless axe supplied one, but flagged as needing review. They are not counted as problems: they appear in a folded To check by hand (N) section at the bottom of the All Issues tab, not in the main list. In Website Scanner reports they still lower the score; in Chrome extension reports they do not. They do not mark their WCAG criterion as failing — the conformance section reports them as needs a person to decide — and they are excluded from the fix plan, because an inconclusive check is not something anyone can be told to go and fix.
• Why leave on: catches things that are likely problems; a human can confirm.
• Why turn off: you want only hard, machine-confirmed failures — and a score that ignores judgement calls.

What's always on

• Every rule mapped to your chosen WCAG version and level. This is the core of the scan and can't be disabled — it's what the conformance matrix is measured against.

Note that the passing rules used in the score are not filtered by your chosen version and level: every rule axe reports as passing counts towards the score's denominator, including rules outside the standard you selected.

Changing a toggle later

The toggles belong to the scan, not to the report. Editing them on an existing scan (creator only) changes the next run — it never re-interprets a report that has already been produced. The settings a given report was produced with are listed in the Scan details dropdown in its header, so two versions of the same scan can legitimately have been measured differently.

Where the toggles live

Scan Settings → Accessibility tab. See Web Scanner for screenshots.

Related

• WCAG levels and versions
• Severity levels
• Web Scanner