I remember when I was in the app-writing business, and our devs would be constantly trying to bump up the minimum OS version supported. “See here, it says that only 10% of customer devices are on OS version 10.1 and below. We must bump our minimum version to 10.2 because us developers are tired of supporting this old shit and legacy code paths!”

This seems to me to be a lot like a salesman simply hanging up on 1 out of 10 of their potential customers. Makes no sense to me, but the version bumpers seem to be winning. The number of apps that no longer support my iPhone 7 is growing and growing…

For example, I'd suspect that people who stay on old iPhone's are less likely to spend money on apps. But it's a small, very unfounded suspicion.

I'd be curious to see if anything works out though in how stuff like that lines up.

I'm thinking specifically of a 3rd party camera app, or maybe one of these modern 3D mapping apps that uses LIDAR to model a room. These apps can (and should!) continue to work on the hardware they were developed for, even if the author bumps the minimum version past what is supported. If the app author builds in reliances on a web api that expects an up-to-date companion app, that was/is shortsighted and should be discouraged.

This makes sense if that 10% are costing more money than they generate, which seems especially likely since people that are frugal enough to (for example) hang onto an iPhone 7 are also unlikely to spend much on other frivolous purchases.

Supporting those older devices can range from supporting multiple code paths due to different APIs, or fallbacks for missing HW performance and/or features. All of that adds up in terms of developer time, build/infra cost, etc.

Just my unsolicited, non-expert advice: don't make your writing more generic just to appeal to a wider audience.

I could feel my soul leaving my body while reading this

I'd also wager few apps have everyone in the world as active users, which is the next sentence in the article.

Really it shouldn't be up to the developer it should be up to the disabled person to buy tools. Just like someone may need to buy a wheelchair to move around, they should have to buy a specialty browser that handles their limited visibility needs or brail tool interface.

No, that’s the wrong analogy. The ADA is there to ensure that people with wheelchairs can find a barrier-free entrance to a building, and a curb cut at an intersection.

It should be on us, the developers, to ensure our apps work with the tools of the trade to enable people with limitations. So, our apps should be usable by screen readers. The screen reader is the analogue to the wheelchair here.

This is one of the great things about HTML. Even ignorant / lazy / time-constrained developers are likely to output something that sorta works, just since they’re using divs and imgs and whatnot.

And the bar is so low! Adding accessibility labels takes not much effort at all. And, as an added bonus, accessible apps are easier to test, since testing frameworks like Playwright can hook into accessibility info directly to validate assertions.

Extreme? The WCAG standard for text most organizations use (Level AA) is 4.5:1 with 1:1 being black-on-black and 21:1 being black-on-white (or vice versa). The higher standard (Level AAA) is only 7:1. Most people wouldn't want to read your content if everything was 7:1 or lower.

> Facebook has long resorted to using AI descriptions

Facebook didn't upload those images, their users did, Facebook isn't responsible for them having good text alternatives.

> Just like someone may need to buy a wheelchair to move around

To go along with your poor analogy, blind people have "wheelchair" equivalents, called screen readers. They're useless if don't build "ramps" that meet established building standards, websites and apps that follow established standards.

> Really it shouldn't be up to the developer it should be up to the disabled person to buy tools. Just like someone may need to buy a wheelchair to move around, they should have to buy a specialty browser that handles their limited visibility needs or brail tool interface.

How can buying a specialty browser solve a problem of a blind person needing alt text for images?

You, as a developer, can determine when AI-generated text is good enough for your images—sometimes it is, and sometimes it isn't. A specialty browser cannot, and should not, be trusted to make that decision, so it will need hints from the developer. And, once the developer offers those hints, any mainstream browser, not just specialty products, can make use of them.

> How can buying a specialty browser solve a problem of a blind person needing alt text for images? If a picture is worth a thousand words you're never going to get the alt text right. There can always be complaints it's not good enough. Look at what happened to Dominoes. They made efforts but it wasn't good enough.

I think that a big part of why it sucks is that people feel comfortable expressing the idea that working to allow people of all abilities to enjoy the same conveniences is wasting time.

Did they? Because the suit alleges that they did not have alt text.

> each place has a phone line that can be called.

Ok but what if the person has troubles talking or hearing or dialing the phone?

Accessibility doesn't even take that long. I updated a site I run to be compliant in less than a day. Corporations can afford to meet regulations.

Edit:

According to the lawsuit the phone number was not added too the website until after.

Also from the lawsuit

> But there are substantial reasons to believe that the phone number does not provide the same level of independence and convenience as does the website and the mobile app. In particular, as the district court noted, "callers may experience delays and be placed on hold." Pet. App. 24a. Ambient noise may distract from and interfere with the accurate taking of orders. See p. 8, supra. And giving a credit card number to a live human being over the phone may create a greater risk to privacy than does submitting that information through a secure website. See DCt. Dkt. No. 33 at 15.

This is pure nonsense. So what if you may experience delays or be put on hold. Just because something exists doesn't mean you're obligated to provide it.

"credit card number to a live human being over the phone may create a greater risk to privacy" is absurd, it's the way people been taking credit cards from inception to very recently, either it's not good enough and should be banned all together or it's an acceptable means of charging a card. Plus there is protection from the CC company.

Why don't they just use high contrast? Why is readability so unfashionable?

Which then makes it downright painful for someone with regular eyesight, who sets their monitor to high contrast to improve photo rendering. Grey-on-grey is the only website design that doesn't make me immediately back away.

What's so wrong with black text on a white background that it's considered extreme?

Surely you could've shared your take on the actual substance of the post?

