Another selfish reason: web pages just work a lot better when you use the actual HTML elements, especially when you compose them together. React projects often mix several component libraries together to make a comprehensive UI. All of these libraries behave differently in subtle ways. When you compose them together, the differences compound: focus is not restored to the button that opened a dialog when it is dismissed, there are 4 different blues used on the page, the date input doesn't use your country's date format.
When you use HTML primitives like inputs with associated labels, the new popover API, dialogs, details + summary elements, their behaviors are all made by the browser vendor and are designed to compose with each other. It really is a difference of night and day, and for free. We don't take advantage of the amazingly powerful tools we have been given.
Flimm 1 hours ago [-]
I wish I could agree with you, but in my experience the built-in controls have many flaws and have remained stagnant for years or decades.
naavis 24 minutes ago [-]
What kind of flaws did you have in mind?
flomo 20 minutes ago [-]
Just some blatantly obvious examples: Select Multiple was some Windows 3 garbage, and HTML didn't have a 'combobox', much less a 'multi-combobox'. (MDN says datalist is not supported on Firefox, so maybe it still doesn't.) So write it yourself, or use a library. The form validation stuff is still bad, and idk if modern desktop browsers have a good date control.
airtonix 2 hours ago [-]
[dead]
energywut 4 hours ago [-]
If only we didn't need to resort to selfish reasons for accessibility. Even looking past the idea that most, if not all, of us will benefit from a more accessible world, it makes me so sad when I hear people say "it's just not worth it".
To me that's equivalent to saying, "we know our system has bugs, but we only want our blind users to experience them". It's just... such a downer of a way to look at the world.
flomo 4 minutes ago [-]
Just like any other bugs, you cannot vamoose your way into fixing them by appealing to people's inner chakra or whatever.
Accessibility is really a nitty-gritty 'policy and procedure' discipline, subject to the bureaucracy. The way you improve it is doing things right to begin with, and flagging PRs not doing it. Its one of those things which comes down to the implementation details.
burningChrome 4 hours ago [-]
>> it makes me so sad when I hear people say "it's just not worth it".
Companies are going to find out the hard way then. I work for a large corporation and we've had a consistent stream of companies and individuals contacting us about accessibility with several of our apps and sites.
This means more time to fix or completely redo these because they built them with accessibility issues baked into them and now we're tasked with fixing them or else deal with the legal ramifications.
Now that several states have included anything online or digital in the ADA, that means we now have a handful of law firms in CA and NY that are filing accessibility lawsuits. Just in 2024 there were over 4,000 lawsuits filed, the majority of them at the state level. The old adage that companies were taking a risk by not having their online apps and sites being accessible is a very real threat now.
I feel like the trend is finally starting to turn and companies are taking accessibility a lot more seriously now.
ethin 3 hours ago [-]
I completely agree, as someone who is disabled and needs to use assistive technology every day. Honestly, I feel like this is a bipartite problem:
1. Companies and individuals don't think about accessibility when designing software. It's from my experience always something that's bolted on after the fact (which only makes adding it in an order of magnitude more difficult). There are exceptions, but in my experience they're rare.
2. Our education system doesn't teach people about this, in practically any capacity, unless you, e.g., go into the education system specifically to work with individuals with disabilities. But if your just an ordinary student taking the usual course classes, it's never mentioned, not even in passing. Or at least, it wasn't mentioned at all in passing when I was in school, unless the teacher brought it up as more of an aside, and even then there wasn't a dedicated class on it.
Granted, the second part is more of a "developer" problem, but people not knowing about individuals with disabilities at all, or what they're capable of if you give them the tools/skills, etc., is also a massive problem. Don't get me wrong: I'm happy to educate when people get curious and ask, and I actively encourage it. But I shouldn't have to. This is something our school system should be teaching people about. An accessible world is better for everyone in pretty much every way.
TheAceOfHearts 3 hours ago [-]
To offer a bit of hope, both the quality and amount of information available nowadays regarding accessibility is at an all-time high.
I remember comments from people who would downplay the difficulty of getting accessibility right despite the changing landscape of web development. Part of it was that web standards hadn't fully caught up in capabilities. But another part of it was just that there wasn't that much conscious effort from the open source community to treat accessibility as a priority.
Right now you can find really high quality packages with any kind of widget without sacrificing accessibility.
lynx97 14 minutes ago [-]
Now, imagine how the world feels from my perspective (100% blind). In my 20s, I was enthusiastic. Joined Debian to found the Debian Accessibility Project. Did a lot of packaging of obscure assistive technology software. Submitted a11y bugs (and actually got them fixed) to major products like Eclipse and Qt. Felt like I could really make at least a small difference. Then, time passed, and experience accumulated. I learnt that only an infinitesimal fraction of contributors is actually motivated/willing to help with niche areas like Accessibility. I learnt that the "scratch your own itch" attitude of FLOSS is a reason why Accessibility doesn't happen. Then, GNOME3 came about, and all my remaining motivation/naivety evaporated sudenly. IBM and Sun had already stopped their Accessibility efforts late 2008. And the CORBA->DBus move basically set accessibility efforts back a few years. I was devastated, and also learnt a lot of things. After that, web accessibility started to get worse and worse. These days, most of the modern web is inaccessible to people like me, only a handful of selected applications/sites do work, and the coridor is progressively getting more narrow. I know stories of 40+yo blind people loosing their jobs due to IT restructuring at their company, left and right. The digital divide is here, and nobody is really talking about it anymore, because, frankly, those "in the know" have basically given up. Its a sad story. Capitalism is simply not willing to care for small minorities. Its a fact... which took me over 20 years to fully accept.
matsemann 17 minutes ago [-]
Working on a huge government form application (lots of pages, sub sections, modals, validations etc), we of course had strict rules about making it accessible. But that made it so much easier to work/debug/test it. It being keyboard accessible made it a breeze to quickly test stuff or get to the needed state. Had muscle memory of like tab, tab, type a letter, tab, enter.
The things I did most often I had bookmarklets for.
cyberlimerence 4 hours ago [-]
A web version of curb cut effect[1], if you will. We all benefit from digital (and physical) accessibility.
The curb cut is not even that good, the new hotness are elevated crosswalks. Smooth paving also makes a big diffeerence. My wife is on a wheelchair and it's hard to overstate how much these little things improve her life.
> We all benefit from digital (and physical) accessibility
Interestingly though, in this space, wheelchair accessible sidewalks often conflict with tactile paving (for blind people). Those tactile bumps are often inside the curbs, so there's often no way for a wheelchair to avoid them.
Doxin 2 hours ago [-]
> the new hotness are elevated crosswalks.
Those are great for making cars not blast through intersections too.
robin_reala 21 minutes ago [-]
Reminder that for a surprisingly large number of sites, you’re legally required to be accessible starting in 11 days time in the EU under the European Accessibility Act.[1] Any e-commerce system has to meet WCAG 2.1 level AA, where e-commerce is defined as an online system designed to conclude a contract for a product or service between a business and a consumer.
The only real get-out clause is if you’re a microenterprise: “an enterprise which employs fewer than 10 persons and which has an annual turnover not exceeding EUR 2 million or an annual balance sheet total not exceeding EUR 2 million”.
> The active class is clearly redundant here. If you want to style based on the .active selector, you could just as easily style with [aria-selected="true"] instead.
I vaguely remember (from 10+ years ago) that class selectors are much more performant than property selectors?
robin_reala 14 minutes ago [-]
Given the morass of JS slathered on every site these days, selector performance is the least of your worries.
aitchnyu 2 hours ago [-]
Shortcat in Mac and Tridactyl in Firefox uses accessibility annotations to pick up clickable elements and help navigate using only keyboard. In future, we could have local AI agents that could use the same and solve "why is my printer not available"?
Those are some good reasons, and I can admit that they work on me.
The testing one is big, I don't want add a bunch of artificial attributes just match an element in test, it's much more natural to just target elements semantically.
blabla1224 1 hours ago [-]
The div soup is for apps and semantic html is for documents. Not knowing the difference creates this kind of frustration.
vaylian 58 minutes ago [-]
It might be that there is no built-in functionality for some things in pure HTML. But most of the time, standard HTML tags provide all the functionality you need, even for web applications. And this benefits people with disabilities.
bapak 7 minutes ago [-]
You missed the point entirely.
You should still use appropriate tags like a, button, label, input and not div, div, div, div. Even apps have links
oneeyedpigeon 60 minutes ago [-]
The problem is, a LOT of people are treating documents as if they are apps.
chrismorgan 2 hours ago [-]
> When I’m trying to debug a web app, it’s hard to orient myself in the DevTools if the entire UI is “div soup”
That’s tame. Try adding some Tailwind CSS.
After monitoring Tailwind CSS since its early days, and believing I had some pretty serious philosophical disagreements with it, I recently took an opportunity to try it out in earnest, and it is so mindbogglingly obnoxious in dev tools that I think surely I must be missing something. How do people cope with this stuff!?
If you’re not sure what I’m on about, go through some of the sites linked near the bottom of https://tailwindcss.com/. In the Inspector/Elements panel, the DOM tree is a bloated mess with a class attribute which amounts to inline styles or worse, commonly hundreds of characters long, discouraging you from using semantically-meaningful classes, and duplicating stuff enormously rather than using sane selectors; the mostly-better ones are those that have data-sentry-{element,component,source-file} attributes. The styles subpanel becomes utterly unnavigable.
(I’m not saying everything in Tailwind is bad; I think I am likely to use a limited utility styles approach more than I did in the past, and there are a couple of other things that are provoking thought in me, and I think it would be more suitable in apps than in marketing-style websites. But the total embodiment of it is not for me.)
troupo 2 hours ago [-]
> discouraging you from using semantically-meaningful classes, and duplicating stuff enormously rather than using sane selectors
In any big site "semantically meaningful classes" are a similar mess, and the duplication is both enormous and spread out and suffers from accidental cascades.
rrgok 1 hours ago [-]
While I mostly agree with the article... Isn't this phrase regarding the table as divs a little bit over-dramatic
If I’m trying to debug this in the DevTools, I’m completely lost. Where are the rows? Where are the columns?
I mean, if you can't decipher the rows and the columns from that divs...maybe this is job is not for you? I understand, there could be some divs soup that are really hard to decipher, but this it not the case. Poor example, please bring more complex example with test associated.
OtherShrezzing 1 hours ago [-]
I think it’s fine to bring an illustrative toy example to an article.
Everyone who works outside frontend will need to parse it a lot. Everyone who works in frontend will be able to project a more complex div soup they’ve experienced in their own projects.
eviks 2 hours ago [-]
> Now I can easily zero in on a table cell, or a column header
Isn't inspecting the actual cell /header easier?
vivzkestrel 5 hours ago [-]
Unpopular opinion: React is an abomination. The websites made with react are an abomination. They are bloated as hell and the performance goes down the drain with every single one of them. Just like we have Earth day and father's day, we need a "No More React" day where everyone across the world gets up and picks as different framework even if means temporary losses in productivity. After all, the long term gains from lower bandwidth and data transfer and optimized load times far far outweigh the short term losses
crab_galaxy 4 hours ago [-]
This is a very popular take, but it has absolutely nothing to do with the article.
SirSavary 5 hours ago [-]
What does this have to with TFA? This is about accessibility, it has nothing to do with React (or any one web framework).
When you use HTML primitives like inputs with associated labels, the new popover API, dialogs, details + summary elements, their behaviors are all made by the browser vendor and are designed to compose with each other. It really is a difference of night and day, and for free. We don't take advantage of the amazingly powerful tools we have been given.
To me that's equivalent to saying, "we know our system has bugs, but we only want our blind users to experience them". It's just... such a downer of a way to look at the world.
Accessibility is really a nitty-gritty 'policy and procedure' discipline, subject to the bureaucracy. The way you improve it is doing things right to begin with, and flagging PRs not doing it. Its one of those things which comes down to the implementation details.
Companies are going to find out the hard way then. I work for a large corporation and we've had a consistent stream of companies and individuals contacting us about accessibility with several of our apps and sites.
This means more time to fix or completely redo these because they built them with accessibility issues baked into them and now we're tasked with fixing them or else deal with the legal ramifications.
Now that several states have included anything online or digital in the ADA, that means we now have a handful of law firms in CA and NY that are filing accessibility lawsuits. Just in 2024 there were over 4,000 lawsuits filed, the majority of them at the state level. The old adage that companies were taking a risk by not having their online apps and sites being accessible is a very real threat now.
I feel like the trend is finally starting to turn and companies are taking accessibility a lot more seriously now.
1. Companies and individuals don't think about accessibility when designing software. It's from my experience always something that's bolted on after the fact (which only makes adding it in an order of magnitude more difficult). There are exceptions, but in my experience they're rare.
2. Our education system doesn't teach people about this, in practically any capacity, unless you, e.g., go into the education system specifically to work with individuals with disabilities. But if your just an ordinary student taking the usual course classes, it's never mentioned, not even in passing. Or at least, it wasn't mentioned at all in passing when I was in school, unless the teacher brought it up as more of an aside, and even then there wasn't a dedicated class on it.
Granted, the second part is more of a "developer" problem, but people not knowing about individuals with disabilities at all, or what they're capable of if you give them the tools/skills, etc., is also a massive problem. Don't get me wrong: I'm happy to educate when people get curious and ask, and I actively encourage it. But I shouldn't have to. This is something our school system should be teaching people about. An accessible world is better for everyone in pretty much every way.
I remember comments from people who would downplay the difficulty of getting accessibility right despite the changing landscape of web development. Part of it was that web standards hadn't fully caught up in capabilities. But another part of it was just that there wasn't that much conscious effort from the open source community to treat accessibility as a priority.
Right now you can find really high quality packages with any kind of widget without sacrificing accessibility.
The things I did most often I had bookmarklets for.
[1] https://en.wikipedia.org/wiki/Curb_cut_effect
> We all benefit from digital (and physical) accessibility
Interestingly though, in this space, wheelchair accessible sidewalks often conflict with tactile paving (for blind people). Those tactile bumps are often inside the curbs, so there's often no way for a wheelchair to avoid them.
Those are great for making cars not blast through intersections too.
The only real get-out clause is if you’re a microenterprise: “an enterprise which employs fewer than 10 persons and which has an annual turnover not exceeding EUR 2 million or an annual balance sheet total not exceeding EUR 2 million”.
[1] https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%25...
I vaguely remember (from 10+ years ago) that class selectors are much more performant than property selectors?
https://shortcat.app/ https://tridactyl.xyz/about/
The testing one is big, I don't want add a bunch of artificial attributes just match an element in test, it's much more natural to just target elements semantically.
You should still use appropriate tags like a, button, label, input and not div, div, div, div. Even apps have links
That’s tame. Try adding some Tailwind CSS.
After monitoring Tailwind CSS since its early days, and believing I had some pretty serious philosophical disagreements with it, I recently took an opportunity to try it out in earnest, and it is so mindbogglingly obnoxious in dev tools that I think surely I must be missing something. How do people cope with this stuff!?
If you’re not sure what I’m on about, go through some of the sites linked near the bottom of https://tailwindcss.com/. In the Inspector/Elements panel, the DOM tree is a bloated mess with a class attribute which amounts to inline styles or worse, commonly hundreds of characters long, discouraging you from using semantically-meaningful classes, and duplicating stuff enormously rather than using sane selectors; the mostly-better ones are those that have data-sentry-{element,component,source-file} attributes. The styles subpanel becomes utterly unnavigable.
(I’m not saying everything in Tailwind is bad; I think I am likely to use a limited utility styles approach more than I did in the past, and there are a couple of other things that are provoking thought in me, and I think it would be more suitable in apps than in marketing-style websites. But the total embodiment of it is not for me.)
In any big site "semantically meaningful classes" are a similar mess, and the duplication is both enormous and spread out and suffers from accidental cascades.
Everyone who works outside frontend will need to parse it a lot. Everyone who works in frontend will be able to project a more complex div soup they’ve experienced in their own projects.
Isn't inspecting the actual cell /header easier?