Hacker News Reader

Comment by zero_shift | Hacker News Reader

What does Tailwind have to do with accessibility? Most significant HTML markup is block level elements. The CSS is completely orthogonal.

I feel like old-school frontend devs bring up accessibility as a kind of bogeyman.

It reminds me of the myth that CSS style X or Y breaks accessibility "because screen readers expect semantic CSS classes". Zeldman (of A List Apart) promulgated that disinformation for years, until someone actually told him screen readers don't work that way. 90% of people who use a11y as a rhetorical cudgel have never actually used AT themselves.

View on HN

I'm not familiar with that old tale about Zeldman. It's true that assistive technologies don't know about CSS class names but CSS absolutely can affect a non-sighted screen reader user's experience.

I don't use Tailwind so I don't know if it makes it easier or harder to do the right thing when needing to hide something from everyone or only visually hiding something. Because it's CSS, it can't take care of only hiding something from assistive technologies.

The structure of your CSS, and the structure of your divs, do not affect AT experience. This is misinformation.

As mentioned below:

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).

Sure. I don't know where you're claiming that misinformation is coming from, it doesn't have anything to do with what I wrote. I was referring to CSS properties that affect the accessibility tree.

The person I am replying to

1. Argues that Tailwind requires div-itis

2. And that divs affect the accessibility tree

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.

> 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)

I can do a lot of layout without divs. Adding aria to divs is an anti-pattern and likely a worse experience than semantic elements.

You might need some extra divs for layout sure. But I guarantee less than most people are using if they markup their content first.

Remember divs mean nothing. So the opening example on the Tailwind website is the accessible equivalent of “blah blah blah”.

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.

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

Reply on news.ycombinator.com