The last app, I figured a way to make that easier to manage, and reward use by non-disabled folks.

I have a long-press help feature. If you long-press on any element in the UI, up pops a popover, with a header, and body text, pointing at the element. The popover explains that element.

It's fairly easy to have a long-press gesture recognizer applied to the main view, and dynamically figure out which element was hit. I then look for the accessibility items. If they are there, I do the popover.

I use the accessibilityLabel for the header, and the accessibilityHint for the text. It works extremely well, and no one has ever had it pop up when they weren't specifically trying for it.

I believe that Cook is totally serious, because he's a gay man who supports his community of shared interest. If there's one community that has some serious "skin in the game," when it comes to privacy, it's gay folks. There's places in the world, where it's worth your life, to be outed.

But he's just one man, and no spring chicken. His successor may not be as vigilant. Also, Peter Thiel runs Palantir, so there's that.

I think ultimately the real Revelation will come when they either don't begin serious advertising, or they do.

It's surprising (to me) that this has actually caused working partners to get peeved at me. They want to occasionally do things, like see when people originally signed up (for example, we keep last activity, but not original inception. Last activity is important for doing things like culling cruft, but there's really no use in knowing when someone signed up -except for vanity metrics).

If the "need" is "Occasionally want to look at vanity metrics," then that (to me) does not count as "justifies holding onto data."

In our latest app, it is a fairly small app that Serves a small community, but we are constantly getting Chinese hackers, trying to get in.

I won't be so arrogant, as to think they won't, eventually, get in, so we make sure that there's nothing in the liquor cabinet, if they finally break in.

[0] https://littlegreenviper.com/welcome-to-little-green-viper/p...

* Almost

https://web.archive.org/web/20121114115948/http://mediaateli...

I thought CheatSheet was the original indie app which Apple copied for its iPad menus, but it seems KeyCue seems far older and such more original.

> Similarly, this is what permits scripting desktop apps from AppleScript.

AppleScript also has a second interaction in which the App gives access to an API to its “logical” object model. Instead of “Select item in list, then click on the delete button” the programming model is more “Tell the app to delete the e-mail”. On more complicated scripting tasks that makes a huge difference. But that depends on the developer on providing an AppleScript dictionary – which not everyone does. And Electron apps are of course black boxes, in scripting and more often than not in accessibility.

I’m still not perfect about it but have trying to make a habit to do these things and will periodically test apps I’m working on with e.g. large fonts enabled in Settings, which doubles as a layout robustness test and improves the experience for everybody since it prepares for edge cases that’d otherwise been missed.

By the way, the blue on yellow, and blue on green buttons won't pass color contrast requirements. Black on yellow will work, and white on blue (for darker blues) will work. Finding a set of branded colors that contrast as needed is tricky too.

That says quite a bit about professionalism in the software development field.

Using spans with event listeners instead of anchor tags is my biggest pet peeve of incompetent frontend engineers. It’s like they go out of their way to take something that they get for free and then spend time and effort to break it.

You can argue it’s morally wrong to not support that edge case, but I do understand why it wouldn’t be a priority for most without legal prodding.

I'm curious: What fraction do you think it is? And what fraction do you think it should be for it to be taken more seriously?

According to CanIUse, that's a similar percentage to the share of users who use browsers that don't support Flexbox. Have you used Flexbox recently? If so, you've excluded a similar slice of your potential user base.

And, just like with ignoring flexbox, you can of course code around this. I've actually written SPAs with screen reader support, and it's a pain. Advocates will tell you that if you just follow the WAI-ARIA standard, it'll work seamlessly! But no -- in practice, each screen reader is like a mini-IE6; they all deviate from the standards in strange and unpredictable ways.

Ignoring the fact that this alone represents a small slice of a larger pie, 2.4% still doesn't seem insignificant to me - that's nearly 8 million people in America alone. In any case, that answers my first question - now how much higher would that number need to be for it to be significant to you?

To me it’s less of an absolute percentage and more of a function of how much extra effort needs to go into it, and whether the usability of the rest of the product needs to suffer. I’ve seen potentially useful features nixed because they can’t be made fully compatible with JAWS, which seems silly to me.

Then you could provide the accessibility-minded users with something customized to their needs, instead of trying to shoehorn accessibility onto a layout that might have no commonality between what "normal" users want and what accessibility-required users want.

The ADA has a private right of action which means that there's distributed effort to find out what's a reasonable accommodation and also to drag businesses into compliance. There's plusses and minuses with this approach, of course.

Your first half of that sentence is debatable in absolute terms but in practice almost always right due to the second half. It can be reasonable to have an alternative version of something — for example, an audio or braille version of a printed document, or a ramp alternative to stairs – but the really hard part is actually keeping them in parity. If something is seen as a compliance obligation, I’d be shocked if that actually happened versus resources being allocated mostly to the extent that they’re cheaper than legal fees.

I find your comment interesting because it speaks to users who can see, just not well. When I think of web accessibility, I (mostly) think of users who are entirely blind. While it turns out:

~80% of screen reader users are blind. The other ~20% may be partially vision impaired, or sometimes not visually impaired at all (but use it due to things like dyslexia). [1]

~2.4% of Americans are visually impaired and use (or could benefit from) a screen reader. [2]

A "low vision" / "low touch accuracy" version of an app would likely be serving less than 0.5% (20% of 2.4%, see above) of your userbase. (As opposed to simply supporting screen readers in the "regular" version of the app.) Doesn't seem like a priority to optimize for 0.5% of your userbase when you're just trying to vet an unproven idea.

