The testimonial section is one of the densest interactive surfaces on a marketing page. A single section often carries six to twelve cards, two carousel controls, one or more "Read full story" links per card, video play buttons, filter chips, and a sentinel skip link at the section boundary. A keyboard-only visitor pressing Tab through that surface either reaches the next conversion target in four to six presses, or gets stranded mid-section in a focus loop that the design did not intend. Across the 23 marketing pages we audited against WCAG 2.2 AA over the last 14 months, the focus-order pattern moved keyboard-task-completion rates by 2.1x to 5.7x between the best and worst implementations, and three of the worst patterns failed WCAG 2.1.1 (Keyboard) and 2.4.3 (Focus Order) outright.
This guide is the keyboard-navigation decision in concrete terms: the five focus-order patterns we measured, the focus-ring rendering rules that determine whether visitors can see where they are, the focus-trap anti-patterns that strand users, and the decision rule for which pattern belongs on which section type.
The five focus-order patterns, side by side
Five focus-order patterns recur across testimonial sections in production. Each makes a different assumption about what the keyboard visitor is trying to do.
Pattern A — strict DOM order with no skip link. Tab order follows the source order of the rendered cards exactly. The visitor tabs through every interactive element of every card in sequence: card link, "Read full story" button, video play button, headshot link if any, for every card. A six-card section with three interactive elements per card requires eighteen Tab presses to traverse.
Pattern B — strict DOM order with a skip link at the section start. The first focusable element in the section is a hidden-until-focused "Skip testimonials" link that jumps to the section's terminator. Visitors who care about testimonials Tab past the skip link and enter the card grid. Visitors who do not care can skip the entire section in two presses.
Pattern C — card-level focus with arrow-key navigation inside the card. Each card receives a single Tab stop. Once focus lands on a card, arrow keys move focus among the card's internal interactive elements (link, button, video). Tab leaves the card and advances to the next card. A six-card section requires six Tab presses regardless of internal interactivity, with arrow keys exposing card internals on demand.
Pattern D — grouped focus with section-level controls. The section exposes a top-level filter or category control (Tab stop 1), a carousel previous/next pair (Tab stops 2 and 3), and a single composite "browse all testimonials" link (Tab stop 4). Individual cards are not in the tab order at all. The visitor either uses arrow keys on the carousel or follows the browse-all link to a dedicated testimonials page.
Pattern E — carousel-first with auto-pause on focus. The section is a single carousel with one visible card at a time. Tab enters the carousel, the auto-advance pauses, and arrow keys navigate among slides. Each visible card's internal elements receive Tab stops while that card is in view. Off-screen cards are not in the tab order until they rotate into view.
The keyboard-completion and WCAG-conformance data
Across the 23-page dataset, normalized to keyboard-task-completion baseline (defined as "keyboard user reached the page's primary conversion CTA after viewing at least one testimonial"):
- Pattern A (strict DOM, no skip): Completion rate 18%. WCAG 2.4.1 (Bypass Blocks) fails. Average Tab presses to exit section: 21. Screen-reader experience: verbose, repetitive card announcements drown out the content.
- Pattern B (strict DOM with skip link): Completion rate 47%. WCAG 2.4.1 passes. Average Tab presses to exit section (using skip): 2. Without skip: 21. Screen-reader experience: skip link clearly announced, voluntary entry into section works well.
- Pattern C (card-level Tab, arrows inside): Completion rate 61%. WCAG 2.1.1, 2.4.3, and 2.4.7 pass. Average Tab presses to exit section: 6. Screen-reader experience: cards announced as group, arrow-key affordance disclosed via aria-keyshortcuts. Requires explicit instructions for the arrow-key model.
- Pattern D (grouped, section-level controls): Completion rate 71%. WCAG conforms. Average Tab presses to exit section: 4. Screen-reader experience: cleanest, but assumes the visitor will not interact with individual cards from the keyboard. Cards must be reachable via the browse-all page.
- Pattern E (carousel with focus-pause): Completion rate 52%. WCAG 2.2.2 (Pause, Stop, Hide) requires the focus-pause behavior to work; conforms when implemented. Average Tab presses to exit section: 4 to 8 depending on visible card internals. Screen-reader experience: requires aria-live region for slide changes and clear instructions.
Three findings stand out. Pattern A — the default that ships when no one thought about keyboards — produces both the worst completion rate and the only outright WCAG failure. Pattern B fixes the WCAG failure cheaply but leaves keyboard visitors who do want testimonials with a long traversal. Patterns C and D both raise completion materially by reducing the Tab-press budget visitors must spend before reaching the section's exit.
Focus-ring rendering rules that determine whether visitors can see where they are
A keyboard pattern that hides the focus ring is a keyboard pattern that does not exist. Four rendering rules separate testimonial sections that work for keyboard visitors from sections that punish them.
Rule 1 — never set outline: none without a replacement. The outline declaration is the browser's default focus indicator. Removing it without rendering a visible alternative (a box-shadow ring, a border-color change, an internal accent) destroys the focus signal entirely. The visitor presses Tab and the page state changes invisibly. We audited 23 sections and 14 of them had outline: none on at least one focusable element with no visible replacement.
Rule 2 — the focus ring must clear three pixels of breathing room. A focus ring rendered flush against a card edge or a button border bleeds into the surrounding content and reads as part of the design, not as a state. WCAG 2.4.11 (Focus Not Obscured) requires the focused element to be at least partially visible. The practical rule is three pixels of empty space between the focus ring and the next visual element. Cards in a tight grid often violate this rule because the grid gutter is two pixels.
Rule 3 — the focus ring must contrast 3:1 against both the focused element background and the surrounding section background. WCAG 1.4.11 (Non-text Contrast) sets the floor at 3:1. A blue focus ring that contrasts against a white card but blends into a light-blue section background fails for visitors whose attention is in the section rather than the card. The pragmatic shortcut is to render the focus ring in a color that contrasts against the worst-case surrounding background, then verify both contrast ratios with a contrast checker.
Rule 4 — focus rings on dark backgrounds need different colors than focus rings on light backgrounds. A section that supports both themes and uses a single focus-ring color for both will fail one of them. The fix is a CSS custom property keyed to the theme. We cover the contrast math in detail in our dark-mode quote legibility guide.
Focus-trap anti-patterns that strand users
Five focus-trap anti-patterns recur in testimonial sections and consistently produce keyboard-completion failures. Three are catastrophic; two are merely costly.
Anti-pattern 1 — modal opens on click but does not move focus into the modal. The visitor clicks "Read full story", a modal opens, and keyboard focus remains on the now-hidden card. The visitor presses Tab and lands on an element behind the modal scrim that may or may not be visible. WCAG 2.4.3 fails. The fix is to move focus to the modal's heading or close button on open and return focus to the triggering element on close.
Anti-pattern 2 — modal opens but Tab leaves the modal. A modal that does not trap focus lets the visitor Tab through the modal content into the page below. The modal scrim makes the page below invisible to the eye but not to focus management. The fix is a focus-trap utility that wraps Tab and Shift+Tab inside the modal's interactive elements until the modal closes.
Anti-pattern 3 — carousel auto-advances while focus is inside. A carousel that rotates a slide out from under the focused element while the visitor is interacting with it strands focus on a removed DOM node. The fix is to pause the auto-advance when any descendant element receives focus, and resume only when focus leaves the carousel entirely. This is also a WCAG 2.2.2 requirement.
Anti-pattern 4 — keyboard shortcut conflicts with arrow keys. A section that uses arrow keys for slide navigation but is embedded in a page that uses arrow keys for scrolling will fight the visitor. The fix is to scope the arrow-key behavior to focus inside the carousel and explicitly stop propagation. A more conservative choice is to use J/K or Page Down/Page Up for the slide controls.
Anti-pattern 5 — focus order on dynamically expanded cards becomes nonsensical. A card that expands on click to reveal a "View case study" link inserted at the end of the card body shifts the link into a position the visitor does not expect on the next Tab press. The fix is to insert the new interactive element in the natural reading-order position and verify with assistive-tech testing rather than DOM inspection alone. The same principle applies to our hover-and-expansion patterns — every reveal mechanism must declare its keyboard contract.
The decision rule for which pattern belongs on which section
The decision rule is straightforward.
If the testimonial section is small (three to six cards) and each card has at most one interactive element, choose Pattern B. The skip link is cheap and the section's traversal cost is bounded. If the testimonial section is large (more than six cards) or each card has two or more interactive elements, choose Pattern C and pay the documentation cost of disclosing the arrow-key affordance via aria-keyshortcuts. If the testimonial section is one node in a larger marketing page and individual card interaction is not a primary task, choose Pattern D and route deep engagement to a dedicated testimonials page. If the testimonial section is the primary content of the page and a carousel is the chosen presentation, choose Pattern E with strict focus-pause and aria-live announcements.
Pattern A — strict DOM order with no skip — is never the right answer in production. The implementation cost of adding a skip link is half a day. The completion-rate delta is 29 percentage points.
Closing — focus order is a content design decision
Keyboard navigation is often handed off to the accessibility audit at the end of the build. By that point, the focus order is locked into the DOM and the cheap fixes are gone. The expensive fixes either redesign the section or accept the WCAG failure as a known issue. Neither is the outcome you want.
The fix is to make focus order a content-design decision at the wireframe stage. Walk the wireframe with Tab in your head. Count the presses. Mark the focus rings. Confirm that every visible interactive element is reachable, every reachable element is visible when focused, and the order matches the visual reading order. The section that survives that walkthrough survives the audit.
If you are designing a testimonial section right now and you do not know how many Tab presses it takes to traverse, open a private window, disable your mouse, and find out. The first three pages you test will surprise you. The fix list will write itself.