About Graceful Web Studio Experts in Webflow Accessibility

Transcript: Summer of Access – Keyboard Navigation in Digital Learning

Nicole L’Etoile:

Hello, hello, welcome everyone! Thank you so much for joining us. We are in a Zoom meeting, so if you would keep your mics muted, we’d really appreciate that.

We’d love to have you join us at any time. We’ll go over some key Zoom features to get started.

The slides I’m sharing are also in the chat. I’ll make sure to continue putting in the proper links so you have access to the content.

Welcome to the Summer of Access webinar series. We’re excited to have you with us, and even more excited to introduce our presenter today, Crystal Scott.

This series is brought to you by Lual Education and the Accessibility L&D community. This is the first in our series, and we’ll be hosting 10 more sessions throughout the summer.

Zoom Meeting Reminders:

• Please stay muted unless you’re speaking.
• Use the chat or raise hand feature for questions.
• Recordings will be shared in the Accessibility L&D Slack community.
• Live captions and transcripts are available for every session.

Please say hello in the chat and let us know where you’re calling in from today.

About the Presenter:

Crystal Scott is the founder of Graceful Web Studio, a Webflow expert, and a Certified Professional in Web Accessibility with over a decade of experience in front-end development and inclusive design.

She specializes in building and remediating accessible websites, creating long-term strategies for SEO, usability, and WCAG conformance.

Crystal is also the founder of the Accessibility Book Club and is passionate about making accessibility practical, approachable, and essential for every team.

Crystal is also my colleague, web designer, and friend. Please welcome Crystal!

Crystal Scott:

Thank you so much, Nicole! That was a wonderful introduction.

I’m going to share my screen and take a deep breath—being the first in a series is always a little nerve-wracking. But I’m thrilled to talk today about one of my favorite topics: keyboard accessibility in digital content.

What We’ll Cover Today:

• 2.1.1 Keyboard: Interactive elements must work equally for mouse, touch, and keyboard users.
• 2.1.2 No Keyboard Trap: Focus must not be trapped within components—this creates critical access barriers.
• 2.4.7 Focus Visible: Focused elements must be clearly visible to all users.
• 1.4.11 Non-Text Contrast: Focus indicators must have at least a 3:1 contrast ratio.
• 2.4.3 Focus Order: Focus should follow a logical and expected sequence.

Inaccessible navigation is still a major barrier for many users. Let’s explore how to design with keyboard access in mind—and why it matters.

Why Keyboard Access Matters

Keyboard access isn’t just about accessibility—it improves usability for everyone.

Developers and power users often rely on keyboard shortcuts to work efficiently. I personally spend a lot of time with both hands on the keyboard while developing or testing websites. It’s frustrating when I’m forced to switch to the mouse unnecessarily.

For users with physical disabilities, keyboard access is essential. Many rely solely on the keyboard because mouse use is difficult or impossible.

People who benefit from keyboard-only navigation include:

• Those with motor limitations, weakness, tremors, or lack of coordination
• People with arthritis or joint pain
• People with paralysis or missing limbs
• Blind users who rely on screen readers and keyboard navigation

Many designers and developers unintentionally build for mouse users only, which results in barriers and WCAG failures.

W3C Video on Physical Disabilities

Let’s watch a short video from the W3C that does a great job explaining the different types of physical disabilities and how keyboard access plays a vital role in inclusion.

[Video Playback Issues]

Nicole: That’s very low, Crystal. I don’t think we’re going to hear it.

Crystal: Oh! Am I not sharing with sound? Let me try again...

[Crystal attempts to share audio and replay the video]

Key Takeaways from the W3C Video:

• People with limited mobility may not be able to use small clickable areas.
• Speech input users need buttons that are properly labeled in code and visually.
• Some users rely on specialized keyboards, mouse sticks, or head sticks.
• Accessible websites should work regardless of input device and provide enough time to interact.
• Instructions, labels, error messages, and support for multiple orientations improve usability.

The video ends with the reminder that accessibility is all about people. You can help make technology accessible to me.

Crystal Scott:

So that was a powerful video. For more resources like that, visit w3.org/people.

They covered a lot more than I will today, but it’s a great reference if you want to go deeper.

Now let’s move into our main topic: keyboard-only navigation essentials.

Keyboard Navigation Essentials (WCAG 2.1.1)

Let’s look at WCAG 2.1.1: Keyboard. The understanding document states that all functionality must be operable via a keyboard interface, without requiring specific keystroke timing. Mouse input can be supported, but it cannot be required. Mouse and keyboard must be equal in functionality.

If you've never tried navigating a website with only your keyboard, I challenge you to do that today. Go to a site like Amazon or Walmart, put your mouse aside, and try purchasing something using only your keyboard. This will give you real insight into the experience of keyboard-only users.

Basic Keyboard Commands

• Tab: Move forward through focusable elements
• Shift + Tab: Move backward
• Enter / Space: Activate elements
• Arrow keys: Navigate carousels, menus, sliders
• Escape: Close modals and dropdowns and return focus

Live Demonstration

[Crystal navigates her website using the keyboard.]