[1] https://www.tempertemper.net/blog/not-all-screen-reader-user...

[2] https://nfb.org/resources/blindness-statistics

My mom has been legally blind for almost two decades now, IIRC. It's only within the past year or two that her computer and phone usage has begun to switch to primarily screen reader-based rather than primarily magnification-based. From then and continuing on to this day, she chooses between the terms 'low vision' and 'blind' (and various others) mainly according to what she thinks the person she's talking to will most easily understand. (Although over the course of time she has gradually shifted toward favoring the word 'blind', both as she becomes more connected to the local blind community and as her vision continues to degrade).

One thing to keep in mind is that going from normal/visual phone usage to a screen reader is like learning to walk all over again (and discovering that some paths are not for you anymore). It's starting over from zero, and it sucks. Going from typical visual usage to jacking up your font sizes is basically free, and using some kind of magnification a fairly natural next step. For people with progressive vision loss, there may be decades where one is 'blind', but it's still not efficient or opportune to drop everything and switch to relying exclusively on a screen reader.

Screen readers are convenient if you want to do anything while reading (I listen to at least view articles per week that way. I'll even admit to reading HN comments with screen reader. Surprisingly accessible).

It's almost always a mixed usage: one minute users use a feature, and the next minute they are fine without it. But those features are very nice to have

Definitely. I think one good way to think about it is as a matter of engineering excellence. Yes, there are moral and legal cases for accessibility features, but it's also a dimension of making software that is great to use and demonstrates attention to important details. It's part of the fit and finish and general UX.

Accessibility features are absolutely vital for some users, but for other users they are still nice to have. And to everyone, they are signals of quality, care, and maturity.

These days most operating systems already come with a voice control feature, designed for people with a motor impairment to use their device entirely by voice.

When you add alt text to an image button, you're not just enabling a blind user to hear a description, you're also enabling someone with carpal tunnel to speak the name of that button to activate it.

Most other accessibility APIs and preferences have multiple use cases like that, too.

That's why accessibility is designed the way it is: you're not modifying your app to work with specific disabilities, you're adding missing semantics and respecting user accessibility preferences, and assistive technology adapts things to work with different users.

What will end up happening is you have your normal app which isn't accessible, and a second app with a fraction of your features that is likely often broken because it's hard to prioritize.

So just like we have desktop and mobile views, I'm just proposing one more view where you also get to reuse some of your components, and where you get to pushback on stuff like animations, rich interactions, or novelties.

Only occasionally does the "accessible way" need to be in addition to what was planned all along, such as up, down, left, right arrow buttons beside a draggable map, you don't need a whole separate map for that.

You could be right though, especially with more and more sites blocking robots. Legitimate companies might just have to shrug and say, "this site prohibits me from reading it. You'll have to go there instead) though that seems like a legal problem to me rather than a technical one.

I wouldn't advise it, though.

https://news.ycombinator.com/item?id=39227843

Fitts' Law intuitively and mathematically explains why pie menus are faster and have lower error rates than linear menus. Fitts's Law says in effect: the bigger and closer a target is, the faster and more reliably you can hit it.

https://en.wikipedia.org/wiki/Fitts%27s_law

>Fitts's law (often cited as Fitts' law) is a predictive model of human movement primarily used in human–computer interaction and ergonomics. The law predicts that the time required to rapidly move to a target area is a function of the ratio between the distance to the target and the width of the target. Fitts's law is used to model the act of pointing, either by physically touching an object with a hand or finger, or virtually, by pointing to an object on a computer monitor using a pointing device. It was initially developed by Paul Fitts.

Pie menus both minimize the target distance, while also maximizing the target size. And the physical directional gesture required to select an item does not demand your continuous visual attention and cognitively taxing hand-eye feedback loop. You don't need to look at the screen to select items from a pie menu, so you can reliably "mouse ahead" or gesture, which is impossible with linear menus.

Another advantage is that they support "rehearsal", by seamlessly training novice users to become experts.

Unlike keyboard shortcuts, the physical action of the novice and expert is the same, only experts can do it faster without looking at the screen.

Unlike traditional "invisible" gesture recognition systems like Palm Graffiti or StrokePlus.net, pie menus are "self revealing" in that the can pop up a menu that shows all the available options and their direction. It's quite difficult to learn which invisible gestures are available and what they all mean, but easy to discover them with pie menus.

Pie menus also support "browsing" and "reselection", which gesture recognition doesn't, allowing users to correct errors or even browse around highlighting every item to preview its effects.

Since pie menus can provide live continuous preview of the effects of the selected item in the application itself (which is especially nice when you use the distance as a parameter, for example a pie menu that lets you create eight objects, with a pull-out size parameter: the more you pull out, the bigger the object previewed at your cursor, which switches to different objects as you browse around the menu, then turns into a real object when you release the button), so you can see the effect and release the button when it's perfect, or go back to the center to cancel. Often the only feedback you need is the live preview of the pie menu selection, and popping up a menu would be a distraction.

Once you learn the directions, you can quickly select items by stroking in the desired direction without even looking at the menu, so pie menus can perform the selection without popping up the menu. There's no need to pop up the "self revealing" menu until you stop dragging the mouse, or you can pop it up instantly by "clicking up" the menu. So a novice can get directions instantly, while an expert can fly ahead without waiting for directions, then pause for directions or confirmation that you have the right selection at any time.

There's a smooth escalator moving you up the learning curve every time you use a pie menu, training your muscle memory through rehearsal.

That is how pie menus "Lead, follow, or get out of the way".

