WCAG 2.4.7 Focus Visible — Testing Guide for Mobile & Web Apps

WCAG 2.4.7: Ensuring Visual Focus Indicators for All Users

WCAG 2.4.7: Ensuring Visual Focus Indicators for All Users

Understanding WCAG 2.4.7: Focus Visible

WCAG 2.4.7 requires that when an interactive element (like a button, link, or form field) receives keyboard focus, a visual indicator must clearly show which element is currently selected. This indicator should be distinct and easily noticeable. The goal is simple: users navigating with a keyboard or assistive technologies need to know precisely where they are on the screen at all times.

The Impact of Visible Focus

This criterion is crucial for users who rely on keyboard navigation or screen readers. Without a visible focus indicator, these users can become disoriented, unable to determine which element will be activated by their next keystroke.

• Keyboard-only users: They depend entirely on the focus indicator to understand their current position and navigate through interactive content.
• Screen reader users: While screen readers announce the currently focused element, a visual indicator provides an essential secondary cue, especially in complex interfaces or when audio cues are missed.
• Users with cognitive disabilities: A clear focus indicator can reduce cognitive load, making it easier to track progress and understand interface state.
• Users with low vision: A well-designed focus indicator aids in identifying interactive elements, especially when contrast is a challenge.

Non-compliance with this standard can lead to significant usability barriers, potentially violating regulations like the EU's European Accessibility Act (EAA) and the Americans with Disabilities Act (ADA) in the United States.

Common Violations and Examples

Violations of WCAG 2.4.7 often stem from either removing default focus styles without providing replacements or implementing replacement styles that are too subtle.

Mobile App Violations:

1. Default Focus Removal Without Replacement: Many frameworks allow developers to remove default focus outlines. If no custom style is applied, navigating via keyboard (e.g., using an external keyboard with Android/iOS) leaves the user blind to the focused element.

• *Example:* A custom button component in an Android app that hides the default ripple effect or outline on focus, and no alternative visual cue is provided.

1. Insufficiently Contrasting Focus Indicator: Applying a focus style that has poor contrast against the background or the element itself.

• *Example:* A web view within a mobile app where links receive focus, but the focus outline is a light gray on a white background, making it almost invisible.

Web Application Violations:

1. Subtle or Invisible Borders: Applying a focus style that is a thin, single-pixel border with very low contrast, or no border at all.

• *Example:* A website where buttons get a border: 1px solid #eee; on focus, which blends into the light gray background.

1. Focus Style on Non-Interactive Elements: Applying focus styles to elements that are not intended to be interactive (e.g., divs that are styled to look like buttons but are not focusable by default).

• *Example:* A marketing website where div elements are styled as clickable cards, but they do not have a tabindex attribute and thus don't receive focus, or if they do, the focus style is missing.

1. Overwritten Default Focus Styles: Custom CSS that overrides the browser's default :focus outline without providing a suitable alternative.

• *Example:* A React application with global CSS that sets outline: none; for all elements, and no specific :focus-visible or :focus styles are defined for interactive components.

Testing for WCAG 2.4.7 Compliance

A multi-pronged approach combining manual testing, automated tools, and platform-specific considerations is most effective.

#### Manual Testing Steps

1. Keyboard Navigation:

• Use the Tab key to move forward through interactive elements.
• Use Shift + Tab to move backward.
• Use Enter or Spacebar to activate focused elements.
• Observe closely: Does a clear visual indicator appear around the element that receives focus? Is it easy to see against its background and surrounding elements?

1. Arrow Keys: For elements like radio button groups, checkboxes, or custom dropdowns, use the arrow keys to navigate within the group. Ensure the focus indicator moves correctly.
2. Browser Developer Tools (Web):

• Inspect focus styles. You can temporarily disable CSS rules or use the "Elements" panel to simulate focus states.
• Use the :focus-visible pseudo-class to test how focus indicators appear for keyboard users versus mouse users.

#### Automated Tools

