Quality

Add accessibility, performance, audits, and metrics checks where they protect real user outcomes.

Use this section when browser automation should protect product quality, not only functional correctness.

Quality checks are useful when the result is actionable. They are harmful when they make every test heavier without explaining what to fix.

In simple terms

Quality checks sit around browser flows:

  • accessibility audits catch structural issues;
  • performance checks watch browser-visible signals;
  • audits create reports for humans or CI;
  • metrics capture application-owned measurements.

Start small. Add checks where the product risk is real and the failure output is readable.

Choose your page

Need Open
Check labels, roles, ARIA, and axe findings Accessibility
Watch stable browser performance signals Performance
Produce reports and CI gates Audits
Read custom marks, counters, or measurements Metrics

Choose what to automate

Risk Good check
Key pages lose accessible names targeted accessibility audit
Critical flow becomes too heavy broad performance budget
A release needs human review report artifact
App owns a browser metric custom metric assertion

Avoid

  • Running expensive audits after every small action.
  • Treating an automated accessibility pass as full sign-off.
  • Using brittle millisecond thresholds on shared CI.
  • Producing reports nobody reads.
  • Adding gates before failures are understandable.

Go next

FAQ

Does an automated audit prove accessibility?

No. It catches many structural issues, but not every task, screen-reader, or keyboard problem.

Should quality checks run in every browser test?

No. Add them where risk is real and failure is actionable.

What should a report do?

It should lead to a decision: fix, investigate, accept, or block release.