[mhitza]

Using tailwind doesn't lead to any inherent concession of accessibility. How do you come to that conclusion?

If I look at their component library, they also do the work of including aria attributes for you https://tailwindcss.com/plus/ui-blocks/marketing/sections/pr... (first exsmple with free code I've found).

If we're not talking landing pages, which are more like digital brochures, I always start with markup and then add css classes on top.

[xigoi]

> If I look at their component library, they also do the work of including aria attributes for you

Using ARIA attributes instead of semantic elements is bad for accessibility.

[rhdunn]

How are ARIA roles/attributes bad for accessibility?

Sure, if there is a HTML element that works then use it, but not every UX pattern is expressible in HTML without specifying roles/attributes (e.g. tabs [1]) and not all browsers support recent HTML elements/attributes (such as using details/summary for accordions).

ARIA patterns [2] has a list of examples for UX components and their examples specify/use ARIA roles/attributes.

[1] https://www.w3.org/WAI/ARIA/apg/patterns/tabs/

[2] https://www.w3.org/WAI/ARIA/apg/patterns/

[extra88]

WAI's APG patterns exist to document how ARIA attributes should work, they don't advocate for them to be used in place HTML elements. They also don't test to confirm that they actually work in browsers or with assistive technologies (some specific patterns are fine). For web developers, they're helpful for documenting expected keyboard interaction support and other norms.

Are you still coding to support Internet Explorer? All browsers have supported details/summary since an Edge switched to Chromium in 2020.

https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

[stefan_lec]

Details/summary had quirky/inconsistent handling by screen readers for quite a while after it reached full browser adoption, unfortunately. Not even sure if they’ve fixed it here in 2026, honestly.

https://www.scottohara.me/blog/2022/09/12/details-summary.ht...

While it’s good to use well-implemented semantic elements when possible, there are still plenty of places where either the built-in browser behavior isn’t actually very accessible (like native form validation), or where you just can’t avoid it (using aria-disabled instead of disabled for submit buttons, setting aria-pressed for toggle switches, setting aria-expanded for buttons that trigger modals, situations where you need aria-hidden/sr-only, etc).

Though once popovers and the invoker command api hit baseline widely available, we’ll be able to drop some of that.

[extra88]

I think popover and invoker commands with polyfills are already the way to go. The polyfills are small (and if you only want to use the "show-modal" invoker, it's like 10 lines to feature detect and polyfills just that).

Many good uses of popover really needs anchor positioning. There's a polyfill for that as well but it's not small.

[fluffybucktsnek]

It should polyfills are basically a no-go for no-JS sites.

[TonyAlicea10]

Who said inherent. The design loop of “I need a div for my CSS class” is an ergonomic problem not a concession.