While I agree I do think there's some "aspiration of purity/correctness" in your approach that I've long let go of.
I look at the royal mess that is HTML/CSS/JS as a necessary evil, required when we want to target browsers. To me it's "just the presentation layer".
In my work I put a lot more emphasis on correctness in the db schema, or business logic in the backend.
When it comes to the messy presentation layer I prefer to write a little as possible, while still ending up with somewhat maintainable code. And for this Tailwind fits the bill really well: LLMs write it very well, new devs understand it quick, and it's quite easy to read-back/adjust the code later.
I 100% agree a Tailwind project is not the best way for a new dev to learn HTML/CSS. But then I prefer the new dev to focus on great db schemas, intuitive APIs, test-able biz logic, etc. Fiddling with the mess that's HTML/CSS is not the place where I consider human attention is best spent on (or where developers pick up skills to become much better developers).
This isn't about "purity/correctness" it's about the real experience of a blind person. Accessibility means caring about the HTML.
Your comment only mentions developers as the audience of HTML authoring, as opposed to users, which is a common attitude and the core problem with Tailwind.
I use Tailwind and have all kinds of "screen reader" directives in my templates.
Not sure if it helps, but if we get our first blind user I will gladly make some admends to make it more usable for them.
It seems that Tailwind is now blamed for the mess that is HTML/CSS. Tailwind certainly allows for accessible designs; it may not be the ideal solution, sure, but what we aim for is "good enough".
> Not sure if it helps, but if we get our first blind user I will gladly make some admends to make it more usable for them.
I have heard "we don't have blind customers" argument many times before. Apart from ethical issues that this raises, ADA requirements, technically, don't care if you have blind users or not. Accessibility is still required...
It's a great way to make an easy $10-30k as a law firm too when you sue them. Especially when you have definitive statements like "we purposely don't care about a11y until we get sued for it."
> but if we get our first blind user I will gladly make some admends to make it more usable for them.
Isn't this slightly backwards? Why would blind users sign up if the platform isn't usable for them in the first place? It has to be usable for them for them to become users :)
> Not sure if it helps, but if we get our first blind user I will gladly make some admends to make it more usable for them.
How will you know if they are unable to use your site? They'll just leave.
It's not just blind people, but also people with reduced eyesight. As I'm getting older, I really appreciate good contrast and the possibility to zoom in without breaking the layout.
And how does tailwind or the structure of the underlying html of the page change or affect that?
If Tailwind lends itself to using pixels instead of relative units for things that should be relative (like font-size, line-height, etc.), that's a problem. For those users, the HTML elements matter less unless they're savvy users who have custom user stylesheets to selectively adjust the appearance of content instead of changing everything on the page by zooming (e.g. make links, buttons, paragraphs, list items bigger and/or a different font or weight).
This is not true. Tailwind defaults to rem as the underlying length unit for almost everything. You have to go to extra effort in most cases to use px.
People always forget they're one unlucky event from losing their sight, hearing, dexterity, or more. Hell, like you say, even aging's enough to do it. Accessibility suddenly becomes a lot more important when you're on the other side of the "not a priority" talk.
if we get our first blind user I will gladly make some admends to make it more usable for them.
Not good enough. You have to be accessible before it is needed in order to avoid legal liability.
And how do you expect to get a blind user if they already cannot use your product?
None of the doctors I build web sites for are currently blind. I know this because I talk to them regularly. But I still build the web sites for the future, when HR might hire a doctor or nurse or other person who is blind, or partially sighted, or has trouble with their muscles, or has difficulty distinguishing colors.
Doing the right thing isn't that hard. Not doing it is just lazy.
You call it lazy. I call it "focus" or avoiding pre-mature optimization.
I find the "legal liability" claim hilarious... I do better than 95% of the web: as I said I HAVE some screen reader directives (just did not test it), and labels to make the app more accessible.
> You call it lazy. I call it "focus"
Is this to be read that disabled people and their needs, or more directly from the replied-to comment, "doing the right thing", are not a focus of yours, flossly?
A former coworker of mine opened a meeting saying "we are so good, we care about accessibility". I had been complaining for months and finally a customer had said "we won't buy your product unless it complies to the law".
I find the "legal liability" claim hilarious
You must have six million dollars laying around. Because that's the penalty Target paid for not having an accessible web site.
In 2008..
That wasn't even a regulatory penalty, but a class action by the National Federation of the blind.
https://en.wikipedia.org/wiki/National_Federation_of_the_Bli...
We use tailwind and are capable of building accessible websites without any issue. People could make all the same mistakes with CSS for accessibility. It’s the not knowing how to make accessible content that leads to inaccessible content, not the tool you use to implement the styling.
Sounds like you're kind of just talking your book though. Person who makes accessible sites suggests you need an accessible site. Blind people aren't the only ones who might need modifications. You could have an infinitely long list of adjustments for all kinds of disabilities, and tell me I'm lazy for not doing each of them. Why are blind people special?
You are lazy for not doing accessibility adjustments, because accessibility isn't for blind users. It's for the deaf ones, the ones with poor eyesight, the ones with mental deficiencies, the ones with motor issues like Parkinson's, the ones browsing your site shitfaced at 4AM, and so on and so on.
Accessibility isn't a checklist to cover your ass for a percentage of the population: it's for everyone. It literally makes your website less shit. You slapping an aria-label doesn't fix things.
Every moment you spend doing accessibility is a moment you spend not doing other things. You could argue it has a high RoI to do accessibility, fine, but that doesn't make it lazy _not_ to do it. Maybe I have even higher RoI/EV stuff to be doing.
> Maybe I have even higher RoI/EV stuff to be doing.
I mean, to readers of these comments, I think it's right there for you: 0x3f will take "higher ROI" over "accommodate and support disabled people".
Yeah, thats explicitly what I'm saying so I'm not sure it needs repeating. That has very little to do with it being lazy though, is the point.
We were already implicitly discussing RoI when we were talking about 'legal consequences' above. This is how people decide between alternatives, generally.
You just told a bunch of potential and current customers that they're not worth the ROI.
Pretty sure they'll remember that, and they'll talk about it a lot.
Picking subsets of customers to focus on is a totally standard part of running a startup or company in general, so this is not really news or any kind of threat.
You might as well tell me the suburban moms are not going to buy my developer tool because I've personally slighted them with the branding. Why would I care? I made my decisions knowing this.
In fact ditching low RoI customers is incredibly common and good startup advice.
This is just admitting that your product is small and unimportant.
Hardly, I can trivially find Fortune 500 websites without accessibility.
I suspect as the years change and you continue to get older you will likely revisit this idea mentally.
But you do you, boo
Ok well enjoy your thought-terminating cliches in the meantime
Accessibility is done while you do it. Not as an afterthought.
But if you're having a higher ROI writing absolute crap, feel free, it's not my website.
You're just expressing a normative view here, it's not very interesting or informationally-dense. You care about accessibility more than I do. That doesn't make not doing it 'crap'.
I mentioned blind but there’s lots of others. Folks sitting a desk whose eyesight are getting worse and are scared to say so for fear of losing their job, for example. This happens.
Side note: if you aren’t deliberately choosing semantic elements and instead dropping aria attributes onto a bunch of divs this is an anti-pattern.
Knowing the DOM structure is properly engineered is the gateway to an entirely compliant end product out the gate. Leaves pros looking for the "difficultly level" on SEMRush after maxing it out.
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.
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.
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”.
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.
But why would I spend any time mastering this skill when we have AI now?
Disability software that uses both the markup and the on-screen visual for decision making is likely imminent and would render most of this no longer necessary.
Claude Cowork is already doing navigation and web browsing by screenshot showing this is possible.
I guarantee you no one is working on this.
You don’t think it’s valuable taking time to improve the interaction layer that all your users interact with your app through?
[flagged]