We performed an empirical study in 1988 that measured eight-item pie menus to be 15% faster than linear menus, with less frequent errors.

An Empirical Comparison of Pie vs. Linear Menus (Jack Callahan, Don Hopkins, Mark Weiser, and Ben Shneiderman, Proc. ACM CHI’88):

https://donhopkins.medium.com/an-empirical-comparison-of-pie...

>Pie menus gain over traditional linear menus by reducing target seek time, lowering error rates by fixing the distance factor and increasing the target size in Fitts’s Law, minimizing the drift distance after target selection, and are, in general, subjectively equivalent to the linear style.

[...]

>Pilot study results: A pilot study of 16 subjects showed that users were approximately 15% faster with the pie menus and that errors were less frequent with pie menus. Statistically significant differences were found for item seek time but not task type. Subjects were split on their subjective preference of pie and linear menus. Some commented that they were able to visually isolate an item easier with linear menus and that it was hard to control the selection in pie menus because of the sensitivity of the pie menu selection mechanism. These subjects tended to be the most mouse naive of all whereas those who had heard of or seen a mouse/cursor controlled system but had not used one extensively tended to prefer pie menus. The most mouse naive users, while finding linear menus easier, tended to be better at pie menus and commented that with practice, they would probably be superior and in fact prefer the pie menus because of their speed and minimization of hand movement with the mouse. Not surprisingly, therefore, most of those preferring linear menus did not have a strong preference on the scaled subjective questionnaire.

More about Fitts's Law and pie menu in this thread from Sept 27, 2022 on: Cairo: Alternative Windows Desktop:

https://news.ycombinator.com/item?id=32992673

More info:

https://news.ycombinator.com/item?id=39228342

[1]: In the past I did have some criticisms around performance and non-native widgets, but those have been worked out

- no `new`

- no single class files only restriction

- named parameters

- no java.util.arraylist nonsense.

semantically it is also very different (unlike eg. Kotlin)