Several tools can assist in identifying potential violations:

• Browser Extensions:
• axe DevTools: Detects accessibility issues, including focus visibility.
• WAVE (Web Accessibility Evaluation Tool): Provides visual feedback on accessibility features, including focus.
• Linters/Scanners:
• ESLint plugins (e.g., eslint-plugin-jsx-a11y): Can flag common issues in React/JSX code.
• HTMLHint: Checks HTML for common errors and accessibility problems.
• Command-Line Tools:
• Pa11y: A command-line accessibility testing tool that can be integrated into CI/CD pipelines.

#### Mobile-Specific Considerations (Android/iOS)

• External Keyboard Testing: Connect a USB or Bluetooth keyboard to your test device. This is the most reliable way to simulate keyboard navigation on mobile.
• TalkBack (Android) / VoiceOver (iOS): While primarily screen readers, their focus management can reveal issues with visual focus indicators if they are inconsistently applied or if the visual cue doesn't match the screen reader's announcement.
• Android Accessibility Scanner: This app from Google can identify accessibility issues, including focus problems.
• iOS Accessibility Inspector: Part of Xcode, this tool helps developers inspect UI elements and their accessibility properties.

Fixing WCAG 2.4.7 Violations

The most robust solution involves using the :focus-visible pseudo-class. This allows you to define focus styles that appear only when a user is navigating via keyboard (or other non-pointer methods), preserving cleaner visual designs for mouse users.

Web Application Code Example (CSS):

/* Default styling for interactive elements */
.button {
  padding: 10px 20px;
  border: 1px solid #ccc;
  background-color: #f0f0f0;
  cursor: pointer;
}

/* Styling for when an element receives focus via keyboard */
.button:focus-visible {
  outline: 2px solid #007bff; /* A clear, high-contrast outline */
  outline-offset: 2px;      /* Adds a small gap between outline and element */
  border-color: #007bff;     /* Optionally change border color too */
}

/* Fallback for older browsers or if you want focus for mouse users too */
.button:focus {
  outline: 2px solid #007bff;
  outline-offset: 2px;
}

/* Ensure focus styles are applied to focusable elements */
a:focus-visible,
button:focus-visible,
input:focus-visible,
select:focus-visible,
textarea:focus-visible {
  /* Styles defined above or specific styles here */
}

/* For elements that are not natively focusable but need to be */
[tabindex]:focus-visible {
  /* Styles */
}

Mobile App Considerations:

• Android: Use StateListDrawable or custom drawables to define focus states for View components. Ensure your focus-aware views have a focusable="true" attribute.
• iOS: For custom controls, ensure they implement accessibility protocols and provide visual focus feedback. For standard controls, the system usually handles this, but custom styling might interfere.

How SUSA (SUSATest) Checks for Focus Visible

SUSA autonomously explores your application, mimicking various user personas, including those who navigate via keyboard.

• Autonomous Exploration: SUSA interacts with your APK or web URL without requiring pre-written scripts. During this exploration, it simulates keyboard navigation.
• Persona-Based Testing: The Power User and Adversarial personas, in particular, are driven to test navigation and interaction flows, including focus management.
• Visual Element Analysis: SUSA analyzes the visual presentation of interactive elements. It detects when an element receives focus and checks for the presence and clarity of a visual indicator.
• Accessibility Violations Detection: As part of its automated QA process, SUSA specifically flags elements that lack adequate focus visibility, aligning with WCAG 2.1 AA standards.
• Flow Tracking: For critical user flows (login, checkout, etc.), SUSA verifies that navigation remains clear and that focus indicators are consistently present, ensuring no steps are missed due to usability barriers.
• Coverage Analytics: SUSA can report on screen element coverage, and its testing process implicitly includes checks for interactive elements and their focus states.

By uploading your APK or web URL to SUSA, you can get immediate feedback on WCAG 2.4.7 compliance, alongside other critical issues like crashes, ANRs, and security vulnerabilities, all without writing a single line of test code.