How Do I Make Webflow Dropdowns and Accordions Keyboard Accessible?

Why do so many Webflow accordions break for keyboard users?

They break because they are built from a plain div and a click interaction. A mouse can click a div, but a keyboard cannot reach it or press it. So a person navigating with the Tab key hits the accordion and nothing happens. The content is trapped, and they never see it.

Many people use a website without a mouse. Some rely on the keyboard because of a motor condition. Some use a screen reader like NVDA or VoiceOver, which navigates by keyboard under the hood. If your dropdowns and accordions only respond to a mouse click, all of these people hit a wall on your Webflow site.

This is not just a kindness issue. It is a legal and quality issue. The Web Content Accessibility Guidelines, known as WCAG, require that everything you can do with a mouse also works with a keyboard. An accordion that only opens on click fails that rule. The good news is the fix is straightforward once you know what to change.

What does keyboard accessible actually mean?

Keyboard accessible means a person can reach, open, and close the element using only keys. They Tab to it, press Enter or Space to open it, and press Escape or Enter to close it. The element also shows a visible focus outline so they can see where they are. No mouse required, at any step.

WCAG spells this out. The keyboard rule says all functionality must be operable through a keyboard. The focus visible rule says the focused element must have a visible indicator. Together they mean two things for your accordion. It has to respond to key presses, and it has to show which item is focused.

Focus is the piece people forget. When you Tab through a page, one element at a time becomes focused, and there should be a clear outline around it. If you have removed those outlines for looks, keyboard users are lost. I made the full case for keeping them in designing accessible focus states in Webflow.

Is Webflow's native Dropdown component accessible?

Webflow's built-in Dropdown component is a good starting point, because it is designed to respond to the keyboard. A user can Tab to the toggle, open it, and move through the links. It is far safer than a dropdown you build from scratch with a div and an interaction.

That does not mean you can ignore it. You still need visible focus states on the toggle and the links inside, and you should test it yourself with the keyboard. Native components give you a solid base, but styling choices can still undo their accessibility, especially if you strip focus outlines or hide the toggle text.

The bigger risk is the custom dropdown. When people want a look the native component does not give, they build one from a div, a click interaction, and show-hide animations. That version usually has no keyboard support at all, because a div is not a button and the browser does not treat it as one.

How do I build an accessible accordion the simple way?

The simplest path is the HTML details and summary elements. A details element with a summary inside is an accordion that the browser makes keyboard accessible for free. It opens and closes on Enter and Space, it is reachable by Tab, and screen readers announce its state. You add it through a Webflow embed.

Drop an HTML embed where you want the accordion, and write a details element with a summary as the visible label and your content below it. That is the entire structure. The browser handles the open and close behavior, the focus, and the announcements. You then style it with your own classes so it matches the rest of the site.

I like this approach because it moves the hard part, the interaction logic, onto the browser, which already does it correctly. You are not reinventing a control that has an accessible version built in. When I compare patterns for grouping content, I weigh this in choosing between tabs and accordions in Webflow.

What if I need a custom accordion with animations?

If you need custom animation, build the toggle from a real button element, not a div. A button is reachable and pressable by keyboard automatically. Then add ARIA attributes so screen readers know the state, and wire your Webflow interaction to the button instead of a plain container.

In Webflow you can set an element's tag or use a Link Block styled as a button, but the cleanest route is an element that is truly a button so the keyboard treats it as one. Attach your open and close interaction to that element. Because it is a button, Tab reaches it and Enter and Space activate it without extra code.

Then layer on the meaning. Add an aria-expanded attribute that reads true when open and false when closed, and use aria-controls to connect the button to the panel it opens. Webflow lets you add custom attributes in the element settings, so you can set these without leaving the Designer.

How do I add ARIA attributes in Webflow?

Select the element, open the settings panel, and scroll to the custom attributes section. Add the attribute name and value there, such as aria-expanded set to false. These attributes tell assistive technology what the element is and what state it is in, which turns a silent control into one a screen reader can describe.

The attributes that matter most for an accordion are aria-expanded on the toggle and aria-controls pointing to the panel ID. For a panel that is hidden when collapsed, you also want it truly hidden from assistive tech when closed, not just visually. A control that says it is collapsed while its content is still read aloud is confusing.

Static attributes are a start, but a fully custom accordion needs the aria-expanded value to flip as it opens and closes. That usually means a small script. This is exactly the trade-off. The details element gives you correct behavior for free, while a custom build gives you more control at the cost of more work to keep it accessible.

How do I test that it actually works?

Put the mouse away and use only the keyboard. Tab to the control, press Enter or Space to open it, check that focus is visible the whole way, and press Escape or Enter to close it. Then run an automated checker like axe or Lighthouse to catch what your eyes miss.

Manual keyboard testing is the honest test, because it copies what a real keyboard user does. If you cannot reach the accordion, or you open it and lose track of where focus is, that is your bug. Fix it before you ship. This takes two minutes and catches the most common failures.

Automated tools add a second layer. The axe extension and the Lighthouse accessibility audit in Chrome DevTools flag missing attributes, low contrast focus states, and unreachable controls. They do not catch everything, but they catch a lot fast. I walked through a full pass in running an axe and Lighthouse accessibility audit on Webflow.

What is the easiest win here?

The easiest win is to stop hiding focus outlines and to prefer native elements. Keep visible focus states, use the details element for accordions, and use Webflow's native Dropdown instead of a div-based copy. Those three choices handle most keyboard accessibility before you write a single ARIA attribute.

Accessibility feels heavy when you imagine rebuilding everything. In practice, most of the wins come from a few habits. Use real controls, keep focus visible, and test with the keyboard. Do that and your Webflow site works for far more people, including the ones your competitors quietly lock out.

If your Webflow site has dropdowns or accordions that only work with a mouse, and you want them fixed properly for keyboard and screen reader users, let's connect. I am happy to audit your interactive elements and get them working for everyone who visits.