Hi again đź‘‹

If you’re new here - hello, and welcome!

If you’ve not yet checked out davedavies.dev - head there to find loads of free videos and articles on how to make your product pages available for everyone. And then let me know what you want to hear more about!

This week…

I was looking at FAQ sections. These do a lot of heavy lifting on your product pages, and if you get them right they’re a real winner.

Shipping. Returns. Sizing. What’s actually in the product. The FAQ section is often where the last objection gets handled before someone buys.

However - so many FAQ areas are built using outdated methods, which actively stop keyboard users from reaching them - and leave your answers sitting behind JavaScript that a crawler has to run before it can see them. Not great…

The usual old approach is a custom component. A <div></div> that hides and shows a panel when you click it. It looks good, it animates nicely, and it works perfectly with a mouse. And that was fine, in its time.

But a <div></div> doesn’t respond natively to either a mouse or a keyboard. So your devs have to add custom JavaScript to make it work. Now with JavaScript added in, it looks great - and works great with a mouse - but did anyone check with a keyboard? Possibly not.

Gif showing a FAQ question toggling open and closed

So what does great look like?

You can now use the widely supported <details>/<summary> elements. These are built into the browser and supported everywhere - and it looks something like this:

Example details/summary code block

That’s the whole thing. Opening, closing, keyboard support, screen reader support: the browser does nearly all of it, with a few gaps still to iron out on iOS.

What that gives you is really worth understanding, even if you’re not part of the dev team, because it stops so many things from going wrong.

Every custom accordion not using the <details>/<summary> pattern needs a small pile of JavaScript that someone has to write, and test, and then maintain. Every one is a fresh chance to forget the keyboard. <details> has none of that. There is no JavaScript to write and no ARIA to get wrong, because there’s almost nothing to build.

It’s also plain HTML, so the content inside is there in the page whether it’s open or not. This keeps the crawlers happy too!

Ask whoever looks after your site whether your FAQs use <details> and <summary>. It’s a question with a yes or no answer.

But here’s the catch…

You’re still responsible for making sure the content inside the FAQs is still accessible!

The element gives you the mechanics, and is accessible out of the box - but… it doesn’t automatically fix the content for you.

Here’s a great example I found this week. Nc’nean whisky distillery uses the <details>/<summary> pattern perfectly (their hover state could have a better colour contrast, but lets move past that for now). Each “accordion” has great information - helping you decide if this is the right purchase for you.

They have loads of awards - however - in the awards accordion, every award logo has an empty alt text - essentially removing it from the accessibility tree. When someone using a screen reader opens the awards accordion, they’ll hear nothing. Sometimes this is useful on images, but it’s probably not what the company wants here.

What to ask this week?

Can someone reach your FAQ panels with a keyboard? If they’re built with <details> and <summary>, yes. That one’s answered for you.

Can someone read what’s inside them? Open each panel and look for anything that isn’t text. Award logos. Certification badges. Star ratings. Size charts as images. If it’s a picture, it needs words attached, or for some of your customers it isn’t there at all.

The information is there on the page. Now make sure everyone can access it.

Talk soon,
Dave