I’m using the Tab key to move forward, Shift + Tab to move back. When I hit Enter on my skip link, it jumps me past the navigation to the main content.

When I open the contact dialog, focus is sent directly to the modal. When I close it, focus is returned to the trigger. This is basic keyboard navigation behavior—and essential for usability and compliance.

W3C APG Patterns

For more advanced interactions, check out the W3C ARIA Authoring Practices Guide (APG). It has great keyboard interaction patterns for menus, sliders, and more. It can be a little technical, but if something doesn’t work the way it should, this is your go-to resource.

Focusable Elements

Let's talk about which elements are focusable by default:

• <button>
• <a href="">
• <input>
• <select>
• <textarea>

These elements do not require extra attributes or JavaScript to be focusable. They’re designed to work with keyboard interaction out of the box.

Use semantic HTML! It helps screen readers interpret elements correctly and supports built-in accessibility. Avoid using non-semantic elements like <div> or <span> for interactive behavior unless absolutely necessary.

Divs That Pretend to Be Buttons

Sometimes you're forced to use a <div> as a button due to platform limitations. If you must, you’ll need to add:

• tabindex="0"
• role="button"
• JavaScript event listeners

But that’s a lot of extra work—just use a <button> whenever you can.

Semantic vs. Non-Semantic Buttons

Let’s compare a semantic button versus a non-semantic one.

Semantic example: A <button> element with proper styling. It behaves as expected. You can activate it with Enter or Space, and it supports accessibility out of the box. No JavaScript is required unless you're adding extra functionality, like opening a dialog or toggling a menu.

Non-semantic example: A <div> styled to look like a button. It requires:

• tabindex="0"
• role="button"
• JavaScript listeners for click and keypress

If these are missing, the element won’t be accessible via keyboard, and you’ll have a WCAG 2.1.1 failure.

Code Editor Recommendations

Question from audience: What code editor do you recommend for practicing semantic HTML?

Answer: I bounce between VS Code and Sublime Text. VS Code is great for GitHub integration and advanced workflows. Sublime is fast and lightweight for quick edits.

Common Keyboard Failures

Let’s walk through a real-world failure using a popular Webflow component library. I love using Relume, but some components in their library look correct but aren't built accessibly.

In this accordion component, I try to tab into the accordion. My focus skips right past it—straight from the back button to the contact button. Why? Because the “accordion toggle” is a <div> with no tabindex or role. It’s not in the focus order, and it’s not functional for keyboard users.

This is a WCAG 2.1.1 failure. These components may work with a mouse, but they are completely inaccessible to keyboard-only users.

Zoom-In and Visual Demos

[Crystal increases zoom to 250% on screen for better visibility.]

Link vs. Button

This is a common area of confusion.

• Links: Navigate to another page or section
• Buttons: Perform an action (e.g., open a modal, submit a form)

Does Mismatching Elements Fail WCAG?

Q: Is it a WCAG failure to use a button styled as a link or vice versa?

A: Technically, no. It’s not a failure per spec (WCAG 4.1.2), but it’s bad usability. Users expect links to navigate and buttons to act.

Always:

• Use <a href> for links
• Use <button> for actions
• Style them differently to convey purpose visually

Keyboard Traps (WCAG 2.1.2)

Let’s talk about WCAG 2.1.2: No Keyboard Trap.

If keyboard focus can be moved to a component, it must also be possible to move focus away—using only the keyboard. If it requires special keystrokes, users must be informed.

Why This Matters

Traps prevent users from progressing or leaving a component. It creates a critical access barrier. Nothing is more frustrating than getting stuck somewhere with no way out—especially for keyboard-only users.

How to Test

• Use only your keyboard
• Try navigating into and out of modals, dropdowns, and widgets
• If focus gets stuck—you have a failure

Are Keyboard Traps Common?

Not really. In my years of auditing and remediation, I’ve only seen two “real” traps. They’re rare—but dangerous.

When Should You Trap Focus?

Only in modals. If you call something a modal, it must trap focus while open, and release it when closed.

You must offer a keyboard method to close the modal—usually an Escape key or a visible close button that restores focus to the trigger element.

Focus Visible (WCAG 2.4.7 + 1.4.11)

Let’s move into focus indicators and visual focus states.

WCAG 2.4.7 states that all keyboard-operable user interface components must have a visible focus indicator.

And WCAG 1.4.11 (Non-Text Contrast) requires that the focus indicator has a minimum contrast ratio of 3:1 against adjacent colors and the background.

Why It Matters

Users must be able to see where their focus is—especially people with low vision, cognitive disabilities, or anyone using a keyboard. It’s not just a usability issue; it’s a compliance issue.

How to Test

• Navigate using only your keyboard
• Can you clearly see which element is focused?
• If not, you have a failure

Contrast Testing Demo

I’m using the TPGi Color Contrast Analyzer tool to test a variety of custom focus styles. Some of them fail the 3:1 contrast ratio.

Example: A light blue focus ring on a white background only meets a ratio of 1.9:1—this fails WCAG.

You must test focus contrast between:

• Focus outline and background
• Focus outline and the focused element itself

Visual Demo Details

One style I tested used a background color on focus (teal). On buttons and links, this failed contrast. On input fields, it passed—because of the blinking text cursor (caret), which serves as a non-color focus indicator.

Pro tip: Use more than just color to show focus. Add outlines, thicker borders, or a combination of styles.

Global CSS Focus Style (Recommended)

I shared a global focus style that includes a black outer outline with a white inner outline. This works on both light and dark backgrounds, but you should still test it in your environment.

Hover States vs Focus States

Hover states are exempt from WCAG 1.4.11 because the mouse cursor counts as a visible indicator. But keyboard focus must have adequate contrast and visibility.

Demo: Focus Indicator Failure

Let’s look at a real-world failure where there is no visible focus indicator.

I begin tabbing through the page—at first, I can see where focus is. But when I reach a dropdown, the indicator disappears. It comes back on the next element, but during that section, the user has no idea where they are. That’s a WCAG 2.4.7 failure.

Inspecting the Failure

I open the browser's developer tools and inspect the element. I switch to the focus state and immediately see the culprit: outline: 0;

This is bad practice. Removing outlines without providing a visible alternative focus style is a major accessibility issue.

Why It Happens

Some designers remove focus styles to improve aesthetics for mouse users—but this completely breaks accessibility for keyboard users.

Don't do this. Use outline styles, box shadows, or thick borders—but never remove focus indicators unless you replace them with something visible and compliant.

Global Focus Style Snippet

I shared my go-to global style in the chat. It uses a black outer outline and a white inner outline—sufficient contrast for most backgrounds. But again, always test!

Focus Order (WCAG 2.4.3)

Let’s talk about focus order and how to keep it logical and predictable.

WCAG 2.4.3 requires that when navigating a page sequentially, the focus order must preserve meaning and operability. This is especially important for screen reader and keyboard users.

How Focus Order Works

Focus order follows the DOM (Document Object Model)—top to bottom.

Even if you use CSS to visually reposition something, its place in the DOM determines where it lands in the tab order.

For example, if your header is coded last but styled to appear first, users will encounter it out of order. That’s a failure.

Using ARC Toolkit

I demo the ARC Toolkit, a free browser extension that shows visual tab order.

It helps you test if your tabbing sequence makes logical sense. If it jumps randomly or skips key elements, it likely fails WCAG 2.4.3.

Tab Index Values Explained

• tabindex="0": Default tab order, used for custom interactive elements
• tabindex="-1": Removes from tab order but can be focused with scripting (e.g., modals)
• tabindex="1+" or higher: Never use. Overrides logical flow and often causes failures

Common Tabindex Mistakes

Let’s go deeper on why positive tabindex values (like tabindex="1", 2, etc.) should be avoided.

They hijack the natural tab order. If an element with tabindex="1" is placed at the bottom of the DOM, it will receive focus before everything else—even if it appears visually last.

This confuses users, breaks flow, and violates WCAG 2.4.3.

Better approach: Use tabindex="0" for custom interactive elements when needed, and tabindex="-1" for modals or temporary focus shifts that are not part of the regular tab sequence.

Screen Reader & Voice Control Compatibility

Label and name consistency is crucial—not just for screen readers, but also for voice assistants like Siri, Alexa, and Google Assistant.

If the visible label says “Submit” but the accessible name (via aria-label) says “Send message,” voice control users who say “Activate Submit” won’t be able to trigger the control. The name and label must match.

Voice Navigation Matters

Voice control is going mainstream, not just for accessibility but for convenience. Tools like Dragon NaturallySpeaking are used for full voice-driven navigation. The voice tech market is projected to reach $83 billion by 2032.

Final Thoughts

• Keyboard access is not optional—it’s essential.
• Use semantic elements. Avoid traps. Always test focus indicators.
• Don’t be afraid to use tools—Color Contrast Analyzer, ARC Toolkit, and your own keyboard are your best assets.
• Accessibility doesn’t require dev skills to begin. Anyone can test. Anyone can advocate.

Advocacy & Community

Remember: accessibility is about people, not just standards. Advocate for logical focus, inclusive design, and clear navigation—even if you’re not writing the code yourself.

If you have questions about WCAG vs. usability or anything we covered, reach out in the Accessibility L&D Slack, the A11y Book Club, or connect with me on LinkedIn.

Keyboard accessibility is not innovation—it’s inclusion.

Connect & Keep Learning

Follow me on LinkedIn for more a11y tips. I’d love to connect with you.

If you're passionate about learning, join the Accessibility Book Club on LinkedIn. We read a book each month and explore accessibility together.

Nicole L’Etoile:

Thank you so much, Crystal. I always learn something new when you present, and I love going back to the recordings to catch even more details.

Everyone, thank you for joining us today. This was the kickoff session, and we hope you’ll come back for more in the Summer of Access series.

We'll share the recording, slides, and links soon. Be sure to connect with Crystal, follow her on LinkedIn, and join the Accessibility Book Club.

Have a wonderful day. See you at the next one!