Hacker News Reader

Comment by ughitsaaron | Hacker News Reader

I had no idea about these elements or their APIs. Maybe one downside to living in JSX all the time is that it can encourage ignorance of the foundation it’s built on.

View on HN

You can use these within JSX! I use <details> and <summary> all the time. Not so much <dialog> — since there are still accessibility issues by default, I’d rather use a library that wraps it. If and when <selectmenu> drops you can bet I’ll be ditching Radix for the native solution.

I've been exploring using dialog for modals - what a11y issues does it have?

There is currently a debate about these supposed a11y issues. Some are about what happens to focus after dismissal, some are about related elements and announcements, some are about buggy implementations and non support from screen readers.

However it is my belief that these were mostly true 2-3 years ago but the myth has remained. And people still belief there are issues.

I've heard from actual screen reader users that these supposed issues are mostly non-issue. And pale in comparison from people implementing their own.

Looks like the sibling comment is correct and that <dialog> a11y has improved recently: https://adrianroselli.com/2020/10/dialog-focus-in-screen-rea...

I still would be careful using it! MDN has a section on accessibility considerations: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di...

The W3C also has a pretty great set of examples of how to make complex widgets like dialogs accessible (not that a11y is just a checklist): https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/

> I still would be careful using it! MDN has a section on accessibility considerations

In fact, it seems pretty unequivocal: “The native HTML <dialog> element should be used in creating modal dialogs”

Reply on news.ycombinator.com