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".
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...
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 :)
How will you know if they are unable to use your site? They'll just leave.
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.
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.
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?
You must have six million dollars laying around. Because that's the penalty Target paid for not having an accessible web site.
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...
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.
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".
We were already implicitly discussing RoI when we were talking about 'legal consequences' above. This is how people decide between alternatives, generally.
Pretty sure they'll remember that, and they'll talk about it a lot.
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.
But you do you, boo
But if you're having a higher ROI writing absolute crap, feel free, it's not my website.
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.
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 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.
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).
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.
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)
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”.
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
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.
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.