[HN Gopher] Selfish reasons for building accessible UIs
___________________________________________________________________
Selfish reasons for building accessible UIs
Author : feross
Score : 198 points
Date : 2025-06-17 01:16 UTC (21 hours ago)
(HTM) web link (nolanlawson.com)
(TXT) w3m dump (nolanlawson.com)
| vivzkestrel wrote:
| 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
| SirSavary wrote:
| What does this have to with TFA? This is about accessibility,
| it has nothing to do with React (or any one web framework).
| vivzkestrel wrote:
| saw the word react in his article and therefore i mentioned
| it
| crab_galaxy wrote:
| This is a very popular take, but it has absolutely nothing to
| do with the article.
| xigoi wrote:
| If this was a popular take, React wouldn't be the most used
| framework.
| DonHopkins wrote:
| 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?
| The_President wrote:
| I like to think that it's all in the name. It's like asking a
| cardiologist or a pilot if they like the word Flutter.
| energywut wrote:
| 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.
| burningChrome wrote:
| >> 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| typewithrhythm wrote:
| You seem to have the opposite perspective on the
| relationship between someone who makes a product and
| customers...
|
| I am never looking at one specific person or group when
| planning what to invest time in, I'm looking for the best
| return.
|
| Its not a fair start point to claim I'm thinking on the
| level of who deserves access. Usually I'm following my
| own plans to try to break even.
| TheAceOfHearts wrote:
| 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.
| ethin wrote:
| 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.
| lynx97 wrote:
| 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 wrote:
| 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 wrote:
| "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 wrote:
| 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 wrote:
| 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:
|
| 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?
| yunwal wrote:
| As a completely ignorant infra engineer, is AI not also a
| potential solution that avoids rewriting entirely? Like, it
| feels like translating between visuals and audio signals
| would be one of the few things it's really great at.
|
| Perhaps a bit wasteful, but feels more likely than getting
| the entire software industry (including companies with
| inverse financial incentives) to get on board.
| holowoodman wrote:
| 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 wrote:
| 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.
| TeMPOraL wrote:
| 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 wrote:
| 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.
| TeMPOraL wrote:
| Yup, precisely this.
|
| To expand on:
|
| > _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._
|
| My ideal version of Amazon is a MS Access file or
| equivalent, that my User Agent can treat as an SQL database
| I can query however the heck I like.
|
| In fact, 90% of the websites and webapps fall into the
| following three categories:
|
| - Is a poster or ad magazine in disguise;
|
| - Would be much better if supplied as an Excel sheet
|
| - Would be much better if supplied as a database file or
| connection
|
| Alas.
|
| I'd go as far as saying, the job of great many web startups
| is to slap an SPA on top of a database to restrict access
| and charge for usage, like someone finding a shortcut
| through dense forest, fencing it off and building a toll
| gate on the path.
|
| And FWIW, it's not like people need things dumbed down into
| funnels and journeys. Sure, you probably can't expect much
| from a product aimed _literally at everyone above age 2_ ,
| but there's a host of products used by a narrower segment
| of population - white-collar workers, or even regular
| people with working mental faculties. These people can
| handle spreadsheets and even databases absolutely fine. In
| fact, there was a brief period of time, when this was
| taught in schools and as well as universities, particularly
| to people pursuing degrees in humanities / liberal arts.
| Databases in particular used to be part of journalist and
| librarian studies. People could easily learn all this
| stuff, if it were useful - but the _trends on the web made
| sure it wasn 't_.
|
| After all, you can't make FU money out of your startup
| backed by millions in VC dollars, that's just running basic
| SELECTs for users and charging for it, if users are allowed
| to run SELECTs themselves.
| hiAndrewQuinn wrote:
| 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 wrote:
| 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 wrote:
| >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.
| ChrisMarshallNY wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| CoastalCoder wrote:
| > 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 wrote:
| 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 wrote:
| 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.
| cyberlimerence wrote:
| 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
| panstromek wrote:
| 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 wrote:
| > the new hotness are elevated crosswalks.
|
| Those are great for making cars not blast through
| intersections too.
| TeMPOraL wrote:
| > _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 wrote:
| 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 wrote:
| > _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 wrote:
| 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.
| panstromek wrote:
| 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.
| skgough wrote:
| 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 wrote:
| I wish I could agree with you, but in my experience the built-
| in controls have many flaws and have remained stagnant for
| years or decades.
| naavis wrote:
| What kind of flaws did you have in mind?
| Zarel wrote:
| <input type="number"> is famously really flawed and not
| worth using even if what you want is semantically a number
| and not just numeric:
|
| https://stackoverflow.blog/2022/12/26/why-the-number-
| input-i...
|
| Tables have a whole bunch of flaws, like not letting you
| turn an entire row or cell into a link. (Some things are
| semantically tabular data!)
|
| <button disabled> doesn't trigger various DOM events,
| forcing you to use <button aria-disabled="true"> if you
| need them.
|
| These are the ones that come to mind immediately. I
| wouldn't be surprised if there are others.
| flomo wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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
| shakna wrote:
| Firefox got partial support in 2011. All that's missing,
| today, is support for date and time fields.
|
| For most usecases, it'll work. Not so much for meeting
| scheduling, or calendar management, but everything else.
| ozim wrote:
| 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 wrote:
| 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.
| bigbuppo wrote:
| The whole reason we need web "applications" when a simple
| web site will do all boils down to the demands of
| marketing and advertising. If you were to go to a major
| news organization's web site, the bulk of the javascript
| isn't for frontend UI frameworks, but advertising. Go to
| a video streaming platform, and they do Weird Things not
| to prevent scraping, but to inject marketing analytics
| _for advertisers_ even when you 're on an ad-free plan.
|
| Marketing and advertising makes the world a worse place.
| When you look at the real numbers, it rarely achieves
| whatever business goals it's supposed to achieve, though
| for some reason they keep throwing money at the crap
| because maybe this time it will be different.
| dgb23 wrote:
| Btw that's largely our (web devs) fault.
|
| 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...)
| sfink wrote:
| DNT wasn't abandoned, it was killed.
| WorldMaker wrote:
| How are `const` and `import` half-baked or broken? They
| work great, and do what they are supposed to do. Browser
| support is great today for both.
| dgb23 wrote:
| "Const" is half baked as it implies that you declare an
| immutable value, but it only prevents redeclaration and
| direct reassignment.
|
| "Import" breaks the browser REPL and the dynamic nature
| of JS. You can't redeclare, look or move into a module.
| Now JS is already broken in that you can't redeclare
| variables declared with let/const. But not being able to
| move into modules an extra crime.
| Toritori12 wrote:
| I dont remember last time (if ever?) I saw a native date input
| in the wild.
| pelagicAustral wrote:
| textbox is the warriors way of date input. Anything else is
| cruft. /s
| cardanome wrote:
| 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.
| bob1029 wrote:
| 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.
| dgb23 wrote:
| 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.
| PaulHoule wrote:
| Quite a few 3rd party controls have had attention paid to
| accessibility and have all the right aria- and other
| accessibility markup.
| aitchnyu wrote:
| 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/
| eviks wrote:
| > Now I can easily zero in on a table cell, or a column header
|
| Isn't inspecting the actual cell /header easier?
| chrismorgan wrote:
| > _When I'm trying to debug a web app, it's hard to orient myself
| in the DevTools if the entire UI is "div soup"_
|
| That's _tame_. Try adding some Tailwind CSS.
|
| After monitoring Tailwind CSS since its early days, and believing
| I had some pretty serious philosophical disagreements with it, I
| recently took an opportunity to try it out in earnest, and it is
| so _mindbogglingly_ obnoxious in dev tools that I think surely I
| must be missing something. How do people _cope_ with this stuff!?
|
| If you're not sure what I'm on about, go through some of the
| sites linked near the bottom of https://tailwindcss.com/. In the
| Inspector/Elements panel, the DOM tree is a bloated mess with a
| class attribute which amounts to inline styles or worse, commonly
| hundreds of characters long, discouraging you from using
| semantically-meaningful classes, and duplicating stuff enormously
| rather than using sane selectors; the mostly-better ones are
| those that have data-sentry-{element,component,source-file}
| attributes. The styles subpanel becomes utterly unnavigable.
|
| (I'm not saying everything in Tailwind is bad; I think I am
| likely to use a limited utility styles approach more than I did
| in the past, and there are a couple of other things that are
| provoking thought in me, and I think it would be more suitable in
| apps than in marketing-style websites. But the total embodiment
| of it is _not_ for me.)
| troupo wrote:
| > 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.
| paradox460 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Why would a linter randomly remove a class name from your
| markup?
| chrismorgan wrote:
| 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 wrote:
| 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?
| DonHopkins wrote:
| Layer upon layer of semantically senseless but colorful sparkly
| CSS diluted with toluene, build up over the years like Fordite!
|
| 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...
| molf wrote:
| Not just in dev tools; that mess is also in your source code...
| rrgok wrote:
| 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 wrote:
| 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 wrote:
| I mean, the article talks about UI, so the target audience
| for that post is frontend devs or closely related.
| blabla1224 wrote:
| The div soup is for apps and semantic html is for documents. Not
| knowing the difference creates this kind of frustration.
| oneeyedpigeon wrote:
| The problem is, a LOT of people are treating documents as if
| they are apps.
| vaylian wrote:
| It might be that there is no built-in functionality for some
| things in pure HTML. But most of the time, standard HTML tags
| provide all the functionality you need, even for web
| applications. And this benefits people with disabilities.
| bapak wrote:
| 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 wrote:
| Input controls are always used by the apps (99.9%) and the
| post and div soup is not about that.
| xigoi wrote:
| Buttons are often replaced by divs for no apparent reason.
| Look at Facebook for example.
| TeMPOraL wrote:
| 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.
| smilekzs wrote:
| > 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 wrote:
| Given the morass of JS slathered on every site these days,
| selector performance is the least of your worries.
| nolanl wrote:
| Author here. I actually did some research on CSS selector
| performance: https://nolanlawson.com/2023/01/17/my-talk-on-css-
| runtime-pe...
|
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Thanks, not sure what I copied from my browser but that's the
| correct one, yep.
| amarcheschi wrote:
| 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
| matsemann wrote:
| 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.
| moffkalast wrote:
| > 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 wrote:
| 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.
| ChrisMarshallNY wrote:
| 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 wrote:
| Out of curiosity, what demographic is that?
| ChrisMarshallNY wrote:
| Recovering drug addicts.
| krzat wrote:
| 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.
| DonHopkins wrote:
| That's like the UBIKAM in LLOOOOMM:
|
| 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.
| goodpoint wrote:
| why are people here so obsessed with justifying selfishness?
| robertlagrant wrote:
| I don't think anyone is obsessed with doing that.
| majewsky wrote:
| The clearest examples are the ones downvoted into oblivion,
| so you probably don't see them.
| DonHopkins wrote:
| 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:
|
| 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.
| twoquestions wrote:
| I've fallen in love with using Vimium when browsing, and the real
| thing elements are _much_ easier to use than JS substitutes.
|
| https://chromewebstore.google.com/detail/vimium/dbepggeogbai...
| twodave wrote:
| 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.
|
| Source: have done multiple WCAG audits
|
| [0] seriously:
| https://github.com/primefaces/primeng/pull/15161/commits/ea4...
| 2OEH8eoCRo0 wrote:
| Reason 1: Add extra requirements that small shops need to deal
| with which only really matter at megacorp scale anyway.
|
| Have fun competition!
| layer8 wrote:
| It's already sad that we have to frame good keyboard operability
| as accessibility.
| snarfy wrote:
| 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.
| bevr1337 wrote:
| 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 wrote:
| 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 wrote:
| 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
| sirwitti wrote:
| Just as we aren't far from actually usable and safe self
| driving cars since 10+ years.
|
| This is not a valid argument.
| shakna wrote:
| Thanks for telling me I deserve to eat glue with my pizza, for
| being born.
|
| Who do you build for, so I can blacklist them?
| nonethewiser wrote:
| >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.
| johneth wrote:
| Another selfish reason: at some point we'll all have diminished
| eyesight; make things accessible for future you.
___________________________________________________________________
(page generated 2025-06-17 23:01 UTC)