Unfortunately there are still plenty of issues with the details element, especially around accessibility. Read more here: https://cloudfour.com/thinks/a-details-element-as-a-burger-m...

Hopefully this will change soon. I’ll amend the article when this will be the case.

As someone who actually uses screenreaders and voice control on a daily basis, most of that is not a huge deal. The "a" element has similar accessibility ratings and holes in implementation.

Appreciate you sharing your direct experience!

Would you mind contacting me at the email address in my profile? I’m about to release an open source thing and I would like to understand some accessibility issues.

Referenced in that article is: https://adrianroselli.com/2019/04/details-summary-are-not-in...

Which says JavaScript is required and simplest solution for building this menu. It also states to try to avoid them when possible.

> Which says JavaScript is required

Only if you want to polyfill for pre-2019 browsers

https://caniuse.com/?search=details

You missed the point then. You're probably going to need to use ARIA to attach and toggle the appropriate states in real time and that is only going to work with JavaScript.

I'd be interested in a similar review of client-specific gaps w.r.t the dialog element (which is even newer to the mainstream, i.e. likely the assistive tech has similar/worse implementation lag).

You should still wrap the list in a <nav> element to give the browser the context about what the menu represents.

Also, while details/summary support in browsers and other user agents and tools is improving over time, it is still not perfect for ... nearly anything. Sadly.

https://adrianroselli.com/2019/04/details-summary-are-not-in...

Perfect is the enemy of the good. It's a reasonable general purpose choice. Of course don't use it if you have stricter requirements.

FWIW This article is almost 4 years old. When it was written 3 years hadn’t passed since Firefox had full support in Firefox 48. Meaning that more time has passed since this article was published then the time between Firefox support and the publication.

Yes, yet last update was last year and coincidentally mentions article "A details element as a burger menu is not accessible" Published on September 20th, 2022:

https://cloudfour.com/thinks/a-details-element-as-a-burger-m...

I don’t think we should take this article at face value. Putting a heading <h2> inside the <summary> is weird and the aforementioned article recommends against it (most experienced web devs know not to put headings inside interactive elements other then <a>).

On top of that we have people in this threat that use screen readers and claim that they have no problems with <details>/<summary> which aren’t present in other elements[1].

1: https://news.ycombinator.com/item?id=34547915

worth pointing out that the link is almost 4 years old - which is an age, for browsers. Things might be better now (I've not tried).

This is really cool, thanks for pointing it out!

I used to use a combination of checkbox & divs to show main part, the logs & data tabs on mobile page e.g. https://hukamnama.bydav.in

Now, I found details,& I keep the main page visible all times in a div, & then horizontal accordion styles as Details underneath it for History, Logs & other stuff e.g. https://spa.bydav.in/odo.html (type foo in the box to see page)

Really wish there were a Markdown equivalent for this.

There is probably one of hundreds of markdown dialects, that supports it. Besides, markdown supports directly putting HTML into the markdown text, so it kind of supports all of HTML. How it is rendered depends on the tool you use for that, rather than on markdown as a format.