- first class support for passing functions as parameters (this is the worst issue with Java by far and can't be understated)

- sound type system (String cannot be null)

- async/await

- no bytecode

lots of other QOL features as well. If you're really thinking of trying out Flutter don't let Dart stop you from doing so. You may even find you like it!

Why do you think C# will give you a better outcome?

We don't have a legal mandate per se to be accessible but many of our subscribers do have a mandate that services they buy have to be accessible. Many of our customers insist on it because they have a legal mandate to be accessible. The university that we are a part of got sued because it made web sites that were not accessible

https://www.insidehighered.com/news/2018/12/10/fifty-college...

and in principle any school could get in trouble for buying products and services that aren't accessible. So it is part of the contracts we sign now, we do accessibility audits regularly to stay ahead of issues, sometimes we have have customers who do their own audits. Thus a11y is a major priority here so I have learned all about ARIA (our app is a great fit) not to mention the real formulas for color spaces, contrast ratios and how to use a screen reader.

The US doesn't really have any regulatory apparatus for disability access - ADA liability is how it gets handled. The legal test is murky, the amount you're liable for is murky, and thats generally considered ok, because it will make you fix your shit (legal term).

https://www.vcstar.com/story/news/local/2023/05/15/ventura-c...

https://www.forbes.com/sites/gusalexiou/2023/06/30/website-a...

In the EU:

    As of 28 June 2025, companies must ensure that the newly marketed products and services covered by the Act are accessible. Member States may decide to make some exceptions. For instance, they can allow more time for the application of the new rules to service providers using self-service terminals. Microenterprises (i.e., a small business with fewer than 10 employees) which provide services also are exempted from the obligations of the Act. Nevertheless, all microenterprises are encouraged to make their products and services accessible to persons with disabilities. 

Plus, its not that hard to do correctly, so the “we’re a startup on a critical burn rate” stops working as an excuse rather early

In my previous life at an ad agency we had a number of clients getting pursued by accessibility lawyers and firms. These were typically nothing more than shakedowns for some insignificant settlement (<$10k) - but it was an open-and-shut case if you wanted to take it to court so it was just easier to settle and spend a couple of sprints on WCAG best practices.

IANAL and my agency didn't do the actual implementation so it was typically up to the client to sort out - but having a lawyer on hand should be one of the first things you take care of once you start making or accepting large amounts of money.

Typically it was just an embarrassing experience for some middle manager, some lost budget, and some extra dev hours to add 'WCAG Compliance' to the QA checklist.

It's not a question of it being too hard or easy, but as always, a question of priorities.

Say you can either build feature A which is expected to open up the product to be used by 1% more users, as people been asking for that feature. Or you can build feature B, which enables motionsick people to use your app without getting sick from your wasteful animations. This will help 0.001% of your current users, when you have 10,000 users in total lets say.

Not saying it's right or wrong, but I understand why people (managers/owners) make the choice to do feature A instead of feature B, especially in a startup-context where it might be the (imaginary or not) choice between surviving or not.

I'm personally in the camp of thinking about accessibility as part of all the work done, but it's not exactly the mainstream workflow.

Meaning: you should think about it early on, and design for the need, but not over invest in it too early.

If you're at the the stage where you don't know if your idea will work, you shouldn't be polishing accessibility, just like you shouldn't be denormalizing your database schema to increase performance.

However, you should be thinking about accessibility, just like you should be thinking about how your database queries will scale if you get increased load.

So for example: if you're making a database of images, why not add a field for alt text from the start and start populating it now? If your app needs drag and drop, why not start sketching out an alternative flow for people who can't drag and drop now?

Accessibility is more often compared to security; if you don't think about how to securely transfer or store data early on, it's going to be much harder later on (support for SSO before you have users might be premature optimization unless your product is especially geared toward enterprises).

'big' open source projects like blender,etc - what are their responsibilities? A quick look at the site doesn't find much except that it's a work in progress.

What is the responsibility of a single developer with a 'scratch an itch' project on github?

Can I as a developer release something for personal use when it's good enough for my own purposes, but miles away from being accessible?

It's going to vary a lot, but one metric that's used by lawyers in finding companies to sue is whether it impedes another protected action. For example, hiring employees has lots of rules and protections, therefore the website where people can look at and apply for your jobs needs to be accessible, especially if there is no other way to apply.

This was about 5-6 years ago though and I was told back then that there was a number of people who are deliberately scouring the internet for websites with accessibility issues so they can sue them for not complying with US accessibility laws. These lawsuits I believe can be fairly costly for large organisations – I know I was given numbers in the millions, but I was on the technical team so I can't say for sure whether that number is accurate.

In one of the cases I was involved with we were given a period of time to take remedial action to make our site accessible otherwise we could face additional fines. I'd assume if you have a reasonable excuse that the penalties and remediation period would be more lenient.

I'll also add I'm from the UK, but our websites served US customers and our lawsuits came from the US. I believe the UK has similar accessibility laws, but I guess we don't have the same culture of suing businesses.

If your font is slightly too small or an alt-text is missing, or whatever? A lawsuit should have zero chance of success, which would then eliminate the blackmail game of "settle or we sue".

Not a friend of accessibility though. It requires so much work to satisfy a small base of users.

Reader mode will help with some disabilities but not others.

> It's only when people reconstruct primitives that assistive technology breaks.

I like using the platform too, but users don't use primitives - they interact with higher level elements like carousels, profile pictures, comment boxes, and most new UI elements do not have accessibility industry ARIA role.

It was only after seeing the ease with which he could navigate the world in spite of his chair that I appreciated how important that law was, because I also saw so many things that he wasn't able to do even though there was a law. Our entire world is built around and for people who see, hear, speak, walk, climb, and crawl.

As developers, I would say we're second only (maybe) to government in the ability to make the world accessible. I'm as guilty as anybody at this. Please make the effort to make your work as accessible as possible to everyone.

It's quite hard to notice a lot of these things before you actually have to deal with them. I knew ramps were needed and automatic doors, but the shock was more about little things. But, a big thing I've noticed is that like 90% of things that would help us would make lives easier for normal people too. Which this was a big thing that opened my mind of how to address a lot of accessibility, is just think more deeply. If it affects a wheelchair it also affects a stroller, your wheeled baggage, things being dropped between cracks/small gaps, being able to clean between gaps (and subsequently the mold, water damage, grime, etc that makes things more costly in the long run!), your robot delivery drone, whatever. Ironically making the world more accessible for wheel-chaired people makes the world easier to robotize, which in turn can then also help disabled people. But the lesson is to think deep, because there are so many parallels. So if you hit upon one, you benefit the others. So you don't need to sit around thinking of every possible disability to make things accessible, which is a big blessing in itself. But if you think with care you will make the world much more accessible. No one expects to be perfectly accessible to everyone and disabled people know the world isn't going to bend to them, but that also doesn't mean we shouldn't try and care for our friends and family (other humans). But since it can help, just remember that a lot of things that help them will also help you.

[0] https://news.ycombinator.com/item?id=39748213

This was a really common observation among the parents in our circles. You really notice things like missing curb cuts or bumpy sidewalks when pushing a stroller, so many things where only needing one hand is really helpful when holding a baby, having restroom stalls big enough to accommodate a wheelchair also means a stroller or second kid can fit, etc. A lot of people went from sort of vaguely thinking this is important to vocally backing accessibility at public meetings.

One important example: public bathrooms. Hatred of homeless people has driven a lot of American cities not to have them, which means people with certain conditions stay in or avoid certain areas. It also sucks for parents and I’ve noticed at planning meetings that one of those things which should not happen but does is that, say, an older low income person saying they’d use a park more if it had a background does not get the same response as, say, the affluent mom saying the same thing. It’d be nice if that didn’t require haggling but if it takes a coalition to get fixed at least it still happens. I noticed something similar with our local bike path expansion - motorized wheelchair users are looking forward to a smooth, safe, fast path, too.

> Why do I have to go a long way extra for an elevator?

  - Why did I just walk past 3 flights of stairs on my way to the elevator?
  - Why did the handicap subway car drop me off at the far end of the station? 
  - Why did 3 people rush in front to get to the extra wide gate when there are 5 empty normal gates?
  - Why does the flat moving walkway have a divider that's meant to prevent bikes but also prevents a fucking wheelchair or walker!
  

God... yes

> I often wonder if Americans are especially selfish.

I can only speak to America and visiting another popular Asian country. I don't think it is uniquely American. It seems more related to people struggling and thus how much they're in their own world.

I think about this a lot because it makes it a solvable thing. But maybe I'm just hopeful. I mean either way we live in a biased internal world, and if we're going to choose, I'll be optimistic in my pessimism (that things can be solve or significantly improved). At least that framework keeps me moving forward.

But also, these experiences make me think about how important it is to offer help. Even in small cases or just see if you can lighten someone's load. There's many situations where it's little to no cost to you (in time, effort, and/or money) but mean a lot to others. Even offering often can turn someone's bad day into a good one (unfortunately sometimes after you leave). So I try to remember the little things. Because it is the little things that get in the way and make our lives difficult, so it makes sense that little things can also improve them. You don't have to be wealthy or a superstar to change the world, you just have to be a friendly neighbor.

Yes, this is very well said and has been my experience as well. It's also been my experience that generally speaking we (the world and the US) are getting better and better at a11y. My cousin was in a wheel chair for decades before he passed away, and there were a lot of places we just flat could not go. It was a nightmare, but the worst enemy was ignorance, not selfishness.

If you're not there yet, the next terror is desperately searching for a bathroom for your kid. It's especially hard in city centers where every place has put code locks on their restrooms "for customers only"... It's fine, I'll buy something, but my kid needs a bathroom right now!

As a parent, I would disagree with the world is built for those that crawl. New parents are told/suggested to crawl around their house just to get a closer eye-level exprience of what their toddler will have.

This isn't something I've really considered, but it's both very true and very important. Thank you

I think 'accessibility' can be reframed as being more generally about flexible configuration and control for everyone to benefit from.

For such personal devices it's not just about about disability, it's about the freedom I want as a user to mold an interface to actually fit me and my usage style moment to moment. Sometimes I want a screen read to me or just a section of it. I'm not visually impaired, I just might not want to look at the screen.

The ADA exists and is a powerful law. If you are willing to put in the work, generally you're going to get a pass.

I wrote a bunch of accessibility guides (with a lawyer looking over my shoulder) around 2000 for a F500. I have since worked with blind users to add accessibility to apps. If someone is asking, and you can help them do it. You will have a massive advocate for what ever it is your doing!

Now, that it is successful, you can think about it and spend resources.

Remember all the original Download/Porn sites. Those had a11y issues even for regular users, yet it was popular. a11y matters only for useless websites because they can't afford for users to leave

This is why tech first finds an interface that works and makes money, and then turns around and makes it accessible.

What is important is that, when you found that something works and you start profiting from it, that you make it accessible. incidentally, this is how the EU law works aswell.

I had many tricks to "sell" accessibility to the various clients and one of them was "What percentage of your potential users would you like to immediately piss off?" "How comfortable are you with random lawsuits? [Then you have to talk about the Target lawsuit]"

Solving a new problem / use case is going to help you be successful, accessibility isn't novel. It's a feature.

If you become really big, you get x amount of time to implement a11y. Good enough balance.

What's that if not regulation?

While YouTube does not supply SVGs, the SVGs from Instagram [2] and GitHub [3] did not include any a11y metadata. I was really surprised by this, given the massive user bases thereof, both consumer and developer. Maybe that's because it's not universal what should be there?

So I had to insert it myself. I was scared to make a repo sharing these changes, but I will drop the GitHub one here:

In `<svg>` element I added:

    role="img"
    aria-label="[title + description]"

    <title>GitHub Octocat Logo</title>
    <desc>An Octocat shadow in front of a white circle</desc>

[2] https://about.meta.com/brand/resources/instagram/instagram-b...

[3] https://github.com/logos

Probably just "Github logo" or even "Github" would do just as well. If the image/logo is purely presentational (that is - if you remove the image do you remove information from the site?), just blank it out with an empty string.

Is the issue specifically the aria-label being too verbose? Like it's OK for the other metadata or even that's overkill?

The best way to figure it out is to use the screen reader in your operating system. It's hard to judge usability without actually using it.

Aria-label, and the rest of the HTML (like just the text content, or label attributes, etc) all build up the accessibility tree which is what screen readers read out. All browser dev tools should have a way to view this. If putting a <title> inside an SVG doesn't result in that showing up in the accessibility tree, it's next to useless.

Can you clarify how many people who merely need corrective lenses need to also rely on software accessibility features? The way you use "about half the planet" in your comment implies that every visual impairment is equal, and that all visual impairments result in increased accessibility needs.

My only accessibility need, funnily enough, is a high-DPI display, despite technically having impaired vision, because my vision at close distances (even corrected) is so much better than 20/20 that regular displays look distractingly pixelated to me.

It's like using the percentage of people without perfect control of their legs as a proxy for how many people actually need to use a wheelchair. Yes wheelchair accessibility is important, yes many people need to use one, but no not everyone without perfect control of their legs need to be in a wheelchair. Sometimes they only need crutches, etc.

Which they do.

And accessibility-oriented architecture already knows that, and has been operating on that principle for decades. So in the exact same way: because half the planet needs glasses, no matter for how "trivial to correct" or actually bad their eyes are, your UI needs controls that allow people with any level of visual disability to compensate beyond what their glasses might correct for, if the medium your UI is presented in does not offer (adequate, because that's not a given) controls already.

That's basically exactly what I said yeah. Which isn't correct because plenty of people who are not in their prime still do not need those things. It doesn't help with making your point.

Instead I'd cite statistics on how many people actually use these accessibility features, and not some far more general group of "how many people are not perfect".

Also, in case it isn't clear, I'm not arguing against accessibility features at all, I just think this part of your argument was a bit misleading.

>16% of people have some kind of accessibility requirement

16% is 4 in 25 people, also no guarantee you'll be able to accommodate their specific accessibility requirement, depending on the app, and depending on the requirement.

That's not to say the app shouldn't be accessible, more that, you should think about when you spend the money to implement things like this, and how that money may best be spent to accommodate the highest number of people. Figure out who those people are, then figure out what your revenue growth would be if you captured those people, then compare those numbers to how much you'll have to spend to accommodate their needs. That's no different than any feature upgrade really.

Where you'll likely arrive at is the same place many apps have, unfortunately, arrived at, which is to probably just get text scaling quasi working and leave it at that because anything more is throwing cash into a black hole.

If government regulations are going to insist I have to put that investment in day 1, I'll just take up badminton or something.

It's not that hard, and if every developer spent an afternoon looking into things, they'd realize how easy it is to get it right if the team is aware of it.

I'd not mind if like developers need to go through security and privacy training, they'd also go through accessibility training. A little investment would go really far.

They all handle accessibility well, you just need to remember adding labels to your icon buttons, and you are good to go. If you don't reinvent the wheel thinking your buttons are soooo different that it needs to be rewritten from scratch, things just work.

For example, the ADA doesn't require employers to accommodate disability needs until a business has 15 employees.

Of course, culture is a huge factor. The US wasn't built on "regulation, or else", it was built on "if you can, do". This makes business boom, but makes other concerns, like welfare, an afterthought. And it's up to debate which system is better to exist in. People dislike the rules, until it ends up benefiting them.

I haven't found anything in that vein and I'm curious if anyone's working on it.

It's part of why I've really tried to stay employed with smallish businesses, because they're more human.

That aside, the work of prioritizing accommodations is already done. Just read through the WCAG criteria, start with level A, then AA. They already determined what the most critical issues are to accommodate everyone who uses your app. I find it extremely callous to frame people's ability to use your product in terms of the revenue they have to offer you. A storefront has to build a ramp because everyone deserves basic human decency, not because they want wheelchair users to spend money inside.

My apologies for the math inaccuracy is in the mail.

I wasn't really trying for pedantry, but, if the check's in the mail, thanks for 0.666% of a coffee ;)

[1] https://www.accessibility.works/blog/avoid-accessibility-ove...

This post reminded me of a video I found really cool from a couple years back where Masahiro Sakurai(creator of Kirby, Super Smash Bros) talked about the importance of accessibility options and how Japanese developers - at the time, were lagging behind their western counterparts. He shows examples from and references Sony/Naughty Dog's 'The Last of Us'.

I'm not sure if this is something that Sakurai influenced or not, though I have noticed larger Japanese AAA game studios adding more and more features in terms of accessibility in the last couple years from studios such as Ryu Go Gotoko(Yakuza series), Capcom(Resident Evil, Street Fighter), and FromSoft(Dark Souls, Elden Ring)

Unless of course you're just experimenting and it seamlessly turns into a serious thing by accident, that is.

Asking for a friend…

Wheelchair ramps aren’t limited to wheelchairs. I have above average hearing despite my advancing age and I choose to apply subtitles to digital movies about half the time because it provides me a better more enriching experience. Solving for color contrast limitations benefits everyone even when people have perfect vision.

There are no blind soldiers in the army yet all Army digital communications are required to conform to federal regulations that accounts for accessibility. The result is higher quality products with greater availability.

Usually the best argument opposing accessibility is that the authors/developers don’t know what they are doing. When they say accessibility is too expensive that’s what they really mean, and it’s not a good argument.

However reality is much more nuanced. We're all, at best, temporarily "abled". Whether you need glasses, or your fingers have raw chicken juice on them for cooking, or you started going to the gym and your muscles ache too much to walk, or have a newborn and can't turn the TV up too loud.

We all go through various levels of impairments over our lives that can make use of assistive technologies. "Accessibility" really is just usability, and building products for real people.

If developers don't know how to make web services accessible, it IS expensive because it will take time to train them. Developer time is often a company's biggest expense.

Moreover, not every web product is simple to make accessible even by experts because eyes can process a lot of information very quickly across two dimensions, and UX designers often take this for granted. Translating complex experiences into comprehensible text-only applications often takes creativity and effort.

I'm not saying accessibility isn't important, but these kinds of arguments that it is always cheap and easy often actually make it harder for engineers to get the resources they need to implement it successfully.

I'd argue that implementing ARIA markup properly also makes developers consider the general markup and structure of their product. Which in turn can lead to better UX in general, as it will lead to new insights. Yes, training developers does cost time so it is an expensive. That's often true for anything that will improve your product.

> Moreover, not every web product is simple to make accessible even by experts because eyes can process a lot of information very quickly across two dimensions, and UX designers often take this for granted.

Do you think that UX designers who take this for granted are good UX designers? I'd say that if they take it for granted that eyes can process more information, that they might need a refresher course on UX. Designs that lean heavily on visually cues and have a lot of them generally tend to be too complex and cause a visual overload.

A bonus benefit of ARIA markup is that if you have any automated UI tests they benefit from good ARIA markup and generally tend to be a bit more stable than tests using regular classes and IDs.

This specific case: ARIA labels also help search engine indexers find pages and extract information within pages more effectively. Excluding contemporary concerns about search engines intercepting advertising revenue by doing this, it is undoubtedly better for the able-sighted and blind user alike to have the option of finding an answer by visiting one page rather than two.

More philosophically: if accessibility makes things easier for people with a disability, that means it is easier for someone emulating a disability. For instance, whenever I'm holding something in one hand, I'm effectively emulating the abilities of a physically one-handed person, so if you make a design that works for one-handed people, you're also giving everyone else the extra opportunity to multitask.

> I'm not saying accessibility isn't important, but these kinds of arguments that it is always cheap and easy often actually make it harder for engineers to get the resources they need to implement it successfully.

Parent poster wasn't saying it is cheap and neither would I, but whilst the incidental benefit of accessibility improvements to able-bodied people might not seem obvious, it always exists.

What accessibility demands all users have is neither light mode nor dark mode, but the ability to easily choose between them (and maybe other color or contrast options).

This is why accessibility is closely tied to hackability and customizability. There isn't one solution that works for everybody. Accessibility is about giving users flexibility and control in the way they access, consume, and produce content, etc., so that they can do so in ways that meet their specific needs. It's about user agency in the same sense as ye olde ’user agent'— and that's why it's something that should resonate with every hacker.

On the other hand I don't think the business really knows/cares what HTML you use, they just can reasonably trust people to implement stuff in the "right" way, which 90% of time is identify the correct HTML to represent the nature and structure of the design and build out from there. You'd expect things to "just work" when you are paying for front-end specialists.

In my 15 year career as a JavaScript developer all the biggest failures were directly attributed to poor training and leadership qualifying low standards. At some point people would do themselves a huge service by admitting they are too lazy/inept to train their staff and they deliver shit as a result. I got tired of all the weak excuses so now I do something else for a living.

Disabilities can be conflicting which makes catering to all difficult.

Consider, for example, that someone who is deaf will usually use a flashing light to wake them up. However, if you are someone that's prone to seizures, that flashing light is now something that can trigger a medical emergency.

Now consider how fire alarms typically work, big flashing lights and loud sirens.

With accessibility you kind of can't please everyone. Not saying you shouldn't try, but there needs to be some level of "best effort" applied.

Whether it’s from disregard or ignorance, the end result for users is the same: lack of accessibility. I don’t think the well meaning but ignorant person is bad, though. I’m sure I’ve inadvertently made software that was challenging in ways I’d never have anticipated. “Click Cancel in the next 10 seconds to stop erasing your hard drive. 9. 8.” (Guy with ALS desperately tries to move the cursor over to the Cancel button.)

There are so many ways a person’s abilities can be different that the norm. Someone can be quite empathetic and still miss a lot of things they could be doing better.

Especially web accessibility standards are so tenplatizable and test driven now, there really is no excuse.

What you're saying is equivalent to a restaurant owner who doesn't serve meals adequate to allergic people is a jerk and should go out of business.

I don't think software shop owners that are ignorant of or ignoring accessibility are necessarily jerks. Before being informed, they are transgressive to good sense; after being informed, immoral. How they act directly towards someone is what defines whether they are a jerk or not, and that, in my mind, is not really connected to the conversation.

Also as a slight tangent, public transportation! The US being so car dependant really hinders my independence, and better public transportation would benefit everyone (except car manufacturers, I suppose)

The question is which features are a must and a bare minimum and which of them are not. If your job doesn't care about accessibility (which is bad, don't get me wrong) and doesn't pay you for adding say, colorblindness support or TTS, that has nothing to do with being competent.

