1 min lesson
Know what Browser can prove
Decide when Browser accessibility checks fits. Name the lesson detail that supports your choice before you act.
Step 1 of 2
Browser can check the keyboard path, source name, contrast and layout. A real assistive-technology session is separate evidence.
Cursor Browser can test keyboard navigation, inspect semantic HTML and ARIA labels, check color contrast and capture responsive screenshots. Give it one control and an expected keyboard path. Use Tab, ⇧⇥, Enter, Space and Escape as the control requires. A visible focus indicator shows where keyboard input will land. Inspect the source or element context for the native role and accessible name. For an icon-only button, visible text, aria-labelledby or aria-label can supply that name. Hide a decorative icon so it does not add noise. WCAG 2.2 uses 3:1 against adjacent colors for meaningful non-text controls and states. An aria-label check is useful evidence, but it is not a screen-reader session.
- Entry point
- the exact page, expected keyboard path, changed control and target viewport
- Source
- Cursor Browser docs, WCAG 2.2 1.4.11 and 2.4.7, and the WAI-ARIA Button Pattern
Check Browser capabilities in Cursor's docs, then use WCAG 2.2 and the WAI-ARIA Button Pattern for focus, contrast and naming.