Will It Vibe?Element with an interactive role is not keyboard-operable
Part of Documentation, UX & Accessibility, which counts for 15% of the overall score. When this check fires it deducts 8 points from that category, once per scan, no matter how many places it turns up.
What it detects
An element given an interactive ARIA role (button, link, tab, etc.) plus a click handler still is not usable by keyboard unless it is also focusable and responds to a key press: role alone grants neither. Add tabIndex/tabindex plus an onKeyDown/@keydown/on:keydown handler that activates on Enter and Space, or use a native interactive element instead of an ARIA role on a div.
Why it matters
Giving an element an ARIA role like button or tab does not make it focusable or respond to a key press; those are separate properties a browser only adds automatically to real interactive elements. A div with role="button" and an onClick handler looks right in a code review but is completely unreachable by keyboard, which is a stricter failure than a missing role since it passes a naive "does it have a role" check while still being unusable.
How to fix it
Add tabIndex={0} (or tabindex="0") so the element joins the natural tab order, and add a key handler (onKeyDown/@keydown/on:keydown) that calls the same function as the click handler when the key is Enter or Space. If the element can be a real <button> or <a> instead, prefer that over managing keyboard behavior by hand.
The paid report includes a ready-to-paste prompt for your AI coding agent for every check it finds, pointed at the exact findings from your scan. See pricing
Does your repo trip this check?
Paste a GitHub URL or drop a project folder. Scans run in your browser and take seconds.
Scan your repo