Accessibility is also in huge part related to cultural context. Sure, blind people and people in wheelchairs exist everywhere, but as an example where I'm from literacy is not universal. People can read for the most part but some have a very hard time reading, and TTS doesn't solve the issue in my experience. Does your website support that? Does it support a lot of visual elements/videos instead of text? Or a simplified version of the language? Does it make you incompetent, and does it make sense to add a completely different UI mode for them? That's what I mean with it being a spectrum.

In fact, assume cost is not a good argument – then why should it even be legal to compile programs that aren’t universally accessible? It’s always beneficial, and just a matter of cost after all.

Or are you perhaps being completely one-sided and unreasonable?

The result of which is, in the USA, a person in a wheelchair can enter nearly every business, use many public restrooms, and generally participate in life on their own.

They may not be the best authority on the question of whether cost is a good enough argument.

>Usually the best argument opposing accessibility is that the authors/developers don’t know what they are doing. When they say accessibility is too expensive that’s what they really mean, and it’s not a good argument.

There's no slippery slope either. If lack of accessibility is just a matter of incompetence and not cost, then there's no downside or cost to adding it everywhere. I don't get the point of not acknowledging that there are costs to accessibility. I get that it's not a good justification in most cases, but there's no benefit in denying that it has costs too. It just discredits the rest of the argument imo.

