Accessibility support is a matter of priorities for a given project.
If 99.99% of your target audience is not using screen readers, then you need to decide if worsening their experience to accommodate the other 0.01% aligns with your project plans and goals.
In some cases it will, in some it won't. It depends.
First, in the US accessibility support is the law. While it is far from well* enforced, your simple formulation of “priorities” obscures the fact that the team is prioritizing convenience vs law. Yes we all do this when deciding, say, how fast to drive. But we know when we are speeding.
Second: in physical space: ramps are required to be implemented in a way that supports wheelchair use. Yet they create alternative affordances: I have appreciated them when when I have broken a limb, for example, even though they weren’t “intended” for that. They are clearly mostly used by delivery people; not only does it make deliveries easier, but reduces incidents of injuries, strains etc.
The same applies to web sites: cleaner affordances allow people to use the page in ways not imagined by the designer.
* By imperfectly I don’t mean “not hyper vigilantly”, I mean that it is often observed in the breach; sometimes it can have negative effects (consider the Berkeley videos case), etc. But that is much better than no attempt at all.
> First, in the US accessibility support is the law
Only for governments or businesses that are open to the public. I've rarely worked on those type of websites. But plenty of B2B stuff. There's a ton of it.
Not your main point, but in the Berkeley videos case I blame, well, Berkeley. They could have taken the videos offline temporarily, worked on transcribing them, and brought them back gradually (they have the resources or, if they’re too cheap, could have resorted to crowdsourcing). Taking that wealth of knowledge offline so abruptly, and with no plan to ever bring it back, is really a disgrace. The videos live on thanks to Archive Team, but they’re not as easy to discover.
> Accessibility support is a matter of priorities for a given project.
It is painful that some managers, architects or developers might think this way. Accessibility is not just for disabled people, such as the blind or those who have lost a limb. In the kitchen, for example, it is great to have push to open drawers (e.g. based on IKEA's EXCEPTIONELL [0]). If your hands are dirty, you can still open the kitchen drawer without getting anything else dirty. And this is just one example of accessibility.
Personally, I see screen readers as an additional tool (like Copilot or ChatGPT) to be used on a daily basis by keyboard users.
Screen readers can also help you, even if you are sighted. For example, with a ShortCat.app [1] I have a system-wide ace jump [2] with a command list. I don't have to use the mouse to move the cursor - I have a keyboard for that. But in applications that are not compatible with screen readers, you can only choose "close", "minimise", "maximise" buttons, and the first option - close - is the best for such an application (e.g. Sublime Text).
In other cases, SR/SA will read the text for you. If you are too tired to read, or your hands are occupied with a sandwich or utensils, you can use SR to read an article or paragraph for you.
I know 99.99% is just an example, but that's a pretty high estimate. I'm seeing estimates for vision impairment at 2% and color blindness at 4% [1] of the US population.
I'm also reminded that people use screen readers or other assistive tech for non-disability reasons. Like increasing font size when tired or when using a website in a foreign language. Plus, building assessible websites may be required by law, such as ADA requirements in the US.
This is, to be blunt, narrow-sighted; most accessibility support is rooted in best practices for every user. Screen readers are only one use case, other things that people don't even consciously think about and take for granted when they use a webpage or app are things like zooming in, focus/reader modes, light/dark modes, performance, print views, copy/pasting content, SEO / searchability, bookmarkability (e.g. headings & anchors in webpages, also used by screen reader users to quickly navigate a page), etc.
99.99% of accessibility things are covered if you just follow normal, established software development practices. Unfortunately, a lot of software developers overcomplicate things, for example by adding modal dialogs to websites. Modals are common and established design patterns in desktop apps, but not so in web and mobile apps. Applying one environment's UX patterns to another is asking for trouble.
>most accessibility support is rooted in best practices for every user.
This isn't quite true, when you get into things like using aria attributes. I definitely wouldn't put it at 99.99%. And I think a lot of vendors of accessibility software get to skate where others would have their feet held to the fire. They could be doing more to make their software easier to use and for developers to make it accessible.
I used to work as a contractor for the CDC, so I have experience in web development that is held to a higher accessibility standard (we had an actual real person who would verify our work and certify that it was accessible.)
And being able to navigate a site with a keyboard, or announce when sections change. That stuff isn't automatic. It might be baked into whatever framework you're using, but those frameworks have bugs too.
Boo! That attitude hurts people, and is against the law for good reasons.
And even if you have no empathy so you don't give a shit about anything unless it affects you directly (in which case UI design isn't for you), then consider that unless you die young or have supernaturally perfect health, you're going to need accessibility features yourself some day, so your lazy anti-accessibility attitude is going to come back and bite you in the ass.
And you're dead wrong that accessibility necessarily worsens the experience for people without disabilities. It's useful for everyone.
Please leave the user interface design to other better educated more compassionate people, and stick to the back-end yourself.
Speaking about empathy, might want to use some to get his point. He isn't talking about himself. He is talking about a typical software business making business decisions.
If adding support for accessibility delays their product delivery, or raises their costs, it's another tradeoff that might even kill their product. And then it wont be a case of the software not being accessible to those needing those features, but it not being accessible to anybody.
Sure, where the law mandates it, they can always do a half-ass job to be, in name, compliant. But full (or proper) accessibility will be judged in the end like any other feature decision.
You might consider those features essential, but you'd be surprised how many business features get cut to get something out, even more so for an MVP.
If you think those designing most websites and apps people use are made by "more compassionate people" who'd jump on such features out of ethical concerns, you'd be quite off.
Heck, this very website (HN) has a quite bad accessibility track record even considering the average website. Among other things: image elements do not have [alt] attributes, form elements do not have associated labels, links do not have a discernible name.
And this is from a major VC company with tons of resources, and a place where thousands upon thousands of devs frequent.
So, while everybody can get their "morally superior and empathetic" rocks off judging the parent, the reality is more like what's described above. It isn't bad if somebody points to the reality - or to the hypocrisy, if we're to see it ethically.
That's a shallow knee-jerk interpretation of what I was actually referring to.
Put my remarks in the context of a startup that has a limited runway and needs to choose between working on something that would appeal, entice and attract the majority of their target user base and trying to accommodate the needs of the fraction of the same. You can "boo" all you want, but their choice will be obvious, as it should be perfectly understandable, even for people from the second group.
> Please leave the user interface design to other better educated more compassionate people, and stick to the back-end yourself.
Ah, a gratuitous personal attack, the best way to strengthen any argument.
Pulling totally bogus statistics out of your ass like "99.99% of your target audience is not using screen readers" is not the best foundation for your dubious argument for using modal dialogs and against supporting accessibility. And your claim that accessibility "worsen[s] their [non-disabled users] experience" is flat out wrong, so it's hard to take you seriously.
And anyway, a lot more people would regularly and happily use screen readers if it weren't for all those badly and lazily designed web sites and user interfaces that use modal dialogs and don't bother supporting accessibility, which make them much less useful and accessible for everyone.
Speaking of context: Even if screen readers or people with disabilities did not exist, there are still many important legitimate reasons not to use modal dialogs, and still many perfectly reasonable alternatives, so your bogus statistical argument for using modal dialogs is still dubious and doesn't address any of those other issues.
>Here are the numbers regarding how many people have disabilities that make accessibility features necessary when surfing the internet.
>4.9% of U.S. adults have a vision disability with blindness or serious difficulty seeing even when wearing glasses, requiring screen readers.
>5.7% of U.S. adults are deaf or have serious difficulty hearing.
>10.8% of people with a disability have a cognition disability with serious difficulty concentrating, remembering, or making decisions.
>There are an estimated 300 million people in the world with color vision deficiency which requires color-adjusting tools on sites.
>About 16% of people who use screen readers have multiple disabilities.
>Roughly a quarter of Americans with disabilities (26%) say they have high-speed internet at home, a smartphone, a desktop or laptop computer, and a tablet compared with 44% of those who report not having a disability.
>18% of US adults report that they have a disability, according to this survey, which asked respondents if any “disability, handicap, or chronic disease keeps you from participating fully in work, school, housework, or other activities.”
>Americans with disabilities are three times as likely as those without a disability to say they never go online (15% vs. 5%.)
>By 2050 nearly 2.5 billion people are projected to have some degree of hearing loss and at least 700 million will require hearing rehabilitation.
>By 2060 the number of people 65 or older is expected to double to 98 million.
Another point is that screen readers aren't only useful for blind people. Here's a demo of a screen reader that I implemented for reading the long but amusing catalog object descriptions in The Sims ("Simplifier" demo starts at 3:15), that's useful for kids who aren't good at reading yet (but want to learn while playing a game), and anyone who is too impatient to read all the tiny text on the screen:
Demo of The Sims Transmogrifier, RugOMatic, ShowNTell, Simplifier and Slice City:
> Pulling totally bogus statistics out of your ass like "99.99% of your target audience
Please make some effort when refuting the arguments of others. See "target audience" in the part that you quoted? That's the keyword.
If one's making an augmented reality app that assists car mechanics in repairs, what would you say be the percentage of screen-reader wielding people there?
> And your claim that accessibility "worsen[s] their [non-disabled users] experience" is flat out wrong
For one, you are taking it out of context. For two, you keep repeating something as if it would make it true.
Here's a little exercise - consider what it would take to make https://finviz.com/bubbles.ashx page accessible. Then, consider what the target audience here is and ponder the choice of working on things that would benefit said audience (i.e. improving their experience) and refactoring the page to be compatible with screen readers. That's what I was referring to in the original comment. It's all in the context, it depends.
Adding keyboard control to an app makes it better for blind users and power users. Adding alt text to images makes it better for blind users and SEO. Adding ARIA tags makes a page better for blind users and for testing with things like testing-library.
I haven't found a single case where improving accessibility doesn't also result in a meaningful improvement for some set of users who don't need accessible features. There is absolutely no good reason not to make things accessible. Heck, I'd make an app accessible even if I had irrefutable proof that it had no users who need it to be accessible.
This was a common argument in the early 2000s, until, you know, someone looked at real world data and figured that something like 10-30% of a website’s audience usually benefits from accessibility features. Accessibility is not only about supporting complete blindness or other stereotypical disabilities.
Accessibility is hugely important and every single html project people work on should at the very absolute least strive to satisfy the chrome light houses accessibility suggestions. It is _really_ not difficult to attain a basic level of accessibility and with a small effort by UX and product people the entire application could be easily usable by anyone able to currently use a computer.
I worked in a consulting company, which estimated accessability requirements to increase web development costs by 10%. It's easy to imagine some big successfull company paying it up like it's peanuts, but it's another hurdle for companies living on the edge. I was in another company that had done a lot of work on accessability. But in the end, they ran out of money and released their software extremely buggy, which contributed to their product failure and bankruptcy.
Non-bugginess is also accessability, but I don't see a law saying that you can't release unfinished software. So how would accessability be anything more than all the others unimplemented issues stuck in the backlog?
There should be zero legal requirement to do so - I just meant to say there is a lot of low hanging accessibility fruit that doesn't require a large amount of time and money to implement that will give everyone using a computer a better experience.
> Accessibility support is a matter of priorities for a given project.
Not any more. In the US this hasn't been the case for years since 2019 [1], and in Europe a similar requirement will take power in 2025 at the latest [2].
There is no choice any more if you cater to either markets: either you're compliant or you can and will get fined to oblivion.
That first link doesn't say what you claim it does.
SCOTUS rejected hearing the case and has let the 9th circuit decision stand for now. That means the ruling ONLY applies in areas of the US that fall under the 9th circuit. Further, if SCOTUS chooses to hear the case in the future, they may well overturn the 9th circuit decision.
As they point out in that article, this decision would instantly make hundreds of thousands of business non-compliant and open them up to being destroyed by accessibility lawsuits.
A megacorp will just do the work and write off the expenses.
Small businesses are different. Faced with tens of thousands in expenses, they have two options. The first is that they eliminate their website entirely. This hurts them and almost all of their customers (including disabled people who might have relied on the partially accessible features). The second is to lay off employees to pay for the work. Neither option is very good.
> That means the ruling ONLY applies in areas of the US that fall under the 9th circuit.
Ah, thanks. I'm German, I thought federal court orders were binding for the whole country.
> Small businesses are different.
Actually small businesses are exempt. The EU EEA has a threshold of 10 employees/2 million euros balance, and the US ADA - at least from a quick Google - of 15 employees [1]. If you're hitting either of these thresholds, you're large enough to afford a once-off expense and hell, you should have a couple tens of thousands of dollars in reserve anyway simply because your employees rely on you being able to make payroll even if disaster strikes - even at 10 employees and 3000 dollars per employee in total cost, that's 30k in payroll a month total so you should have 60k in reserve anyway.
For those who don't, well, please don't operate in a way that externalizes costs and risks onto others - no matter if it's disabled people, your employees or your customers.
> Faced with tens of thousands in expenses, they have two options.
A lot of small businesses don't do their own website, they use social media or SaaS providers - Wix, Wordpress, Jimdo, or (for restaurants) Just Eat and their competitors. For them, the SaaS provider does the heavy lifting, and besides: these sites usually don't have much content anyway.
My employer has more than that, and is not subject to it. I don't know exactly why, but I think has something to do with availability to public? Our users are employees of our customers.
However, consider how much do you worsen the experience of the majority, and how much do you improve it for the minority? I think that should factor into this decision.
I think the article is mostly trying to make an effort to inform people of the options available to them, so that when you are creating estimates of the work required to support accessibility requirements, you're not overestimating out of sheer ignorance.
If 99.99% of your target audience is not using screen readers, then you need to decide if worsening their experience to accommodate the other 0.01% aligns with your project plans and goals.
In some cases it will, in some it won't. It depends.