Description
About Keyboard Focus Test
Introduction
The DeviceHub Keyboard Focus Test is a free online practice surface for tabbing through sample controls and verifying visible focus indicators, without installing accessibility extensions on every laptop, without crawling your production DOM, and without claiming to replace WAVE, axe, or a professional keyboard audit. Engineers who removed outline:none too aggressively, designers checking focus ring contrast, QA reproducing “cannot see where Tab went,” educators teaching tabindex and DOM order, and support teams confirming a user’s keyboard reaches the page all open one HTTPS sample and press Tab. DeviceHub states limits plainly: this is an educational sample, not a full page audit crawler; prefers-* tools reflect OS settings, not all AT; speech tools elsewhere may need gestures; and nothing here is a medical or clinical diagnosis. Pair with Forced Colors Test because High Contrast must preserve focus. Pair with Reduced Motion Check when animated UIs hide rings. Pair with Text Spacing Test when cramped boxes clip outlines. Pair with Accessibility Preferences for hub context. Pair with Color Contrast Checker when focus rings fail AA against backgrounds. Permissions stay none. Visible focus is one of the highest-impact keyboard accessibility basics, yet outline:none without a replacement still ships in countless stylesheets. DeviceHub Keyboard Focus Test gives teams a permission-free sample to feel Tab and Shift+Tab, confirm a visible indicator, and discuss :focus-visible strategies, without pretending the sample audited every modal, combobox, and router view in your SPA. Limits stay honest: not a full page audit crawler; not a substitute for WAVE, axe, or professional reviews; prefers-* tools reflect OS/browser settings, not all AT; speechSynthesis elsewhere may need gestures; text-spacing is a preview not a fixer; and nothing here is a medical or clinical diagnosis. Pair with Forced Colors Test so Contrast themes still show focus. Pair with Reduced Motion Check when animated carousels steal attention from rings. Pair with Color Contrast Checker when focus halos fail WCAG 2.x sRGB contrast against backgrounds. Pair with Accessibility Preferences for environment context. Pair with Color Blindness Test only for educational palette empathy, not clinical screening. Permissions stay none.
What this tool does
Keyboard Focus Test renders sample interactive controls, highlights focus as you Tab, and explains common authoring pitfalls (removing outlines without replacements, positive tabindex traps, off-screen focus). It does not scan your domain, does not upload key logs for ads, and does not certify WCAG keyboard success criteria for third-party sites. Typed permissions remain none. Closing the tab ends listeners. Informational only, not clinical. The page presents buttons, links, and fields you can tab through, emphasizing visible focus states and common failures such as focus moving off-screen, invisible focus on dark themes, and mouse users never noticing keyboard bugs. It does not record your keystrokes for advertising, does not scan your domain, and does not certify WCAG 2.1/2.2 keyboard criteria for third-party apps. Guidance mentions skip links conceptually without claiming your site’s skip link was tested. Typed permissions remain none. Mobile testers learn that hardware keyboards differ from on-screen keyboards. Closing the tab ends listeners. Informational practice, not clinical assessment of motor ability.
When to use it
Use when training teams on visible focus, when debugging outline:none regressions, when comparing forced-colors focus visibility, when teaching skip links conceptually, and before filing “keyboard broken” tickets that actually lack indicators. Prefer professional audits for real apps. Prefer Forced Colors and Reduced Motion checks for related themes. Avoid medical claims. Avoid treating the sample as proof your SPA routes are complete. Use in onboarding for new frontend hires, when regressing after a CSS reset, when High Contrast users report lost rings, when teaching tabindex hygiene, when comparing Safari versus Chrome :focus-visible behavior on the sample, and before blaming “broken keyboards” that are actually missing indicators. Prefer real audits for production widgets. Prefer Speech Synthesis Test only as a separate TTS capability check, not as a screen-reader substitute. Avoid medical claims about mobility. Avoid treating success on the sample as SPA certification.
How it works
Browsers move sequential focus via Tab among focusable elements. DeviceHub’s sample demonstrates expected visible indicators using CSS :focus-visible patterns educationally. Real sites need their own audits for roving tabindex widgets, modals, and SPA routing. Typed permissions stay none. Mobile on-screen keyboards may not match hardware Tab. Not WAVE/axe. Not clinical. Local only. Sequential focus navigation moves among focusable elements based on DOM order and tabindex rules. DeviceHub’s sample keeps tabindex simple to teach defaults. Roving tabindex patterns in tabs and grids need dedicated component testing DeviceHub does not automate here. Typed permissions stay none. Secure HTTPS applies. Screen reader virtual cursors and browse modes are out of scope for this visual focus demo, perform AT testing separately. Forced-colors may remap outline colors; verify on Windows. Not WAVE/axe. Not clinical. Local event handling only; do not type secrets into sample inputs on projectors. Modern authors often prefer :focus-visible to avoid showing rings on pure pointer clicks while keeping them for keyboard users; the sample demonstrates the idea without locking you into one design-system token. Contrast of the focus indicator against adjacent colors still needs Color Contrast Checker math when you invent custom halos. Under forced-colors, system highlight colors may replace your fancy box-shadow rings, retest with Forced Colors Test on Windows. Reduced-motion settings should not remove focus visibility; if your “subtle” animation was the only indicator, that is an authoring bug Reduced Motion Check can help explain but not auto-fix on your CDN. DeviceHub will not crawl every route for focus order defects; SPA developers must still test dialogs, drawers, and route changes with real keyboards and AT. Mobile Bluetooth keyboards can Tab where on-screen keyboards cannot, document the input method in tickets. Nothing in this flow is a clinical assessment of motor control, tremor, or disability status.
Step-by-step instructions
- Open Keyboard Focus Test over HTTPS and click the sample so keys reach the page.
- Press Tab repeatedly and confirm each control shows a visible focus indicator.
- Use Shift+Tab to move backward and note order expectations.
- Retest after enabling Forced Colors or reduced motion if those settings hide rings on your product.
- Run axe/WAVE or hire a professional audit on your real pages, do not stop at this sample.
- Label outcomes as educational keyboard practice, not a full audit certificate and not a medical finding.
Common problems
outline:none without a replacement. Positive tabindex chaos. Modals trapping focus incorrectly on real sites (sample cannot certify yours). Mouse-only testers missing keyboard bugs. Forced colors removing custom rings. Treating DeviceHub as WAVE. Claiming clinical results. Mobile OSK limitations. Skipping professional audits. Confusing screen reader virtual cursor issues with simple Tab focus. Global outline:none. Positive tabindex traps. Modals without focus containment on real sites. Mouse-only QA. Forced colors hiding custom rings. Sample treated as WAVE. Clinical claims. Mobile OSK limits. Skipping professional audits. Confusing SR issues with Tab focus. Dark theme gray rings failing contrast. Reduced-motion carousels moving focus unexpectedly. Expecting DeviceHub to fix remote CSS. WebView key handling differences. Filing compliance certs from a practice page. Relying on browser default outlines that your CSS reset removed only on some elements. Focusable cards with nested buttons creating unexpected stops. Skip links that become visible only on the sample mindset but missing on production. Treating VoiceOver rotor issues as Tab issues. Filing Section 508 certificates from DeviceHub alone. Mixing Color Blindness Test into clinical forms while discussing focus paint. Expecting DeviceHub to disable outline:none sitewide via magic.
Privacy explanation
Keyboard Focus Test listens for focus and key events on the sample region locally. DeviceHub does not upload keystrokes for advertising when you use this page. Permissions stay none. Do not type passwords into sample fields on shared screens. Informational, not medical. Clear the page after classroom demos. Focus and key events stay on the sample region locally. DeviceHub does not upload keystrokes for advertising when you use this page. Permissions stay none. Never enter passwords or personal data into demo fields. Informational, not medical. Clear the page after workshops. Key events are not archived by DeviceHub for advertising. Do not demonstrate password fields on the sample during public streams. Informational keyboard education only, not medical documentation of physical ability.