It’s not Tailwind the tech, it’s the ergonomics of the tool. Tailwind’s design loop encourages “let me add a div so I have a place for my CSS class”.
I’ve usability tested and performed user research with many users needing assistive tools and I’ve used them myself as part of design.
Basic HTML authoring is good practice for many reasons.
Screen readers do not announce divs. They only read from the AOM.
A <div> itself is treated as a generic, transparent box. It doesn't get keyboard focus, and it isn't added to the screen reader's elements list (like headings, links, or landmarks).
> I’ve usability tested and performed user research with many users needing assistive tools and I’ve used them myself as part of design.
Tell me how often screen readers announce divs that have no role attributes. You are continuing to spread misinformation
This is nonsense, you can stick classes on semantic HTML elements just as easily as on a div.
And screen readers can handle elements nested inside a grouping div just fine, that’s how div’s are supposed to be used. The accessibility issues with div’s are when people repurpose them to take the place of existing semantic elements, because doing so requires handling a bunch of aria roles and attributes manually, and something invariably gets missed.
> let me add a div so I have a place for my CSS class
As opposed to what exactly? HTML doesn't let you lay out stuff properly without at least some structural divs that have no meaning.
If we have the proper aria properties for example, why does it really matter if I have extra divs (which is, again, irrespective of tailwind)