Manually Test Accessibility on Desktop

Some users interact with technology using only a keyboard—no mouse.

Under WCAG 2.1 2.1.1 – Keyboard (A), 2.4.3 – Focus Order (A), and 2.4.7 – Focus Visible (AA), all functionality must be operable from the keyboard, and focus must move logically and remain visible.

Test your interface the same way: put the mouse aside and navigate using just the keyboard. Use these keys to move through all interactive elements (links, buttons, menus, and form fields):

How to Test

Basic Keyboard Navigation

These keys work across most websites and applications:

• Tab – Move forward through interactive elements
• Shift + Tab – Move backward through interactive elements
• Enter/Return – Follow a link or activate a button
• Spacebar – Toggle checkboxes or activate buttons

Advanced Keyboard Interactions

Some custom components use additional keys:

• Arrow Keys – Move between items in menus, radio groups, or tabs
• Tab – Move into the selected tab panel to access its content
• Esc – Close modals, dropdowns, or menus (if applicable)

What to Look For

• Can you see where the focus is?
  • Each element should show a visible focus indicator (like a border or color change) when selected.
  • Is the indicator easy to see and does it have good contrast with the background?
• Can you reach everything?
  • All interactive elements—links, buttons, menus, and form fields—should be accessible with the keyboard alone.
• Is the navigation order logical?
  • Focus should move in a sensible order, usually top to bottom and left to right.

Keyboard testing is a quick way to uncover accessibility barriers that automated tools miss. It helps ensure your content is a user-friendly digital experience for everyone.

Quick Summary Checklist

• All interactive elements and functionality are accessible using only the keyboard.
• Focus moves in a logical and predictable order.
• It is always clear which element currently has keyboard focus (visible focus indicator), and the indicator is easy to see.
• Links, buttons, menus, and form controls can be activated using the keyboard.
• No keyboard traps prevent users from moving focus away from a component.
• Menus, dialogs, and other custom components support expected keyboard interactions.

Color contrast ensures that text, controls, focus indicators, and other visual elements are distinguishable from their background. Sufficient contrast helps users with low vision, color vision deficiencies, and those viewing content in challenging lighting conditions.

How to Test

1. Identify text, icons, graphics, form controls, focus indicators, and other interactive elements on the page.
2. Use a contrast checker or color-picking tool to measure the contrast between the element and its background. For recommended tools, see the Color and Contrast guidance page.
3. Test interactive elements in all available states:
   • Default
   • Hover
   • Focus
   • Active/Pressed
4. Verify that text, graphical elements, and user interface components meet the required contrast ratios.

Testing Test Contrast

Per WCAG 2.2 Success Criterion 1.4.3 Contrast (Minimum), text must have a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (18 pt regular or 14 pt bold and larger).

Use a contrast checker to measure the ratio between text and its background and verify these minimum requirements are met.

Testing Non-Text Contrast

When interactive elements change state (such as hover, focus, active, or disabled), users must be able to clearly perceive and understand those changes.

Under WCAG 2.2 Success Criterion 1.4.11 Non-Text Contrast, interactive components, focus indicators, and meaningful graphical elements must have a contrast ratio of at least 3:1 against adjacent colors.

What to Look For

• Text meets minimum contrast requirements.
• Interactive controls and focus indicators maintain at least 3:1 contrast against their background.
• Important icons, charts, and graphics are distinguishable from surrounding colors.
• Hover, focus, and active states are visually apparent.
• State changes are not communicated by color alone.
• If the only difference between states is color, ensure the color change itself meets a 3:1 contrast ratio or provide an additional visual cue such as an underline, border, icon, or shape change.
• Disabled controls remain visually distinct from active controls, even though they are exempt from WCAG contrast requirements.

Quick Summary Checklist

• Normal text meets a contrast ratio of at least 4.5:1 and large text meets 3:1.
• Interactive components and focus indicators maintain ≥ 3:1 contrast.
• Informational graphics are distinguishable from surrounding colors.
• Interactive elements clearly display their various states.
• State changes are not communicated by color alone.
• Keyboard focus remains visible and easy to identify.

Some users increase text size or zoom content to make it easier to read. Under WCAG 2.2 Success Criteria 1.4.4 Resize Text and 1.4.10 Reflow, content should remain usable when zoomed without loss of information or functionality.

How to Test Resize Text (WCAG 1.4.4)

Users should be able to increase text size up to 200% without loss of content or functionality.

1. Open the page in your browser.
2. Increase the browser zoom level to 200% (Ctrl/Cmd + Plus).
3. Review the page content and interactive elements.
4. Verify that:
   • Text remains readable.
   • Text is not cut off, truncated, or overlapping other content.
   • Buttons, links, menus, and form controls remain visible and usable.
   • No information or functionality is lost.

For additional guidance, see WebAIM’s Text Resize Testing.

How to Test Reflow (WCAG 1.4.10)

Users with low vision often magnify content rather than viewing pages full screen. Content should reflow without requiring horizontal scrolling.

1. Open browser developer tools and enable responsive design mode, or manually resize the browser window.
2. Set the viewport width to 1280 CSS pixels.
3. Zoom the page to 400%. This simulates a viewport approximately 320 CSS pixels wide, which is the WCAG testing condition.
4. Navigate through the page and verify that:
   • Content reflows into a usable layout.
   • Users can read and interact with content using primarily vertical scrolling.
   • Text, controls, and functionality remain available.
   • Dialogs, menus, forms, and other components are not clipped or obscured.

Exception: Two-dimensional content such as data tables, maps, spreadsheets, images, and complex charts may require horizontal scrolling.

For additional guidance, see WebAIM’s Reflow and Responsive Design.

Quick Summary Checklist

• Content remains readable and usable at 200% zoom.
• Text does not overlap, truncate, or disappear when zoomed.
• Content reflows correctly at 400% zoom (320 CSS pixels wide equivalent).
• No loss of content, information, or functionality.
• Interactive elements remain visible and operable.
• Forms, menus, dialogs, and navigation remain usable.
• Horizontal scrolling is not required except for content that inherently requires two-dimensional layout (e.g., data tables, maps, charts, or large images).
• Users can complete tasks using primarily vertical scrolling.
• No content is hidden, clipped, or obscured at increased zoom levels.

Screen readers enable users to access digital content through speech or Braille output. While commonly used by people who are blind or have low vision, they may also be helpful for some individuals with cognitive, learning, or reading disabilities.

Screen reader testing can help identify issues related to page structure, headings, links, forms, images, and dynamic content.

Because screen reader testing requires specialized knowledge and practice, it is covered separately from this introductory guide.

Coming Soon: A dedicated guide covering screen reader testing tools, techniques, and best practices.