Standard scope
This standard applies to:
- pennmedicine.org
- All Penn Medicine websites
- Penn Medicine mobile applications
- All Penn Medicine digital products
Overview
Keyboard navigation ensures that every user—regardless of ability—can interact with Penn Medicine web and digital products. At Penn Medicine, we adhere to Web Content Accessibility Guidelines (WCAG), to ensure that websites are usable by a wider audience, including those who rely on screen readers or other assistive technologies.
Importance of keyboard navigation
Keyboard navigation is essential for the following reasons:
- Accessibility compliance
- Required under WCAG 2.0/2.1 Guidelines (e.g., Success Criterion 2.1.1: Keyboard).
- Supports ADA, Section 508, and HIPAA aligned best practices.
- Non-compliance can lead to legal risk and complaints from users with disabilities.Equal access to care
- Equal access to care
- Many patients rely on keyboard navigation to:
- Book appointments
- Refill prescriptions
- View lab results or test records
- Complete forms or insurance documents
- If they can’t do this without a mouse, they may be excluded from essential services.
- Inclusive user experience
- Demonstrates your organization’s commitment to health equity and digital inclusion.
- Builds trust and credibility with all patient populations.
Guidelines for keyboard navigation:
To ensure compliance with keyboard navigation—especially to meet WCAG 2.0 AA standards—you need to design, build, and test with keyboard-only users in mind. Here's a practical checklist tailored to healthcare organizations, where accessibility impacts patient care, privacy, and legal compliance.
1. Use a logical tab order
- Ensure that pressing Tab moves through elements in a logical, visual order (e.g., navigation → content → forms).
- Use semantic HTML (<nav>, <main>, <form>, <button>, <a>) to support natural focus flow.
- Avoid disrupting the order with complex layout structures (e.g., using position: absolute without tabindex fixes).
2. Make all interactive elements focusable
- All key components must be reachable via keyboard:
- Buttons (<button>)
- Links (<a href="...")
- Form fields (<input>, <select>, <textarea>)
- Modals, pop-ups, and accordions
- Use tabindex="0" to make custom elements (like icons or cards) focusable if necessary.
3. Provide a visible focus indicator
- Every interactive element must show a clear visual outline when focused.
- Default browser outlines are okay, but can be styled for branding.
- Use CSS like:
css
CopyEdit
button:focus, a:focus {
outline: 3px solid #005eb8; /* Example: high contrast blue */
}
4. Avoid keyboard traps
- Users must be able to enter and exit every interactive component using only the keyboard.
- Especially check:
- Modals/popups (should trap focus only while open, then return to trigger)
- Embedded content like video players or chatbots
5. Enable skip navigation links
- Add a “Skip to Main Content” link at the top of the page.
- It should appear when focused and jump past repetitive content like navigation.
html
CopyEdit
<a href="#maincontent" class="skip-link">Skip to Main Content</a>
6. Support all key actions via keyboard
- Users should be able to:
- Open/close menus with Enter or Space
- Submit forms with Enter
- Dismiss modals with Esc
- Navigate dropdowns with arrow keys
7. Ensure accessible forms
- Labels must be associated with inputs using the for and id attributes.
- Error messages should appear inline and be focusable or announced.
- Required fields should be clearly marked and accessible.
8. Use ARIA wisely (only when necessary)
- ARIA (aria-* attributes) can help with custom elements but should not replace native HTML behavior.
- Example: role="dialog", aria-labelledby, aria-hidden
Testing
Testing for compliance can be performed manually or with automated tools.
Manual testing (No mouse!)
- Unplug or stop using your mouse.
- Use only Tab, Shift + Tab, Enter, Esc, and arrow keys.
- Try:
- Navigating the header, footer, and main content
- Opening/closing menus or modals
- Submitting forms
- Filling in inputs and correcting errors
Automated tools
- axe DevTools (Chrome extension)
- WAVE Evaluation Tool
- Lighthouse in Chrome DevTools
- Keyboard testing in screen reader mode (e.g., NVDA or VoiceOver)
Related resources
Contact
For more information about this standard, email: web-standards@pennmedicine.upenn.edu