Skip to content(if available)orjump to list(if available)

Selfish reasons for building accessible UIs

skgough

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

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.

flomo

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

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.

naavis

What kind of flaws did you have in mind?

Toritori12

I dont remember last time (if ever?) I saw a native date input in the wild.

airtonix

[dead]

ChrisMarshallNY

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.

energywut

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

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.

burningChrome

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

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

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.

ethin

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

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.

null

[deleted]

holowoodman

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.

lynx97

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

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…

hiAndrewQuinn

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.

askew

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.

ChrisMarshallNY

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

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.

cyberlimerence

A web version of curb cut effect[1], if you will. We all benefit from digital (and physical) accessibility.

[1] https://en.wikipedia.org/wiki/Curb_cut_effect

TeMPOraL

> 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

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.

panstromek

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

> the new hotness are elevated crosswalks.

Those are great for making cars not blast through intersections too.

smilekzs

> 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

Given the morass of JS slathered on every site these days, selector performance is the least of your worries.

chrismorgan

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

Vinnl

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.

paradox460

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

1: https://pdx.su/blog/2023-07-26-tailwind-and-the-death-of-cra...

TeMPOraL

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.

troupo

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

robin_reala

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

[1] https://eur-lex.europa.eu/eli/dir/2019/882/oj/eng (Edit: fixed URL from Y-bar)

Y-bar

Your URL seems to have expired.

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)

robin_reala

Thanks, not sure what I copied from my browser but that’s the correct one, yep.

panstromek

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

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"?

https://shortcat.app/ https://tridactyl.xyz/about/

matsemann

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.

blabla1224

The div soup is for apps and semantic html is for documents. Not knowing the difference creates this kind of frustration.

vaylian

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

The problem is, a LOT of people are treating documents as if they are apps.

bapak

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

moffkalast

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