I think there are many cases where it benefits everyone, but probably many more cases where it has no positive OR negative effect for the median user. It doesn't improve the UX in a way that makes a difference to them.

The question in this, as in all things, is whether enough of your users will benefit from accessibility improvements to justify the marginal cost of implementing them versus not implementing them. And, at a more granular level, which improvements can be made to get the most benefit for the least cost.

You could probably more accurately say that accessibility never hurts anyone. But even that might get an objection, because there is a cost to implementing it, compared to working on new features, or polishing old ones.

Done well, building new affordable housing with appropriate accessibility does nothing to cut into profit margins for builders. The tax breaks and other pubic dollars almost always deliver more than the cost of ensuring common areas are accessible and a few units have slightly varied doors and bathrooms (mostly.)

That builders don't want to build more affordable housing is its own problem, but not because of ADA requirements. In general, the ADA doesn't say much about low income housing except explicitly government owned and managed housing, BTW. The ADA is overwhelmingly concerned with public accommodations (businesses open to the public) and government and public spaces, not private home construction.)

It's almost exclusively the lower profit margins for price capped construction and not the minimal a11y requirements easily covered for anyone taking public money and who is building affordable housing and not taking government money, that are the root of our affordable housing shortage.

Accessibility is an unalloyed good and your bogus attempt at providing an alternative example is easily shot down. Pick an example you actually know something about and try again.

I saw another IRL example of this in yet another football match over the weekend where one team was in a blue jersey with the other team in a black jersey. I'm not even color blind, yet it was hard for me to immediately distinguish players. I really miss the old days of home team in their club's color, with the away team in a predominately white jersey.

So not even remotely UI/front-end related to a tech forum, but color contrast is a basic way humans separate things. It is not nice to mess with that for normal things.