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 10 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.
Good intentions and some good ideas. But ultimately lead to a fractured, overly complicated and bloated web.
I say yes to lower level, more general capabilities. But why does that have to mean we get bad APIs (web components, indexeddb, service workers...) and lack fundamental and well established UI components (combobox, toggles, tabs, tooltips, data grids...) and incomplete implementations (lacking HTTP verbs for forms)?
(Also why we're at it, I'm going to sneak in a complaint about half baked and broken language features like `const` and `import`. Also we shouldn't have abandoned Do-Not-Track...)
sfink 11 minutes ago [-]
DNT wasn't abandoned, it was killed.
ozim 3 hours ago [-]
Second that and from my experience they are just not feasible for any modern web app.
Those controls work fine maybe for a static form on a website as parent wrote - but web applications are not websites...
ryandrake 2 hours ago [-]
To you and OP, as the movie goes: "Yeah, well, that's just like, your opinion, man."
My opinion is that we could use fewer "web applications" and more web pages that simply provide structured semantic data and then get out of the way and let the User Agent (and user himself) control the presentation of that data. Sure, some things have to be a web application. I'll grit my teeth and admit that. But many, many sites we visit could easily be raw HTML and maybe some CSS (which the User Agent is free to cherry-pick through or ignore). They would be fast, functional, accessible, (probably) more secure, (probably) more private, free of telemetry, and would better serve the user's interests over the web company's interests.
Instead we get JavaScript "instructions" from the web site, which require the User Agent to faithfully execute, often removing the user's direct access to the actual content and enforcing the web developer's opinion on how it should be presented.
If we had more use of standard controls and light markup, and less JavaSludge, maybe browsers would devote more time towards fixing and improving their standard controls.
Just another random person's opinion, but this has been a terrible direction for the web.
flomo 9 hours 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.
Y-bar 8 hours ago [-]
I can agree that it is bad. And there might be some examples where <select multiple> is the "best" way, but I cannot ever remember a real-world use case where it was not better solved using a list of <input type=checkbox> anyway.
flomo 8 hours ago [-]
Yeah sure, the 'right' way was checkboxes in an iframe. Just that the weblords care alot more about adding syntax to javascript than whatever multi-select-searchable-accessible-box you might want. The form stuff still mostly sucks.
komali2 3 hours ago [-]
I must be confused because the use case I'm thinking of is a list of 5,000 somethings that are filtered down through user-input text in the combobox, that they can then select, and selected items are then displayed as bubbles within the input field or elsewhere. Certainly can't just display 5,000 checkboxes instead :P
naavis 9 hours ago [-]
What kind of flaws did you have in mind?
PaulHoule 2 hours ago [-]
Quite a few 3rd party controls have had attention paid to accessibility and have all the right aria- and other accessibility markup.
Toritori12 7 hours ago [-]
I dont remember last time (if ever?) I saw a native date input in the wild.
bob1029 3 hours ago [-]
Last product I worked on I made this a thing. Every modern browser now renders a very competent date picker for input type="date".
I find a lot of the arguments for building inaccessible UIs seem to conflate historical web issues with modern times. Virtually everything that sucked in the core web toolkit circa 2010 has essentially been solved in 2025, even on ultra-restrictive platforms like iOS Safari.
cardanome 4 hours ago [-]
I have recently used plain old html date input in a internal tool and it works great.
Not the prettiest but I have seen much worse custom ones that were super buggy.
dgb23 2 hours ago [-]
Native date inputs have their problems, but I default to them usually because they typically have the best behavior on mobile and are localized by default.
pelagicAustral 5 hours ago [-]
textbox is the warriors way of date input. Anything else is cruft. /s
airtonix 11 hours ago [-]
[dead]
energywut 13 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.
TeMPOraL 7 hours ago [-]
It's worse than that. Accessibility is actually opposite to what the business wants, and the combined cultural and (occasionally) legal backing it has is our last line of defense of user autonomy.
Assistive software is just a different user agent. A non-standard browser interpreting the page in ways different than the vendor intended. The very same feature that enables a screen reader to help a blind person navigate, enables everyone else to identify and snip off ads and upsells, escape the thick sewage that's called "web design", and get straight to the actual thing one came for in the first place. Accessibility is the only thing that prevents the web from becoming Flash again, entirely unparseable through automated means[0].
Again, were it not for cultural and legal insistence to cater for the disabled, we'd all already be completely without agency on the web, dumb riders in a theme park paying for something at every turn. Cutting curbs and such? Why, so the users complete their "journey" faster and leave less money behind?
--
[0] - LLMs changed the equation here recently, mostly in our favor, for now. In the immediate term, they can make any website machine-interpretable no matter what the vendor does. But that's just the beginning, we don't yet know how vendors will abuse GenAI to thwart the users.
ryandrake 2 hours ago [-]
Web sites hate the idea of a web ecosystem with dozens of (if not thousands of) User Agents, each of them presenting the site in a way the user wants it to be presented. We have strayed so far from the path of HTML being text markup that suggested formatting and semantics only. We have basically handed control over all the content, its presentation, and its interaction modes, to the web developer.
My ideal version of YouTube is a bare HTML page with a single <video> element that the User Agent decides how to interpret and render. And maybe some <li> links to navigate through the site to find other features. Maybe my User Agent is a browser, but maybe it's a video player, or some kind of assistive video display for the disabled. Or a powerpoint slide. Or a command line downloader. As a user, I should have control over how the web content is ultimately rendered, and the only job for the web site is to send me structured content that my renderer can pull apart, understand, and render in the way I see fit.
Similarly, my ideal version of Amazon is a bare HTML page with a search box and a structured list of products and their attributes, that my User Agent can ingest, understand and render in whatever way it sees fit.
Web sites have totally abandoned this path of giving the user control, and now when we GET from a web site, instead of structured, semantic data, we get a big opaque blob of JavaSludge that our browser is expected to faithfully execute as-written, so that the web company gets to make all the major presentation decisions. The user is just the passenger along for the ride.
burningChrome 12 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.
typewithrhythm 8 hours ago [-]
This is a very artificial way to make the argument though; it's still not worth it from a revenue or user acquisition perspective, it's just a risk from a potentially fickle government body.
TeMPOraL 7 hours ago [-]
It's worse than not worth it, it's defeating some of the main ways they make money.
Misunderstanding this point leads to endless surprise in this topic. No, companies don't just "don't care" for some unfathomable reason. They don't want it in the first place; they begrudgingly make concessions to accessibility due to cultural and regulatory pressure.
The same things that let the disabled people participate, also help regular users escape the very traps and tricks businesses on-line use to make money. Now, supporting the former group may be a rounding error on the balance sheet, but enabling the latter to defeat monetization efforts, not so much.
rickydroll 1 hours ago [-]
Many moons ago, I attended a demo of a new software product, and without disclosing my disability to the vendor, I inquired about its accessibility features. They said that they don't do anything for the disabled because it's such a small market, and it wasn't profitable to accommodate the needs of disabled users.
I found myself irrationally enraged and had to walk away from the conversation. I thought about it when I calmed down and I realized I was feeling, "Who the fuck are you to tell me how I can live in the world?"
Dissecting these thoughts further led me to the understanding that, without accessibility, you are telling a class of people that they don't deserve access to education, government services, or commercial products.
Telling disabled people that they don't deserve access to any benefits of a civilized society is a long-standing and persistent attitude. It's roughly analogous to denying poor people health care, food, and basic shelter because all they deserve is what scraps we are willing to bestow on them.
ethin 11 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 11 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.
CoastalCoder 5 hours ago [-]
> If only we didn't need to resort to selfish reasons for accessibility.
I agree, but I think that's tantamount to wishing humans were more kind and empathetic.
If that we're the case, I suspect the world would be souch better as to be unrecognizable.
energywut 2 hours ago [-]
I genuinely believe humans are kind and empathetic by nature. I believe that humans have invented systems that penalize kind and empathetic behavior and adhere to those systems because they are familiar.
Look at what happens after a disaster or when a neighbor falls ill -- people band together and feed one another. They care for one another. They pick up the slack. Not because anyone pays them, but because it's what they intrinsically want to do.
But it only occurs during disruptions from the norm.
ryandrake 2 hours ago [-]
I believed this, too, before COVID hit and I saw ~half my country try to throw everyone else under the bus so that they could continue to eat at their favorite restaurants, and buy their khakis, and hoard goods to price gouge their neighbors, and just making a belligerent scene any time they were unable to do something the way they want to. Many people will naturally pull together and act cooperatively and altruistically, but also many, many people just live to grief everyone else.
lynx97 9 hours 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.
wizzwizz4 7 hours ago [-]
The only viable approach I can think of is to completely rewrite everything from scratch. It's a huge undertaking, but I honestly think it's less work than getting the existing software infrastructure to work accessibly. Even heroic efforts like AccessKit just aren't heroic enough.
We've got a few decent speech synths, but information about how things should be read out isn't passed through to them. That's handled by a screen reader program… except screen readers can't represent half the semantics they should, so people regularly bypass them, which leads to (a) UI inconsistency; and (b) the systems being useless if you need something other than a screen reader. AI scraper bots are the straw that broke the camel's back, so virtually no (current) website is accessible via a basic web browser any longer. UI customisability was low in the Windows 95 days, but we've managed to go backwards from there.
We might as well go the whole way, and design something that's actually usable, then put together case-by-case compatibility layers. Here's how we translate Home Office Design System HTML, here's how we translate Stacks Design System HTML, here's how we translate MediaWiki HTML, here's how we translate Wordpress Gutenberg HTML, here's how we translate Moodle HTML… here's how we represent the OpenDocument content model for reading and writing, here's how we represent the SVG content model for reading and writing, here's how we represent a login flow…
lynx97 6 hours ago [-]
"Ghetto systems" as the saying goes aren't a solution either. Those have been tried decades ago. Remember "IBM Homepage reader"? No? Probably before your time. Its a nice idea, in isolation. However, the translation layers you talk about are never going to be sufficient. You're just moving the problem. Now, if you want to use a system which doesn't have a translation layer for your ghetto system, you're out of luck again.
wizzwizz4 1 hours ago [-]
One of the translation layers can be to-spec WAI-ARIA: then anyone who can be bothered to implement their websites correctly will. (There are currently no correct implementations of WAI-ARIA: only vague approximations of partial implementations.) I don't think there's a way to salvage untagged PDF forms, except taking them case-by-case.
You're right to point out issues with "ghetto systems" – but we don't have a single computer system that actually works, and everything that does exist has fundamental design flaws that make accessibility prohibitively difficult. (Wayland somehow managed to be a downgrade from X11, which is quite a feat.)
I think a basic ghetto system with a full development environment and easily-accessible documentation would rapidly become not a ghetto system.
DonHopkins 5 hours ago [-]
M-X professor-hubert-j-farnsworth-mode
Good news, everybody! Rewriting everything from scratch has recently become a lot, lot easier, and much more fun!
Leela AI (not to be confused with Turanga Leela) learns to speak in LLOOOOMM / Cursor:
PS: Does anyone know how to make the Mac "say" command use a new fangled "Personal Voice" that you can record of your own?
8 hours ago [-]
holowoodman 8 hours ago [-]
I agree 100% and welcome any improvement for any reason.
When most or all of us benefit from "accessibility", then it isn't really accessibility. It is fixing a broken UI, period. Designers need to be shamed for not even providing a good enough UI for the average person, let alone disabled people.
energywut 2 hours ago [-]
I would argue UI that doesn't work for people with low vision is also broken UI. There's no distinction in my mind between "broken for many people" and "broken for people with disabilities". It's broken.
hiAndrewQuinn 7 hours ago [-]
These are great and humanistic sentiments, until you have to talk price. When price comes into the equation, the approach of specialized accessibility software seems to work much better in a lot of cases.
Consider a rosy hypothetical: A SaaS under truly great, enlightened leadership. The team lead knows that it would take only one two week sprint, for one focused developer, to go the last mile and make it truly accessible for all. The fully loaded cost of those developer-hours, in a very optimistic scenario, is $1000, and optically closer to $4-8000 for a US based team.
First, do those extra steps towards accessibility even break even? Second, if so, are they truly the revenue maximizing move for what that dev can do with that 2-week sprint? Sometimes, rarely, they are. In practice I suspect market research would show the opposite. This is before we add in all of the usual fog of war around how long things really take to build, whether the leadership is really as enlightened as they seem, etc.
Consider an alternative model where one company specializes in creating high quality accessibility-enhancing software. This software aims to work as a compatibility layer across most to all of the other programs a user is likely to use; perhaps they use frequent in-memory screenshots and detailed image analysis to help blind users understand what's going on. Or perhaps it's as simple as a FOSS dev focusing on making sure every terminal program they can run works well with their screen reader.
There are a plethora of benefits to this model, not least that you aren't imposing a heavy tax on everyone else for a really small customer base. This is also very specialized, customer-facing work. If there is anywhere in software you would want dedicated frontend or UI/UX expertise it would probably be the guy designing the screen reader compatibility layer.
I point to the popular extension Dark Reader as an example of this paradigm; it does a wonderful job on most websites, is easy to disable on websites where it doesn't, and doesn't cost the website runner anything to use.
Some might take issue with this for aesthetic reasons. It feels kludgy to suggest someone run a whole third interface layer just to use the same software you and I use right out of the box. I think this aesthetic violation is misplaced in this case - the factors at play suggest to me that this work would benefit heavily from specialization. Indeed, that seems to be what has happened in practice; making the web accessible in 2025 is much easier than it was in 2000, because third parties have stepped up and improved the situation dramatically enough that hooking into accessibility layers "merely" requires things like writing semantically correct HTML.
Now imagine if a Dark Reader existed, that could reliably insert all the finer details into the page which are obvious from a screen grab of the page, but non-obvious to the web designer - that would clearly be a much better approach for the majority of businesses.
ChrisMarshallNY 7 hours ago [-]
In my experience, developing the habit of writing accessible software, substantially reduces the friction (and cost) involved in adding it.
Definitely, the most expensive way to add accessibility, is to retrofit it.
hiAndrewQuinn 7 hours ago [-]
My hypothetical assumes that the team was writing 95% accessible software already. The last 2 weeks are for the final push.
Of course, if this is a truly all-or-nothing thing where you need to do it 100% perfectly to incur no extra cost, then that strengthens my argument for the compatibility layer, it doesn't diminish it. Very few non-specialists can get something 100% right on the first shot.
ChrisMarshallNY 6 hours ago [-]
Fair enough.
> Very few non-specialists can get something 100% right on the first shot.
But that certainly doesn’t stop managers from assuming 100%, first shot.
In my experience, a realistic plan can save huge amounts of cost; in far more areas than just accessibility.
Also in my experience: realistic plans are unicorns.
hombre_fatal 5 hours ago [-]
Yeah, it's like RSS: a solution that requires every single operator to implement something you need is quite a bad solution. For you who needs it and for every operator who has to implement it.
Instead, it's superior if you didn't need RSS at all to generate and consume feeds of website because your software did it for you.
Same for screen readers and accessibility. The superior solution is for software to derive the UX just like a sighted person can.
It will be nice when we get the tech for this so that accessibility convos don't just get stuck in these weird shaming rituals where you're supposed to feel guilty that you never tried your website with macOS VoiceOver when you're not even sure if your business will exist in a year.
askew 7 hours ago [-]
Is that extra development cheaper than the risk of a lawsuit or loss of reputation? Not forgetting the ~20% of potential customers you might be missing out on…
> not least that you aren't imposing a heavy tax on everyone else for a really small customer base.
Ah. Seeing your disabled customers as a burden. One day you might encounter barriers when it comes to computing.
hiAndrewQuinn 6 hours ago [-]
>Is that extra development cheaper than the risk of a lawsuit
It probably isn't cheaper, no. The base risk of a lawsuit in this domain seems very low for all but the largest of websites; the largest of websites generally have large enough user pools that investing in out of the box accessibility makes sense anyway. In fact I would wager Facebook makes more advertising money off of its median blind user than its median fully-sighted user, simply because that's a very easy demographic to target ads to.
I'm willing to change my mind on this if you can provide evidence if even, say, 1% of all inaccessible websites on the Internet have been sued on these grounds.
>Seeing your disabled customers as a burden
Disabled potential customers, for one. Disabled people aren't dumb, and they don't pay for things they can't actually use. I'm surprised you assume they would.
But, and and this may come as a surprise, I genuinely think the compatibility layer approach is the much better option here. There are plenty of reasons to think so, which I outlined in the original post. Your slander is not welcome or acceptable just because you disagree with me.
thunderfork 5 hours ago [-]
[dead]
cyberlimerence 12 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 10 hours ago [-]
> the new hotness are elevated crosswalks.
Those are great for making cars not blast through intersections too.
TeMPOraL 7 hours ago [-]
> We all benefit from digital (and physical) accessibility.
If only. The problem is that businesses on the web directly benefit from things being not accessible.
Attention economy makes money on friction. Your typical website is a maze the user is supposed to get a little lost in, to maximize time they're exposed to product offering, and/or third-party ads, and/or tracking. Cutting curbs just tells them where to go and lets them do it with less effort, so they cut through the maze faster, and business loses money.
panstromek 7 hours ago [-]
That's pretty selective view of the problem. And I'm also pretty sure it's at least partially a fallacy that even some these businesses are fooled by. Removing friction often increases your revenue, that's been shown in many cases, often by the companies you seem to be criticizing here.
TeMPOraL 6 hours ago [-]
> Removing friction often increases your revenue
It does, because obviously friction that doesn't make you money is a waste and loses you money. Doesn't change the fact that friction is how attention is monetized.
As an example, think of a rotary grinder. The friction that's valuable to you is the one between the grinding end and the work piece you apply it to. The friction inside bearings of the grinder, or within the wobbling mount of the work piece, or electrical resistance, are all friction that costs you energy -> money, and you benefit from removing it.
(The actual example that matches attention economy I have in mind is like a funnel that drops into a vibrating barrel lined with sandpaper, but I can't seem to find how that tool is named.)
panstromek 2 hours ago [-]
Sure, but you said that "businesses on the web directly benefit from things being not accessible." which is obviously not true in gereal. Every business would be stupid to not make their checkout form accesible, for example.
twoquestions 4 hours ago [-]
I've fallen in love with using Vimium when browsing, and the real thing elements are much easier to use than JS substitutes.
These are ok points. Though I don't think it's necessary to use tables to be accessible, for example. It's perfectly fine to use whatever you want, so long as you include the proper semantics/ARIA tags to help the screen reader know what's going on.
I think understated by the author is how many a11y considerations are visual, real-time and/or physical in nature. Accessible UIs aren't just for communicating the structure of a page to a screen reader. Sometimes your user is deaf, or just colorblind, or lacks fine motor control/experiences physical fatigue using computers. Sometimes they're not blind, but they need larger letters and contrasting colors to quickly and accurately use your application. Sometimes you're displaying something new, and you need to let all of these users know about it clearly.
Also probably understated is that many component libraries (Prime, Material... all of them) have a11y bugs that nobody finds because most don't care. If you want your name on some open-source commits [0], this is a really easy way to get your feet wet.
Another selfish reason: at some point we'll all have diminished eyesight; make things accessible for future you.
matsemann 9 hours 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.
ChrisMarshallNY 7 hours ago [-]
I write apps (iOS native) and backend stuff, for a demographic that has a statistically high number of disabled folks, so I put a lot of accessibility into my coding.
The one thing that I’ve found to be important, in native iOS coding, is to start early. Retrofitting accessibility sucks.
CoastalCoder 5 hours ago [-]
Out of curiosity, what demographic is that?
ChrisMarshallNY 4 hours ago [-]
Recovering drug addicts.
nonethewiser 2 hours ago [-]
>I personally find these arguments persuasive. But experience has also taught me that “eat your vegetables” is one of the least effective arguments in the world. Scolding people might get them to agree with you in public, or even in principle, but it’s unlikely to change their behavior once no one’s watching.
I interpret this to mean the author may not actually find this argument persuasive.
smilekzs 10 hours ago [-]
> 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?
The TL;DW is: yes, class selectors are slightly more performant than attribute selectors, mostly because only the attribute _names_ are indexed, not the values. But 99% of the time, it's not a big enough deal to justify the premature optimization. I'd recommend measuring your selector performance first: https://developer.chrome.com/docs/devtools/performance/selec...
robin_reala 9 hours ago [-]
Given the morass of JS slathered on every site these days, selector performance is the least of your worries.
chrismorgan 10 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.)
paradox460 8 hours ago [-]
I've felt this way for years, even wrote a blog post [1] about it nearly 2 years ago
It doesn't seem to be getting better, sadly. You get posts like the op, where the author realizes there's something wrong with how they're doing things, but then misses that tailwind is a big part of it. Emperor has no clothes, so everyone else strips naked as well
Thanks for the link, and for making an edit to the article after publishing - I just learned about the ".cls" button, which is now also present in Firefox. That'll make dealing with Tailwind pages a bit less painful.
Vinnl 7 hours ago [-]
Well, in the context of this article, it still consists of meaningful semantic elements, and attributes like `aria-selected`. And if I really need to, I can still just add a regular class.
chrismorgan 6 hours ago [-]
Congratulations! Your regular class is now drowned by all the noise, and looks like a mistake. It will probably attract a red squiggly at some point and be culled by an aggressive linter.
rustc 5 hours ago [-]
Why would a linter randomly remove a class name from your markup?
chrismorgan 4 hours ago [-]
I think it’s plausible, though probably not quite intentional at any point.
The first step is a rule that all class must be valid Tailwind names. Honestly this would be useful, because people make mistakes, Tailwind’s names are often obtuse, and without this it’s hard to realise when you’ve got mistakes, because there’s so much noise. If you think a CSS checker should complain about unknown CSS property names or values, it stands to reason in this brave Tailwind world that the class attribute should receive the same treatment.
Then the second step is making that rule autofixable, by removing invalid values. This is the sort of thing that shouldn’t happen, but easily could.
Vinnl 5 hours ago [-]
Honestly I almost never do, because in practice it's really not necessary that often. But when I do, I just put it in front, then it's easy to find. It's never happened to me that it got marked as an error or culled by an aggressive linter, so I feel like those might be straw men?
molf 3 hours ago [-]
Not just in dev tools; that mess is also in your source code...
troupo 10 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.
DonHopkins 4 hours ago [-]
Layer upon layer of semantically senseless but colorful sparkly CSS diluted with toluene, build up over the years like Fordite!
Some day people will be cutting out slices of today's web pages archived on archive.com, polishing them up like gemstones, and wearing them as jewelry.
LLOOOOMM applies Minsky's "Society of Mind" approach to simulating characters who can focus and apply their style and expertise to all kinds of tasks, including designing and coding web pages, user interfaces, and games.
You can recruit an ensemble of user interface and design specialists to help design web pages while making sure they are clear and accessible, and recruit any other characters to express their own aesthetic design sensibilities and voice, actually using simulated characters as "style sheets" that you can combine and modulate with instructions.
Here is an example of Klaus Nomi writing in his own voice about LLOOOOMM and "Characters as Living Stylesheets", with the help of some friends and experts who champion accessibility, ease of use, and transparency:
>This page was generated by: Klaus Nomi + Jakob Nielsen + Ben Shneiderman + Bret Victor
>"In LLOOOOMM, every webpage is a performance, every function a song, every variable a note in the cosmic symphony of code." — Klaus Nomi, Digital Opera Singer
The trick (not a secret) is that LLM's ALREADY KNOW a HUGE AMOUNT about these topics and those people, and simulated characters provide and focus a lens (multiple virtual attention heads with memory and persistence) to embody, refine, augment, converse, evolve, solve problems, learn from experience, and remember all that knowledge and wisdom, and not only can enhance the character models (markup and yaml files) with specific details about the design guidelines they invented and published and practice and champion, but they can also introspect and talk with and edit themselves and each other!
The magic is you can #include well known real or fictional characters entire life's work just by mentioning their names (instead of wasting your token budget on building them from scratch by describing the ultimate but fictional UI designer).
Then you can copy and paste in their wikipedia page and some posts or articles or papers they've written, then curate, focus, and refine them. It takes way fewer words than starting from scratch! Instead you start with characters whose life's work of research and publications is already "baked into" the LLM's training data.
Alan Kay is great at helping with object oriented programming and language design, Marvin Minsky is deep into discussing AI and philosophy, Seymour Papert loves to help kids learn to program, Linus Torvalds is brilliant at helping with git, linux, and performing HARSH but insightful code reviews, and so on. Dang is the patron saint of moderation to invite when you want to provoke a passionate discussion between cantankerous characters with passionate diverse opinions. In case a flame war breaks out, Dang can summon Micky Mouse in his Fantasia conductor role to whip up an army of marching broomsticks tossing buckets of water on a fire! ;)
More stuff about LLOOOOMM, which I'll publish on github SSOOOONN:
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”.
In any case it is "Document 32019L0882" which does go into effect on June 28:
> Directive (EU) 2019/882 of the European Parliament and of the Council of 17 April 2019 on the accessibility requirements for products and services (Text with EEA relevance)
Thanks, not sure what I copied from my browser but that’s the correct one, yep.
amarcheschi 4 hours ago [-]
I studied wcag in a course in uni this semester, it is truly mind blowing how experts were gathered to make a list of "list of all things you need to know about accessible webpages" and yet so many websites don't care about it. I mean, it takes just some scrolling to understand that they're very useful tips. And having something accessible might make it for a better experience for regular people too
Partially unrelated, but at a venue I work at there's the console managing stage lights that has the button to save and the button to delete the saved presets next to each other. That's one of the worst things that I could imagine for an interface
panstromek 11 hours ago [-]
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.
aitchnyu 11 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"?
Selfish reason for not building accessible UIs: it's extra work that doesn't justify the cost compared to the market share.
We would all be better off spending that investment on improving the dozen or so screen readers instead of billions of web sites. We aren't far from an LLM powered screen reader making aria tags moot.
sirwitti 2 hours ago [-]
Just as we aren't far from actually usable and safe self driving cars since 10+ years.
This is not a valid argument.
bevr1337 2 hours ago [-]
It takes the same amount of work to use an <aside> or <button> as a <div>. I have never accepted the argument that accessibility is more work. It is the same amount of work but done correctly. Aria attributes are only necessary when extending HTML semantics.
zamadatix 1 hours ago [-]
In the best (and thankfully pretty common) cases the work to do the accessible answer can be the same, or even less, than the work to do it otherwise. That certainly doesn't extend to all cases though and that's where it can snag. E.g. making complex charts or visualizations accessible to those using screen readers often involves creating a second version of the information only suited for that modality. A ton of other things are a bit in-between, such as prefers-reduced-motion being somewhere between "pretty easy" to "complex" depending on how you implement it in your site but, either case, adding some amount of effort.
bevr1337 1 hours ago [-]
Complex cases are indeed complex! Data viz is an interesting example since visuals are often misleading and time sinks regardless of ability. It's less effort to provide an HTML table or CSV export than gluing D3 and React together (or whatever stack your team uses).
I try my hardest to push back on canvas viz so we're not reinventing every wheel. SVG is easy to extend and make interactive
krzat 6 hours ago [-]
For people familiar with snapshot testing: instead of snapshotting pixels, try snapshotting the semantic tree.
Basically, you generate a textual representation of your UI, and then compare it against pre-recorded reference.
Ubikam is a semantic camera that records two channels: a markup presentation channel, and a semantic "YAML Jazz" channel that describes the semantic content and characters' state of mind.
layer8 2 hours ago [-]
It's already sad that we have to frame good keyboard operability as accessibility.
blabla1224 10 hours ago [-]
The div soup is for apps and semantic html is for documents. Not knowing the difference creates this kind of frustration.
TeMPOraL 6 hours ago [-]
Nah, div soups are for when you really insist your app UI must look like you want, instead of being ergonomic or useful to end users.
vaylian 9 hours 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.
oneeyedpigeon 9 hours ago [-]
The problem is, a LOT of people are treating documents as if they are apps.
bapak 8 hours 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
blabla1224 3 hours ago [-]
Input controls are always used by the apps (99.9%) and the post and div soup is not about that.
rrgok 10 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 9 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.
rrgok 4 hours ago [-]
I mean, the article talks about UI, so the target audience for that post is frontend devs or closely related.
2OEH8eoCRo0 2 hours ago [-]
Reason 1: Add extra requirements that small shops need to deal with which only really matter at megacorp scale anyway.
Have fun competition!
moffkalast 7 hours ago [-]
> combobox
It's 2025, browsers are adding GPU access for JS, we can run native code with wasm, yet HTML still has no actual combobox support. WHATWG are not just clowns they are not even the whole circus, they are a worldwide consortium of circuses with Barnum at the helm.
Devasta 3 hours ago [-]
It's honestly embarrassing that we are twenty years since the browsers took control of HTML from the W3C and they still have nothing approaching even one tenth the capability of XForms.
The fact that legions of developers are working on browsers, and at the same time everyone scrambles to abstract away from the browser offerings towards JSX, Tailwind and TS is maddening.
goodpoint 6 hours ago [-]
why are people here so obsessed with justifying selfishness?
robertlagrant 4 hours ago [-]
I don't think anyone is obsessed with doing that.
majewsky 3 hours ago [-]
The clearest examples are the ones downvoted into oblivion, so you probably don't see them.
eviks 11 hours ago [-]
> Now I can easily zero in on a table cell, or a column header
Isn't inspecting the actual cell /header easier?
DonHopkins 5 hours ago [-]
It boggles my mind that there are actually "Anti-Accessibility" trolls out there, lurking under their rocks, angrily eager to criticize and shut down any discussions or efforts towards accessibility and inclusivity by attacking the messenger instead of addressing the message.
But then again, there are also many "Anti-Woke" trolls gleefully leaping to the defense of Nazis and racists and misogynists and bigots, so there you go, that's where we are.
It directly relates to the MAGA philosophy of seeing empathy as a weakness, championed by someone who got elected by mocking a reporter with disabilities:
One of their ilk, aaron695, is actually in this discussion with us right now, buzzing around like a housefly, in the next message under mine. Apparently he is regularly attracted to accessibility discussions, which feed his anger. And yet again, he's posting useless anti-accessibility drivel that got his message rightfully flagged and dead. Set showdead=true to see his useless anti-accessibility rant if you don't believe me or think I'm exaggerating (but TL;DR: his incoherent rant cotributes absolutely nothing interesting to the conversation, which is why he's so frustrated and impotent, so it's not worth the time to read):
You're never going to convince those people that accessibility is good by explaining that it's in their own self interest. They'd rather cut off their nose to spite their face. The only thing that would ever convince them to support accessibility is if it actively HURTS someone they don't approve of.
Here's what I wrote 13 days ago to one of them, who was too busy to read the wall of deeply researched and linked text that I wrote about Dasher, but he decided to take the time out of his busy life to complain to me about posting too much text about Dasher without him actually bothering to read it, and not even bothering to comment on the topic itself:
>I'm sorry to hear about your disabilities of poor reading comprehension and trouble parsing text, and I'm envious that you have so much free time and nothing better to do, that you can take time to complain about your impatience with and intolerance of my writing. But it would have been easier, more efficient, and less stressful for you to simply ignore things you're not interested in rather than unconstructively whining with off-topic posts that benefit nobody. Obviously you don't appreciate how lucky you are to be able to type such a useless post so easily. I'm not even asking you to be empathic, or give a shit about anyone but yourself: if you're lucky enough to live long enough, you'll need accessibility tools like Dasher too.
aaron695 7 hours ago [-]
[dead]
vivzkestrel 13 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 13 hours ago [-]
This is a very popular take, but it has absolutely nothing to do with the article.
SirSavary 13 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).
vivzkestrel 7 hours ago [-]
saw the word react in his article and therefore i mentioned it
DonHopkins 4 hours ago [-]
And the sky is blue, grass is green, roses are red, water is wet, and farts stink except for your own. Want to go outside, look at the sky, touch some grass, take a swim, fart some bubbles, and smell the roses?
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.
https://extensiblewebmanifesto.org/
Good intentions and some good ideas. But ultimately lead to a fractured, overly complicated and bloated web.
I say yes to lower level, more general capabilities. But why does that have to mean we get bad APIs (web components, indexeddb, service workers...) and lack fundamental and well established UI components (combobox, toggles, tabs, tooltips, data grids...) and incomplete implementations (lacking HTTP verbs for forms)?
(Also why we're at it, I'm going to sneak in a complaint about half baked and broken language features like `const` and `import`. Also we shouldn't have abandoned Do-Not-Track...)
Those controls work fine maybe for a static form on a website as parent wrote - but web applications are not websites...
My opinion is that we could use fewer "web applications" and more web pages that simply provide structured semantic data and then get out of the way and let the User Agent (and user himself) control the presentation of that data. Sure, some things have to be a web application. I'll grit my teeth and admit that. But many, many sites we visit could easily be raw HTML and maybe some CSS (which the User Agent is free to cherry-pick through or ignore). They would be fast, functional, accessible, (probably) more secure, (probably) more private, free of telemetry, and would better serve the user's interests over the web company's interests.
Instead we get JavaScript "instructions" from the web site, which require the User Agent to faithfully execute, often removing the user's direct access to the actual content and enforcing the web developer's opinion on how it should be presented.
If we had more use of standard controls and light markup, and less JavaSludge, maybe browsers would devote more time towards fixing and improving their standard controls.
Just another random person's opinion, but this has been a terrible direction for the web.
I find a lot of the arguments for building inaccessible UIs seem to conflate historical web issues with modern times. Virtually everything that sucked in the core web toolkit circa 2010 has essentially been solved in 2025, even on ultra-restrictive platforms like iOS Safari.
Not the prettiest but I have seen much worse custom ones that were super buggy.
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.
Assistive software is just a different user agent. A non-standard browser interpreting the page in ways different than the vendor intended. The very same feature that enables a screen reader to help a blind person navigate, enables everyone else to identify and snip off ads and upsells, escape the thick sewage that's called "web design", and get straight to the actual thing one came for in the first place. Accessibility is the only thing that prevents the web from becoming Flash again, entirely unparseable through automated means[0].
Again, were it not for cultural and legal insistence to cater for the disabled, we'd all already be completely without agency on the web, dumb riders in a theme park paying for something at every turn. Cutting curbs and such? Why, so the users complete their "journey" faster and leave less money behind?
--
[0] - LLMs changed the equation here recently, mostly in our favor, for now. In the immediate term, they can make any website machine-interpretable no matter what the vendor does. But that's just the beginning, we don't yet know how vendors will abuse GenAI to thwart the users.
My ideal version of YouTube is a bare HTML page with a single <video> element that the User Agent decides how to interpret and render. And maybe some <li> links to navigate through the site to find other features. Maybe my User Agent is a browser, but maybe it's a video player, or some kind of assistive video display for the disabled. Or a powerpoint slide. Or a command line downloader. As a user, I should have control over how the web content is ultimately rendered, and the only job for the web site is to send me structured content that my renderer can pull apart, understand, and render in the way I see fit.
Similarly, my ideal version of Amazon is a bare HTML page with a search box and a structured list of products and their attributes, that my User Agent can ingest, understand and render in whatever way it sees fit.
Web sites have totally abandoned this path of giving the user control, and now when we GET from a web site, instead of structured, semantic data, we get a big opaque blob of JavaSludge that our browser is expected to faithfully execute as-written, so that the web company gets to make all the major presentation decisions. The user is just the passenger along for the ride.
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.
Misunderstanding this point leads to endless surprise in this topic. No, companies don't just "don't care" for some unfathomable reason. They don't want it in the first place; they begrudgingly make concessions to accessibility due to cultural and regulatory pressure.
The same things that let the disabled people participate, also help regular users escape the very traps and tricks businesses on-line use to make money. Now, supporting the former group may be a rounding error on the balance sheet, but enabling the latter to defeat monetization efforts, not so much.
I found myself irrationally enraged and had to walk away from the conversation. I thought about it when I calmed down and I realized I was feeling, "Who the fuck are you to tell me how I can live in the world?"
Dissecting these thoughts further led me to the understanding that, without accessibility, you are telling a class of people that they don't deserve access to education, government services, or commercial products.
Telling disabled people that they don't deserve access to any benefits of a civilized society is a long-standing and persistent attitude. It's roughly analogous to denying poor people health care, food, and basic shelter because all they deserve is what scraps we are willing to bestow on them.
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.
I agree, but I think that's tantamount to wishing humans were more kind and empathetic.
If that we're the case, I suspect the world would be souch better as to be unrecognizable.
Look at what happens after a disaster or when a neighbor falls ill -- people band together and feed one another. They care for one another. They pick up the slack. Not because anyone pays them, but because it's what they intrinsically want to do.
But it only occurs during disruptions from the norm.
We've got a few decent speech synths, but information about how things should be read out isn't passed through to them. That's handled by a screen reader program… except screen readers can't represent half the semantics they should, so people regularly bypass them, which leads to (a) UI inconsistency; and (b) the systems being useless if you need something other than a screen reader. AI scraper bots are the straw that broke the camel's back, so virtually no (current) website is accessible via a basic web browser any longer. UI customisability was low in the Windows 95 days, but we've managed to go backwards from there.
We might as well go the whole way, and design something that's actually usable, then put together case-by-case compatibility layers. Here's how we translate Home Office Design System HTML, here's how we translate Stacks Design System HTML, here's how we translate MediaWiki HTML, here's how we translate Wordpress Gutenberg HTML, here's how we translate Moodle HTML… here's how we represent the OpenDocument content model for reading and writing, here's how we represent the SVG content model for reading and writing, here's how we represent a login flow…
You're right to point out issues with "ghetto systems" – but we don't have a single computer system that actually works, and everything that does exist has fundamental design flaws that make accessibility prohibitively difficult. (Wayland somehow managed to be a downgrade from X11, which is quite a feat.)
I think a basic ghetto system with a full development environment and easily-accessible documentation would rapidly become not a ghetto system.
Good news, everybody! Rewriting everything from scratch has recently become a lot, lot easier, and much more fun!
Leela AI (not to be confused with Turanga Leela) learns to speak in LLOOOOMM / Cursor:
https://youtu.be/Sn057QrCUm8?t=5367
https://leela.ai/how-leelas-ai-is-different/
PS: Does anyone know how to make the Mac "say" command use a new fangled "Personal Voice" that you can record of your own?
When most or all of us benefit from "accessibility", then it isn't really accessibility. It is fixing a broken UI, period. Designers need to be shamed for not even providing a good enough UI for the average person, let alone disabled people.
Consider a rosy hypothetical: A SaaS under truly great, enlightened leadership. The team lead knows that it would take only one two week sprint, for one focused developer, to go the last mile and make it truly accessible for all. The fully loaded cost of those developer-hours, in a very optimistic scenario, is $1000, and optically closer to $4-8000 for a US based team.
First, do those extra steps towards accessibility even break even? Second, if so, are they truly the revenue maximizing move for what that dev can do with that 2-week sprint? Sometimes, rarely, they are. In practice I suspect market research would show the opposite. This is before we add in all of the usual fog of war around how long things really take to build, whether the leadership is really as enlightened as they seem, etc.
Consider an alternative model where one company specializes in creating high quality accessibility-enhancing software. This software aims to work as a compatibility layer across most to all of the other programs a user is likely to use; perhaps they use frequent in-memory screenshots and detailed image analysis to help blind users understand what's going on. Or perhaps it's as simple as a FOSS dev focusing on making sure every terminal program they can run works well with their screen reader.
There are a plethora of benefits to this model, not least that you aren't imposing a heavy tax on everyone else for a really small customer base. This is also very specialized, customer-facing work. If there is anywhere in software you would want dedicated frontend or UI/UX expertise it would probably be the guy designing the screen reader compatibility layer.
I point to the popular extension Dark Reader as an example of this paradigm; it does a wonderful job on most websites, is easy to disable on websites where it doesn't, and doesn't cost the website runner anything to use.
Some might take issue with this for aesthetic reasons. It feels kludgy to suggest someone run a whole third interface layer just to use the same software you and I use right out of the box. I think this aesthetic violation is misplaced in this case - the factors at play suggest to me that this work would benefit heavily from specialization. Indeed, that seems to be what has happened in practice; making the web accessible in 2025 is much easier than it was in 2000, because third parties have stepped up and improved the situation dramatically enough that hooking into accessibility layers "merely" requires things like writing semantically correct HTML.
Now imagine if a Dark Reader existed, that could reliably insert all the finer details into the page which are obvious from a screen grab of the page, but non-obvious to the web designer - that would clearly be a much better approach for the majority of businesses.
Definitely, the most expensive way to add accessibility, is to retrofit it.
Of course, if this is a truly all-or-nothing thing where you need to do it 100% perfectly to incur no extra cost, then that strengthens my argument for the compatibility layer, it doesn't diminish it. Very few non-specialists can get something 100% right on the first shot.
> Very few non-specialists can get something 100% right on the first shot.
But that certainly doesn’t stop managers from assuming 100%, first shot.
In my experience, a realistic plan can save huge amounts of cost; in far more areas than just accessibility.
Also in my experience: realistic plans are unicorns.
Instead, it's superior if you didn't need RSS at all to generate and consume feeds of website because your software did it for you.
Same for screen readers and accessibility. The superior solution is for software to derive the UX just like a sighted person can.
It will be nice when we get the tech for this so that accessibility convos don't just get stuck in these weird shaming rituals where you're supposed to feel guilty that you never tried your website with macOS VoiceOver when you're not even sure if your business will exist in a year.
> not least that you aren't imposing a heavy tax on everyone else for a really small customer base.
Ah. Seeing your disabled customers as a burden. One day you might encounter barriers when it comes to computing.
It probably isn't cheaper, no. The base risk of a lawsuit in this domain seems very low for all but the largest of websites; the largest of websites generally have large enough user pools that investing in out of the box accessibility makes sense anyway. In fact I would wager Facebook makes more advertising money off of its median blind user than its median fully-sighted user, simply because that's a very easy demographic to target ads to.
I'm willing to change my mind on this if you can provide evidence if even, say, 1% of all inaccessible websites on the Internet have been sued on these grounds.
>Seeing your disabled customers as a burden
Disabled potential customers, for one. Disabled people aren't dumb, and they don't pay for things they can't actually use. I'm surprised you assume they would.
But, and and this may come as a surprise, I genuinely think the compatibility layer approach is the much better option here. There are plenty of reasons to think so, which I outlined in the original post. Your slander is not welcome or acceptable just because you disagree with me.
[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.
If only. The problem is that businesses on the web directly benefit from things being not accessible.
Attention economy makes money on friction. Your typical website is a maze the user is supposed to get a little lost in, to maximize time they're exposed to product offering, and/or third-party ads, and/or tracking. Cutting curbs just tells them where to go and lets them do it with less effort, so they cut through the maze faster, and business loses money.
It does, because obviously friction that doesn't make you money is a waste and loses you money. Doesn't change the fact that friction is how attention is monetized.
As an example, think of a rotary grinder. The friction that's valuable to you is the one between the grinding end and the work piece you apply it to. The friction inside bearings of the grinder, or within the wobbling mount of the work piece, or electrical resistance, are all friction that costs you energy -> money, and you benefit from removing it.
(The actual example that matches attention economy I have in mind is like a funnel that drops into a vibrating barrel lined with sandpaper, but I can't seem to find how that tool is named.)
https://chromewebstore.google.com/detail/vimium/dbepggeogbai...
I think understated by the author is how many a11y considerations are visual, real-time and/or physical in nature. Accessible UIs aren't just for communicating the structure of a page to a screen reader. Sometimes your user is deaf, or just colorblind, or lacks fine motor control/experiences physical fatigue using computers. Sometimes they're not blind, but they need larger letters and contrasting colors to quickly and accurately use your application. Sometimes you're displaying something new, and you need to let all of these users know about it clearly.
Also probably understated is that many component libraries (Prime, Material... all of them) have a11y bugs that nobody finds because most don't care. If you want your name on some open-source commits [0], this is a really easy way to get your feet wet.
Source: have done multiple WCAG audits
[0] seriously: https://github.com/primefaces/primeng/pull/15161/commits/ea4...
The things I did most often I had bookmarklets for.
The one thing that I’ve found to be important, in native iOS coding, is to start early. Retrofitting accessibility sucks.
I interpret this to mean the author may not actually find this argument persuasive.
I vaguely remember (from 10+ years ago) that class selectors are much more performant than property selectors?
The TL;DW is: yes, class selectors are slightly more performant than attribute selectors, mostly because only the attribute _names_ are indexed, not the values. But 99% of the time, it's not a big enough deal to justify the premature optimization. I'd recommend measuring your selector performance first: https://developer.chrome.com/docs/devtools/performance/selec...
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.)
It doesn't seem to be getting better, sadly. You get posts like the op, where the author realizes there's something wrong with how they're doing things, but then misses that tailwind is a big part of it. Emperor has no clothes, so everyone else strips naked as well
1: https://pdx.su/blog/2023-07-26-tailwind-and-the-death-of-cra...
The first step is a rule that all class must be valid Tailwind names. Honestly this would be useful, because people make mistakes, Tailwind’s names are often obtuse, and without this it’s hard to realise when you’ve got mistakes, because there’s so much noise. If you think a CSS checker should complain about unknown CSS property names or values, it stands to reason in this brave Tailwind world that the class attribute should receive the same treatment.
Then the second step is making that rule autofixable, by removing invalid values. This is the sort of thing that shouldn’t happen, but easily could.
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.
https://en.wikipedia.org/wiki/Fordite
Some day people will be cutting out slices of today's web pages archived on archive.com, polishing them up like gemstones, and wearing them as jewelry.
LLOOOOMM applies Minsky's "Society of Mind" approach to simulating characters who can focus and apply their style and expertise to all kinds of tasks, including designing and coding web pages, user interfaces, and games.
You can recruit an ensemble of user interface and design specialists to help design web pages while making sure they are clear and accessible, and recruit any other characters to express their own aesthetic design sensibilities and voice, actually using simulated characters as "style sheets" that you can combine and modulate with instructions.
Here is an example of Klaus Nomi writing in his own voice about LLOOOOMM and "Characters as Living Stylesheets", with the help of some friends and experts who champion accessibility, ease of use, and transparency:
https://donhopkins.com/home/lloooomm/klaus-nomi-lloooomm-man...
>This page was generated by: Klaus Nomi + Jakob Nielsen + Ben Shneiderman + Bret Victor
>"In LLOOOOMM, every webpage is a performance, every function a song, every variable a note in the cosmic symphony of code." — Klaus Nomi, Digital Opera Singer
The trick (not a secret) is that LLM's ALREADY KNOW a HUGE AMOUNT about these topics and those people, and simulated characters provide and focus a lens (multiple virtual attention heads with memory and persistence) to embody, refine, augment, converse, evolve, solve problems, learn from experience, and remember all that knowledge and wisdom, and not only can enhance the character models (markup and yaml files) with specific details about the design guidelines they invented and published and practice and champion, but they can also introspect and talk with and edit themselves and each other!
The magic is you can #include well known real or fictional characters entire life's work just by mentioning their names (instead of wasting your token budget on building them from scratch by describing the ultimate but fictional UI designer).
Then you can copy and paste in their wikipedia page and some posts or articles or papers they've written, then curate, focus, and refine them. It takes way fewer words than starting from scratch! Instead you start with characters whose life's work of research and publications is already "baked into" the LLM's training data.
Alan Kay is great at helping with object oriented programming and language design, Marvin Minsky is deep into discussing AI and philosophy, Seymour Papert loves to help kids learn to program, Linus Torvalds is brilliant at helping with git, linux, and performing HARSH but insightful code reviews, and so on. Dang is the patron saint of moderation to invite when you want to provoke a passionate discussion between cantankerous characters with passionate diverse opinions. In case a flame war breaks out, Dang can summon Micky Mouse in his Fantasia conductor role to whip up an army of marching broomsticks tossing buckets of water on a fire! ;)
More stuff about LLOOOOMM, which I'll publish on github SSOOOONN:
https://www.youtube.com/watch?v=Sn057QrCUm8&list=PLX66BqHq0q...
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/eli/dir/2019/882/oj/eng (Edit: fixed URL from Y-bar)
In any case it is "Document 32019L0882" which does go into effect on June 28:
> Directive (EU) 2019/882 of the European Parliament and of the Council of 17 April 2019 on the accessibility requirements for products and services (Text with EEA relevance)
https://eur-lex.europa.eu/eli/dir/2019/882/oj/eng (I think this one is permanent)
Partially unrelated, but at a venue I work at there's the console managing stage lights that has the button to save and the button to delete the saved presets next to each other. That's one of the worst things that I could imagine for an interface
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.
https://shortcat.app/ https://tridactyl.xyz/about/
We would all be better off spending that investment on improving the dozen or so screen readers instead of billions of web sites. We aren't far from an LLM powered screen reader making aria tags moot.
This is not a valid argument.
I try my hardest to push back on canvas viz so we're not reinventing every wheel. SVG is easy to extend and make interactive
Basically, you generate a textual representation of your UI, and then compare it against pre-recorded reference.
https://youtu.be/Sn057QrCUm8?t=470
Ubikam is a semantic camera that records two channels: a markup presentation channel, and a semantic "YAML Jazz" channel that describes the semantic content and characters' state of mind.
You should still use appropriate tags like a, button, label, input and not div, div, div, div. Even apps have links
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.
Have fun competition!
It's 2025, browsers are adding GPU access for JS, we can run native code with wasm, yet HTML still has no actual combobox support. WHATWG are not just clowns they are not even the whole circus, they are a worldwide consortium of circuses with Barnum at the helm.
The fact that legions of developers are working on browsers, and at the same time everyone scrambles to abstract away from the browser offerings towards JSX, Tailwind and TS is maddening.
Isn't inspecting the actual cell /header easier?
But then again, there are also many "Anti-Woke" trolls gleefully leaping to the defense of Nazis and racists and misogynists and bigots, so there you go, that's where we are.
It directly relates to the MAGA philosophy of seeing empathy as a weakness, championed by someone who got elected by mocking a reporter with disabilities:
https://www.youtube.com/watch?v=PX9reO3QnUA
One of their ilk, aaron695, is actually in this discussion with us right now, buzzing around like a housefly, in the next message under mine. Apparently he is regularly attracted to accessibility discussions, which feed his anger. And yet again, he's posting useless anti-accessibility drivel that got his message rightfully flagged and dead. Set showdead=true to see his useless anti-accessibility rant if you don't believe me or think I'm exaggerating (but TL;DR: his incoherent rant cotributes absolutely nothing interesting to the conversation, which is why he's so frustrated and impotent, so it's not worth the time to read):
https://news.ycombinator.com/item?id=44297083
You're never going to convince those people that accessibility is good by explaining that it's in their own self interest. They'd rather cut off their nose to spite their face. The only thing that would ever convince them to support accessibility is if it actively HURTS someone they don't approve of.
Here's what I wrote 13 days ago to one of them, who was too busy to read the wall of deeply researched and linked text that I wrote about Dasher, but he decided to take the time out of his busy life to complain to me about posting too much text about Dasher without him actually bothering to read it, and not even bothering to comment on the topic itself:
https://news.ycombinator.com/item?id=44173863
>I'm sorry to hear about your disabilities of poor reading comprehension and trouble parsing text, and I'm envious that you have so much free time and nothing better to do, that you can take time to complain about your impatience with and intolerance of my writing. But it would have been easier, more efficient, and less stressful for you to simply ignore things you're not interested in rather than unconstructively whining with off-topic posts that benefit nobody. Obviously you don't appreciate how lucky you are to be able to type such a useless post so easily. I'm not even asking you to be empathic, or give a shit about anyone but yourself: if you're lucky enough to live long enough, you'll need accessibility tools like Dasher too.