12. Accessibility, keyboard use and layout evidence

qatestingplaywrightindependent-practice

Saved on this device

Full lesson · 4 learning steps Open any exercise for focused practice

Step 1 of 4 · intro card

12. Accessibility, keyboard use and layout evidence

Concept and contract

Combine automated findings with explicit manual and interaction limits.

Accessibility evidence comes from several kinds of checks. Automated rules can detect some missing labels, contrast problems or structural issues. Keyboard interaction, screen-reader behavior and understandable content need additional review. A zero-violation automated scan is not a complete accessibility certification.

Start with a small, stable local page. Give controls meaningful labels and verify that a user can reach and operate them. Keep test scope visible so a useful tool does not create a broader claim than its observations support.

Mechanism and worked example

The worked test runs axe against the local page after roles are loaded.

The worked test runs axe against the local page after roles are loaded. It reports violations rather than hiding them. Waiting for the intended content matters: scanning an empty loading shell would miss controls that appear only after data arrives.

Visual comparisons answer a different question. Baselines depend on browser, fonts, platform and fixture state. A screenshot can support review, but pixel equality does not prove keyboard access or semantic labels.

Complete worked example

typescript

import { test, expect } from "../support/test.js";
import AxeBuilder from "@axe-core/playwright";
test("local page automated accessibility scan", async ({page}) => {
  await page.goto("/");
  await expect(page.getByRole("list", {name:"Matching roles"}).getByRole("listitem")).toHaveCount(4);
  const result = await new AxeBuilder({page}).analyze();
  expect(result.violations).toEqual([]);
});

Reasoning: The scan runs on loaded content and reports a defined class of automated findings.

Counterexamples and common mistakes

The weak check captures a screenshot and declares accessibility complete.

The weak check captures a screenshot and declares accessibility complete. It does not inspect labels, focus order or assistive-technology behavior. Conversely, an automated semantic scan can pass while a keyboard user still encounters a workflow problem.

Do not suppress every rule that fails without understanding its impact. Record a justified exception and retain an independent check when a tool cannot model the real behavior. Review noisy findings rather than converting them automatically into passes.

Counterexample: what this check misses

typescript

// A screenshot alone cannot establish labels, focus order or screen-reader usability.
// Do not label it a complete accessibility pass.

Reasoning: One image cannot establish a complete accessibility outcome.

Independent practice: small task

Write a keyboard check that focuses Search roles, presses Tab and verifies focus reaches Reload roles.

Write a keyboard check that focuses Search roles, presses Tab and verifies focus reaches Reload roles. Then set a narrow viewport and check the page has no document-wide horizontal overflow. Begin with the focus transition before adding layout evidence.

Attach a screenshot for review. Optional extension: add a stable visual baseline in one pinned browser environment. The basic task deliberately keeps semantic, keyboard and layout evidence distinct.

Step 1: Verify the expected focus transition. Step 2: Check narrow viewport width and retain a screenshot.

Practice starter: solve before reading the solution

typescript

import { test, expect } from "../support/test.js";
test("keyboard and narrow layout", async ({page}, testInfo) => {
  // TODO: check the focus transition and document width, then attach an image.
});

Reasoning: Check the keyboard transition first, then add a scoped layout observation.

Hint 1: An automated scan is partial evidence.
Hint 2: Do not disable failing rules without review.

Solution, tests and trade-offs

The solution observes focus through the real browser and checks viewport width at a defined size.

The solution observes focus through the real browser and checks viewport width at a defined size. Its screenshot is evidence for that fixture, not proof of every device. The automated scan and keyboard test remain separate because they cover different risks.

The verifier executes both examples in Chrome. A reviewer should still inspect the captured image and consider screen-reader use. Clearly named limitations make the evidence more trustworthy, not less useful.

Practice solution and acceptance checks

typescript

import { test, expect } from "../support/test.js";
test("keyboard and narrow layout", async ({page}, testInfo) => {
  await page.setViewportSize({width:390,height:844});
  await page.goto("/");
  await page.getByLabel("Search roles").focus();
  await page.keyboard.press("Tab");
  await expect(page.getByRole("button", {name:"Reload roles",exact:true})).toBeFocused();
  expect(await page.evaluate(() => document.documentElement.scrollWidth <= innerWidth)).toBe(true);
  await testInfo.attach("narrow-layout", {body:await page.screenshot(),contentType:"image/png"});
});

Reasoning: The screenshot complements focus and width assertions without replacing manual review.

Interview reasoning and next step

In interviews, distinguish automated violations, keyboard behavior and visual regressions.

In interviews, distinguish automated violations, keyboard behavior and visual regressions. Explain one problem a screenshot cannot reveal. State the baseline environment before interpreting a pixel difference as a product defect.

Next, investigate flaky failures with traces and reproducible inputs rather than increasing retries until the suite turns green.

Optional stretch — after the core task works: Add a baseline in one documented browser environment.

Computer practice: download the companion lab at https://applydjinn.com/typorithm/qa-lab-20261105.zip. Read its README, install the pinned tools and run the accepted examples before attempting a starter. The mobile reader preserves your reading and self-check progress; the local lab runs browser tests separately.

Combine automated findings with explicit manual and interaction limits.