2 min lesson
Check the Filter reports button
Practice Browser accessibility checks on one real case. Check the result before moving on.
Step 1 of 2
Open /reports at 1280 pixels and record the expected keyboard order around Filter reports. Use Tab and ⇧⇥ to reach the button. Activate it with Enter, close the panel with Escape and continue to the first table control. Confirm that focus remains visible throughout. Inspect the button in the source or element context. It should be a native button with the accessible name Filter reports, and its decorative SVG should stay out of that name. Check the icon and focus indicator against adjacent colors at 3:1. Repeat the layout check at 360 pixels. Keep the keyboard path, source evidence, contrast values and narrow screenshot. Call it a screen-reader test only if you also ran one with assistive technology.
Tab to Apply, then confirm the focus ring and the name
0:41 · narratedRead this demo as text
- Ask the agent to actually tab to the Apply button on the live cart — not just glance at the screenshot. Focus order and focus visibility only show up when you drive the keyboard yourself.
- Switch to the Browser tab and watch the tab order: focus stops on the coupon field first, then lands on Apply with a visible blue ring. That's the order a real keyboard user would hit.
- The agent reads the accessible name straight off the focused control: Apply. Ring visible, name confirmed — that's a keyboard-safe control, not a guess from the layout.
Practice next: Open one icon button on a running page. Reach it by keyboard, check its focus indicator and inspect how its name is defined.
Simulated Cursor 3.12 (macOS, light) — beta educational reconstruction, not the real product.