2 min lesson
Keyboard path, accessible name, non-text contrast, mobile layout
Practice Browser accessibility checks on one real case. Check the result before moving on.
Check your understanding
Complete the practice "Browser, check one icon-only Filter reports button".
Outcome: The handoff states exactly what Browser proved and leaves any screen-reader claim for a real assistive-technology check.
Browser, check one icon-only Filter reports button
Keyboard path, accessible name, non-text contrast, mobile layout
SayThe new Filter reports button has only an icon. Open /reports at 1280 pixels and use the keyboard path, not the pointer.
Type
Open http://localhost:3000/reports. Record the controls immediately before and after Filter reports in the Tab order.DoTab from Export to Filter reports, activate it with Enter, close the panel with Escape and continue to the first table control.
SeeFocus follows the expected order, the filter opens from the keyboard and a visible indicator stays on the focused control.
SayInspect the button in the source or element context. Confirm that the native button exposes the name Filter reports and that its decorative SVG is hidden from assistive technology.
SeeThe button uses aria-label="Filter reports". The icon has aria-hidden="true", so it does not add a second name.
DoCheck the icon and focus indicator against their adjacent colors, then repeat the layout check at 360 pixels.
SeeThe meaningful non-text states meet the 3:1 threshold. The title and button do not overlap at the narrow viewport.
SayKeep the keyboard path, source evidence, contrast values and narrow screenshot. Do not call this a screen-reader test unless you ran one with assistive technology.
SeeThe handoff states exactly what Browser proved and leaves any screen-reader claim for a real assistive-technology check.