One thing that you largely ignore in this post is the cost of creating such accommodations.
I will give a couple of examples. The first concerns a “curb cut” scenario; the second is about a “Braille signage” scenario.
Making public spaces uglier on the public’s dime
Not far from me is a highway, which has a residential neighborhood on one side of it and a waterfront promenade on the other. In several places there are pedestrian bridges that cross the highway. One of these bridges (which doubles as a ramp onto the highway, in one direction) is currently being rebuilt; the project nears completion (indeed the bridge is already usable, as the remaining work is mostly to do with railings and such), so it is now possible to see, and judge, what the completed construction will be like.
Now, prior to this project, this was a perfectly functional bridge, which was not in any way damaged, decrepit, crumbling, failing, dangerous, or even unsightly. There was nothing wrong with the bridge whatsoever—except that it wasn’t wheelchair-accessible. Hence, the rebuilding.
The new bridge is much less convenient for non-disabled pedestrians (one must walk thrice as far to get from one side to the other, due to the lengthy sloped ramps which the new design uses). It is more dangerous to pedestrians of all kinds, due to the incorporation of a bizarre roundabout in the design of the new ramp. It is much uglier and more obtrusive; it takes more of the promenade away from greenery. The bridge couldn’t be used while it was being rebuilt, of course (the project has taken considerable time, as such things do). And, of course, the rebuilding project is taxpayer-funded.
As far as I can tell, this is a case of me paying (via taxes) for my life to be made strictly worse than it was before.
Helping users who seem strangely uninterested in solving their problems
Web designers/developers routinely hear that we should make our websites accessible to users of screen readers. The specific things that must be done to accomplish this are sometimes reasonable (add alt attributes to images)… but often aren’t.
For instance, I have been told that using soft hyphens as hyphenation hints is bad, because it causes screen readers to get confused and pronounce all the words incorrectly. Alright. Well, why is that my problem? If a screen reader does this, that sounds like a bug in the screen reader program. So the users of that program should talk to the developers of said program; or, if that does not help, switch to a different screen reader. (There seem to be quite a few options!)
Similarly, I’ve been told that using the title attribute (on links, say) is bad, because screen readers will read out the value of said attribute, which is usually undesirable. Again: why is this the web dev’s problem? Fix the screen reader, or use a better one!
And yet “accessibility advocates” seem much more interested in hectoring web developers about all the myriad inconvenient, time-consuming, headache-inducing ways in which we must cater to the strange (and strangely persistent—some of these supposed limitations of screen readers have been around for decades, it seems, despite the plenitude of offerings, of which a good number are even free software licensed and can presumably be patched, forked, etc.!) peculiarities of screen readers than they are in… fixing the screen readers.
“Every web developer must remember to do all of the following long list of specific things—many of which take time and development resources, and substantively restrict your options for implementing certain features or solving certain problems—in order to support users of screen readers” is a demand for a very large number of people to contribute unpaid work (and to keep doing so, indefinitely) to solve a problem which could be solved much more easily (with a solution that needs to be implemented just once) by a much smaller number of precisely the people who are making the demand.
I haven’t worked on front end for over a decade, so I am not familiar with recent development, but from the days I did, I remember adding the alt tag to images, but I never heard anything about soft hyphens.
Could it possibly be that the good and bad advice does not come from the same sources? And that we should listen to some sources and ignore the others? I can imagine that a set of advice that was reasonable at the beginning can grow through the game of telephone.
(Something similar happened with SEO advice, which started with “if you use keywords in the URL, Google will prioritize your page for the keyword, so use the page title in the URL rather than id=123”, and quickly mutated to “if you use id=123 in your URL, Google will refuse to index your page” that was obvious nonsense, but you could find it in 99% of articles about SEO. Or all that stuff “required by” GDPR.)
No, the lack of screen reader support for soft hyphens is a real thing, with actual user complaints behind it. Besides, that guidelines page doesn’t mention title attributes either; those are only very general guidelines, lacking details.
As far as ignoring some advice—sure. I ignore all of it, personally.
Even googling for “accessibility soft hyphen” did not return much. The #1 result on my computer says: “Well, screen readers mispronounce a lot of the words in a document or on a website. Should we just eliminate words entirely to prevent the problem? … The answer: It’s the responsibility of screen reader manufacturers to do a better job of recognizing and pronouncing hyphenated words.”
So it is does not seem like a frequent advice / complaint.
Some screen readers have issues with words that contain soft hyphens (they read syllables instead of words). Please note that this is not an issue of Hyphenator but a bug in the screen reader. Please contact the makers of the screen reader application.
The Reddit link goes to a post that has 1 karma, where 1 user suggests to remove the soft hyphens, 1 user disagrees… and that’s all.
In the Github debate, most people seem to agree that it is a bug of screen readers.
Only in the Apache link, someone recommends to do something about the hyphens. Even there, it seems to happen in context of discussing FOP, which is a PDF file generator. So as I understand it, it is not about “every web developer should adapt to the bugs of screen readers” but rather “authors of a PDF generator have an opportunity to compensate for the bugs of screen readers by automatically adding some PDF equivalent of ‘alt text’ containing the unhyphenated version of the word”. It still means compensating for someone else’s bug, but it’s a hack you only need to do once.
I think you have misunderstood my claims and my point.
The links I have posted were to demonstrate the fact that screen readers having a problem with soft hyphens is a real thing that really happens. (You seemed to be skeptical of this.)
That developers are sometimes told to not use soft hyphens, on account of this issue, is something for which I have and need no links, because, as I said initially, this is something which I, personally, have been told, by self-described accessibility advocates and/or disabled users, in discussions of actual websites which I have worked on. (You could disbelieve me on this, I suppose…)
And whether this specific advice/request/demand happens often is inconsequential. It is one example of a class of such things, which collectively one ends up hearing quite a bit, if one does serious web development work these days. The title attribute example was another. I could also have mentioned the deeply confusing and bizarre ARIA attributes.
Again: any specific such issue comes up only occasionally. But if I were to try to build a website such that screen readers have no problems with it, I would have to deal with many such issues—most of which could be fixed much more easily by the developers of the screen reader software… but aren’t. And the attitude of most accessibility advocates I’ve encountered has been that I should indeed take that (“build a website such that screen readers have no problems with it”) as my goal.
Achmiz is a bit salty because the issue came up occasionally with Gwern.net and other sites, and it’s striking that it came up at all because generally, even if there is a severe problem with a website, “theywill never tell you”. If you never ran into it, that might have as much to do with you not bothering with justification or typographic niceties like fixing linebreaks with manual soft hyphen use.
I once spent nearly a month working on accessibility bugs at my last job and therefore found the screen reader part of this comment incredibly insightful and somewhat cathartic.
Helping users who seem strangely uninterested in solving their problems
I don’t think this is unrelated to the “Deaf” community’s “hearing aids/cochlear implants are genocide” position. I suspect getting other people to submit to their arbitrary whims is the point, and the “problems” are in fact the means to that end.
I would guess it’s because the Americans with Disabilities Act provides a private right of action against businesses whose websites are not accessible to people with disabilities, but doesn’t say anything about screen reader software bugs.
I would guess most of them just want their screen readers to work, but a badly written law assigns the responsibility for fixing it to the wrong party, probably due to excessive faith in Coase’s theorem.
Yes, that may be part of it. I suspect, however, that in this case it is a slightly different (though somewhat related) dynamic that’s mostly responsible.
“Accessibility advocate” is qualification which leads naturally to “accessibility expert”; and there is a certain amount of demand for such people (e.g., as consultants on projects which are required by regulations to be “accessible”, or which otherwise benefit from being able to claim to be “accessible”). Such people have an incentive to establish their credentials and their credibility by talking about what web developers must do in order to make their websites accessible, to frequently mention accessibility in Hacker News discussions, to write blog posts about accessibility best practices, etc.
They do not have any incentive whatever to help to fix bugs in screen reader programs. What would that do for them? The better such programs work, the less work there is for these people to do, the less there is to talk about on the subject of how to make your website accessible (“do nothing special, because screen readers work very well and will simply handle your website properly without you having to do anything or think about the problem at all” hardly constitutes special expertise…), the less demand there is for them on the job market…
None of this helps actual vision-impaired users, of course. It’s a classic principal-agent problem.
They do not have any incentive whatever to help to fix bugs in screen reader programs. What would that do for them? The better such programs work, the less work there is for these people to do, the less there is to talk about on the subject of how to make your website accessible (“do nothing special, because screen readers work very well and will simply handle your website properly without you having to do anything or think about the problem at all” hardly constitutes special expertise…), the less demand there is for them on the job market…
You don’t even need to describe this as a baptist-and-bootleggers problem to explain most of the lack of actual bug fixing.
A frontend developer who runs into accessibility-related browser bugs all day and gets very good at working around them and publicizing how to work around them is unlikely to be a competent C++ developer who is capable of going into browser-engine codebases and actually fixing the bugs.
If even one out of every ten accessibility advocates/experts/etc. did these things, then all these bugs would’ve been fixed years ago.
Maybe you’re aware of an OOM more accessibility advocates than I am, but I come across all sorts of well-written blog posts explaining this or that bug, which browser/etc. it happens in, and how to work around it. That’s most of the bullet points, although it might not be in the bug tracker of choice for the project.
What people aren’t doing, as far as I have seen, is starting pooled-funds bug bounties for these things. People pass the collection plate for childhood cancer, especially since I’m told that September is Childhood Cancer Awareness Month, but not bugfixing.
This is not insensible: all sorts of people tend to be unwilling to set aside the cost of a new cell phone to fix one bug apiece that, generally speaking, is encountered in one’s day job.
And there are a lot of accessibility bugs out there, some of which are quite old. I can only assume that accessibility bugs aren’t treated massively more seriously than anything else in the WebKit or Firefox Bugzillas.
While the world would be a better place if bug-bounty collection plates were more popular, I can see why they’re not as popular as I’d like.
I only know the very basics of design for screen readers so I’ll stick to talking about your first example. I agree this isn’t a case of the curb cut effect, because the curb cut effect by definition refers to an accommodation creating benefits for a broader set of people than it was originally intended for. Part of my goal was to make it clear that we can’t always expect that to happen. If an accommodation makes life worse for non-users then it’s at best what I’d call a handicapped parking effect, meaning that designers have to make a hard tradeoff. It’s also possible that the people working on your bridge just didn’t think about it or didn’t try very hard, in which case it’s not any kind of cleverly-named effect, it’s just bad design. (but I also don’t know anything about civil engineering, so I wouldn’t jump to that conclusion in any particular case.)
As for financial cost: This post was meant to be about usage patterns around the accommodations themselves, so it doesn’t go into decisions about whether to invest in any particular accommodation in the first place (except for the aside about curb cut effects increasing the total benefits). But I agree that financial cost is real and important. If someone believes that accessibility either is a fundamental moral imperative or has diffuse benefits to all of society, that should lead them to argue that it’s worth paying high costs to make things more accessible, but it shouldn’t let them get away with ignoring cost/benefit thinking entirely.
If an accommodation makes life worse for non-users then it’s at best what I’d call a handicapped parking effect, meaning that designers have to make a hard tradeoff.
Right. The thing is (and this is what I was getting at), it seems to me that disability accommodations are often argued for on the basis of the “curb cut effect” concept, but in fact such accommodations turn out to be handicapped parking effects—at best! It seems to me, in fact, that disability accommodations quite often make life tangibly worse for many more people than those whose lives they improve.
(By the way, here’s something which I find to be… interesting, let’s say. It’s often claimed that curb cut effects are ubiquitous. Yet if you ask for three examples of such things, people tend to have trouble producing them. One’s a freebie: actual curb cuts. Two, also easy, there’s the standard-issue second example: closed captions (although I am not entirely convinced that they’re strictly positive-or-neutral either, but never mind that). But what’s the third? After some straining, you might get something lame like “high contrast on websites” (what websites…?) or “accessibility features in games” (what features…?). At that point the well of examples runs dry.)
It’s also possible that the people working on your bridge just didn’t think about it or didn’t try very hard, in which case it’s not any kind of cleverly-named effect, it’s just bad design.
Sure they didn’t. Why should they? It’s not like anyone is building the thing out of a purely altruistic desire to help disabled people. Someone somewhere passed a law, someone else in another place wrote some regulations, a third person somewhere else wrote some funding proposal, a budget was approved, jobs were created, political capital was made, etc., etc.
But that’s how it almost always is. Almost nobody ever really thinks about it or tries very hard. This entire domain is absolutely jam-packed with principal-agent problems. That’s the whole problem.
From the tone of your text I feel like you’re expressing disagreement, but as far as I can tell we’re in agreement that not every accommodation is a win-win curb cut effect. I’m a lot more enthusiastic about the good outcomes of many accommodations than you are but I fervently agree that 1) sometimes there are negative tradeoffs and 2) it’s harmful and dogmatic, not to mention infuriating, when people insist that this never happens or that negative consequences to non-users are unimportant. Am I missing someplace where my post dismisses the issues you’re talking about?
Am I missing someplace where my post dismisses the issues you’re talking about?
Not explicitly, no.
I would characterize the difference in our views (as I understand your views) as having primarily to do with expectations about the distribution of outcomes w.r.t. whether any given accommodation will be positive-sum, zero-sum, or negative-sum (and the details of how the benefits and harms will be distributed).
If one believes that the distribution is skewed heavily toward positive-sum outcomes, and zero-sum or negative-sum outcomes are rare or even essentially of negligible incidence, then the emphasis and focus of your post basically makes sense; in such a case, overlooking opportunities to provide accommodations is the primary way in which we end up with less value than we might have done.
If one believes that the distribution contains a substantial component of zero-sum or negative-sum outcomes (and, especially, if one believes that there are common categories of situations wherein a negative-sum outcome may be the default), then the emphasis and focus of your post is essentially mis-aimed, and the lack of discussion of costs, of harms, etc., is a substantial oversight in any treatment of the topic.
That said, I of course agree with the basic thesis which you express in the post’s title, and which you develop in the post, i.e. that not everything is a curb cut effect and that there are different dynamics that arise from different sorts of accommodations. You can think of my top-level comment in this thread as additive, so to speak—addressing a lacuna, rather than directly challenging any specific claim in your post. (My other top-level commentdoes directly challenge some of your claims, of course. But that’s a different subtopic.)
That makes sense, thanks. I should think more about cases where design for accessibility just generally makes something worse. You could shoehorn that into the handicapped parking paradigm but it’s not really the best fit—the challenge there isn’t allocating a limited resource, though there probably is an underlying limitation in terms of budget or attention. Those are frustrating because usually you can imagine a thoughtful solution that would make everyone happy, but you can’t count on it actually working out that way.
One thing that you largely ignore in this post is the cost of creating such accommodations.
I will give a couple of examples. The first concerns a “curb cut” scenario; the second is about a “Braille signage” scenario.
Making public spaces uglier on the public’s dime
Not far from me is a highway, which has a residential neighborhood on one side of it and a waterfront promenade on the other. In several places there are pedestrian bridges that cross the highway. One of these bridges (which doubles as a ramp onto the highway, in one direction) is currently being rebuilt; the project nears completion (indeed the bridge is already usable, as the remaining work is mostly to do with railings and such), so it is now possible to see, and judge, what the completed construction will be like.
Now, prior to this project, this was a perfectly functional bridge, which was not in any way damaged, decrepit, crumbling, failing, dangerous, or even unsightly. There was nothing wrong with the bridge whatsoever—except that it wasn’t wheelchair-accessible. Hence, the rebuilding.
The new bridge is much less convenient for non-disabled pedestrians (one must walk thrice as far to get from one side to the other, due to the lengthy sloped ramps which the new design uses). It is more dangerous to pedestrians of all kinds, due to the incorporation of a bizarre roundabout in the design of the new ramp. It is much uglier and more obtrusive; it takes more of the promenade away from greenery. The bridge couldn’t be used while it was being rebuilt, of course (the project has taken considerable time, as such things do). And, of course, the rebuilding project is taxpayer-funded.
As far as I can tell, this is a case of me paying (via taxes) for my life to be made strictly worse than it was before.
Helping users who seem strangely uninterested in solving their problems
Web designers/developers routinely hear that we should make our websites accessible to users of screen readers. The specific things that must be done to accomplish this are sometimes reasonable (add
altattributes to images)… but often aren’t.For instance, I have been told that using soft hyphens as hyphenation hints is bad, because it causes screen readers to get confused and pronounce all the words incorrectly. Alright. Well, why is that my problem? If a screen reader does this, that sounds like a bug in the screen reader program. So the users of that program should talk to the developers of said program; or, if that does not help, switch to a different screen reader. (There seem to be quite a few options!)
Similarly, I’ve been told that using the
titleattribute (on links, say) is bad, because screen readers will read out the value of said attribute, which is usually undesirable. Again: why is this the web dev’s problem? Fix the screen reader, or use a better one!And yet “accessibility advocates” seem much more interested in hectoring web developers about all the myriad inconvenient, time-consuming, headache-inducing ways in which we must cater to the strange (and strangely persistent—some of these supposed limitations of screen readers have been around for decades, it seems, despite the plenitude of offerings, of which a good number are even free software licensed and can presumably be patched, forked, etc.!) peculiarities of screen readers than they are in… fixing the screen readers.
“Every web developer must remember to do all of the following long list of specific things—many of which take time and development resources, and substantively restrict your options for implementing certain features or solving certain problems—in order to support users of screen readers” is a demand for a very large number of people to contribute unpaid work (and to keep doing so, indefinitely) to solve a problem which could be solved much more easily (with a solution that needs to be implemented just once) by a much smaller number of precisely the people who are making the demand.
This is clearly a negative-sum solution.
I haven’t worked on front end for over a decade, so I am not familiar with recent development, but from the days I did, I remember adding the alt tag to images, but I never heard anything about soft hyphens.
Could it possibly be that the good and bad advice does not come from the same sources? And that we should listen to some sources and ignore the others? I can imagine that a set of advice that was reasonable at the beginning can grow through the game of telephone.
(Something similar happened with SEO advice, which started with “if you use keywords in the URL, Google will prioritize your page for the keyword, so use the page title in the URL rather than id=123”, and quickly mutated to “if you use id=123 in your URL, Google will refuse to index your page” that was obvious nonsense, but you could find it in 99% of articles about SEO. Or all that stuff “required by” GDPR.)
For example, page Accessibility Principles on W3C homepage does not mention hyphens.
No, the lack of screen reader support for soft hyphens is a real thing, with actual user complaints behind it. Besides, that guidelines page doesn’t mention
titleattributes either; those are only very general guidelines, lacking details.As far as ignoring some advice—sure. I ignore all of it, personally.
Even googling for “accessibility soft hyphen” did not return much. The #1 result on my computer says: “Well, screen readers mispronounce a lot of the words in a document or on a website. Should we just eliminate words entirely to prevent the problem? … The answer: It’s the responsibility of screen reader manufacturers to do a better job of recognizing and pronouncing hyphenated words.”
So it is does not seem like a frequent advice / complaint.
Come now; you can do better than that.
A search for
screen reader "soft hyphen"easily finds this:https://github.com/nvaccess/nvda/issues/9343
A search for
"screen reader" "soft hyphen"easily finds these:https://www.reddit.com/r/accessibility/comments/lku7kq/comment/go5kkwy/
https://lists.apache.org/thread/8bjr2lxhy3jj4vqrqzdp98hlndbt3sol
https://github.com/e2b/wordpress-hyphenator
The last link goes to a page that says:
The Reddit link goes to a post that has 1 karma, where 1 user suggests to remove the soft hyphens, 1 user disagrees… and that’s all.
In the Github debate, most people seem to agree that it is a bug of screen readers.
Only in the Apache link, someone recommends to do something about the hyphens. Even there, it seems to happen in context of discussing FOP, which is a PDF file generator. So as I understand it, it is not about “every web developer should adapt to the bugs of screen readers” but rather “authors of a PDF generator have an opportunity to compensate for the bugs of screen readers by automatically adding some PDF equivalent of ‘alt text’ containing the unhyphenated version of the word”. It still means compensating for someone else’s bug, but it’s a hack you only need to do once.
I think you have misunderstood my claims and my point.
The links I have posted were to demonstrate the fact that screen readers having a problem with soft hyphens is a real thing that really happens. (You seemed to be skeptical of this.)
That developers are sometimes told to not use soft hyphens, on account of this issue, is something for which I have and need no links, because, as I said initially, this is something which I, personally, have been told, by self-described accessibility advocates and/or disabled users, in discussions of actual websites which I have worked on. (You could disbelieve me on this, I suppose…)
And whether this specific advice/request/demand happens often is inconsequential. It is one example of a class of such things, which collectively one ends up hearing quite a bit, if one does serious web development work these days. The
titleattribute example was another. I could also have mentioned the deeply confusing and bizarre ARIA attributes.Again: any specific such issue comes up only occasionally. But if I were to try to build a website such that screen readers have no problems with it, I would have to deal with many such issues—most of which could be fixed much more easily by the developers of the screen reader software… but aren’t. And the attitude of most accessibility advocates I’ve encountered has been that I should indeed take that (“build a website such that screen readers have no problems with it”) as my goal.
Achmiz is a bit salty because the issue came up occasionally with Gwern.net and other sites, and it’s striking that it came up at all because generally, even if there is a severe problem with a website, “they will never tell you”. If you never ran into it, that might have as much to do with you not bothering with justification or typographic niceties like fixing linebreaks with manual soft hyphen use.
I once spent nearly a month working on accessibility bugs at my last job and therefore found the screen reader part of this comment incredibly insightful and somewhat cathartic.
I don’t think this is unrelated to the “Deaf” community’s “hearing aids/cochlear implants are genocide” position. I suspect getting other people to submit to their arbitrary whims is the point, and the “problems” are in fact the means to that end.
I would guess it’s because the Americans with Disabilities Act provides a private right of action against businesses whose websites are not accessible to people with disabilities, but doesn’t say anything about screen reader software bugs.
That’s basically agreement with my “getting other people to submit to their arbitrary whims,” isn’t it?
I would guess most of them just want their screen readers to work, but a badly written law assigns the responsibility for fixing it to the wrong party, probably due to excessive faith in Coase’s theorem.
Yes, that may be part of it. I suspect, however, that in this case it is a slightly different (though somewhat related) dynamic that’s mostly responsible.
“Accessibility advocate” is qualification which leads naturally to “accessibility expert”; and there is a certain amount of demand for such people (e.g., as consultants on projects which are required by regulations to be “accessible”, or which otherwise benefit from being able to claim to be “accessible”). Such people have an incentive to establish their credentials and their credibility by talking about what web developers must do in order to make their websites accessible, to frequently mention accessibility in Hacker News discussions, to write blog posts about accessibility best practices, etc.
They do not have any incentive whatever to help to fix bugs in screen reader programs. What would that do for them? The better such programs work, the less work there is for these people to do, the less there is to talk about on the subject of how to make your website accessible (“do nothing special, because screen readers work very well and will simply handle your website properly without you having to do anything or think about the problem at all” hardly constitutes special expertise…), the less demand there is for them on the job market…
None of this helps actual vision-impaired users, of course. It’s a classic principal-agent problem.
You don’t even need to describe this as a baptist-and-bootleggers problem to explain most of the lack of actual bug fixing.
A frontend developer who runs into accessibility-related browser bugs all day and gets very good at working around them and publicizing how to work around them is unlikely to be a competent C++ developer who is capable of going into browser-engine codebases and actually fixing the bugs.
Uh-huh, and what about the people who aren’t front-end developers, either, but only “advocates”, “experts” (but not the kind that write code), etc.?
To help with projects like “an open-source screen reader”, it is not necessary to be able to write C++ (or whatever) code. You can also:
file well-written and well-documented bug reports, including testing with various setups, detailed replication steps, etc.
survey alternate software options, cataloguing which of them correctly handle the relevant test cases, and how
find people who do have the relevant expertise and may be willing to contribute code, and connect them with the maintainers
contribute funding to the project and/or help to convince other people to contribute funding
other (i.e., “reach out to the maintainer(s) to ask them what would help get the bug fixed, then do that”)
If even one out of every ten accessibility advocates/experts/etc. did these things, then all these bugs would’ve been fixed years ago.
Maybe you’re aware of an OOM more accessibility advocates than I am, but I come across all sorts of well-written blog posts explaining this or that bug, which browser/etc. it happens in, and how to work around it. That’s most of the bullet points, although it might not be in the bug tracker of choice for the project.
What people aren’t doing, as far as I have seen, is starting pooled-funds bug bounties for these things. People pass the collection plate for childhood cancer, especially since I’m told that September is Childhood Cancer Awareness Month, but not bugfixing.
This is not insensible: all sorts of people tend to be unwilling to set aside the cost of a new cell phone to fix one bug apiece that, generally speaking, is encountered in one’s day job.
And there are a lot of accessibility bugs out there, some of which are quite old. I can only assume that accessibility bugs aren’t treated massively more seriously than anything else in the WebKit or Firefox Bugzillas.
While the world would be a better place if bug-bounty collection plates were more popular, I can see why they’re not as popular as I’d like.
I only know the very basics of design for screen readers so I’ll stick to talking about your first example. I agree this isn’t a case of the curb cut effect, because the curb cut effect by definition refers to an accommodation creating benefits for a broader set of people than it was originally intended for. Part of my goal was to make it clear that we can’t always expect that to happen. If an accommodation makes life worse for non-users then it’s at best what I’d call a handicapped parking effect, meaning that designers have to make a hard tradeoff. It’s also possible that the people working on your bridge just didn’t think about it or didn’t try very hard, in which case it’s not any kind of cleverly-named effect, it’s just bad design. (but I also don’t know anything about civil engineering, so I wouldn’t jump to that conclusion in any particular case.)
As for financial cost: This post was meant to be about usage patterns around the accommodations themselves, so it doesn’t go into decisions about whether to invest in any particular accommodation in the first place (except for the aside about curb cut effects increasing the total benefits). But I agree that financial cost is real and important. If someone believes that accessibility either is a fundamental moral imperative or has diffuse benefits to all of society, that should lead them to argue that it’s worth paying high costs to make things more accessible, but it shouldn’t let them get away with ignoring cost/benefit thinking entirely.
Right. The thing is (and this is what I was getting at), it seems to me that disability accommodations are often argued for on the basis of the “curb cut effect” concept, but in fact such accommodations turn out to be handicapped parking effects—at best! It seems to me, in fact, that disability accommodations quite often make life tangibly worse for many more people than those whose lives they improve.
(By the way, here’s something which I find to be… interesting, let’s say. It’s often claimed that curb cut effects are ubiquitous. Yet if you ask for three examples of such things, people tend to have trouble producing them. One’s a freebie: actual curb cuts. Two, also easy, there’s the standard-issue second example: closed captions (although I am not entirely convinced that they’re strictly positive-or-neutral either, but never mind that). But what’s the third? After some straining, you might get something lame like “high contrast on websites” (what websites…?) or “accessibility features in games” (what features…?). At that point the well of examples runs dry.)
Sure they didn’t. Why should they? It’s not like anyone is building the thing out of a purely altruistic desire to help disabled people. Someone somewhere passed a law, someone else in another place wrote some regulations, a third person somewhere else wrote some funding proposal, a budget was approved, jobs were created, political capital was made, etc., etc.
But that’s how it almost always is. Almost nobody ever really thinks about it or tries very hard. This entire domain is absolutely jam-packed with principal-agent problems. That’s the whole problem.
From the tone of your text I feel like you’re expressing disagreement, but as far as I can tell we’re in agreement that not every accommodation is a win-win curb cut effect. I’m a lot more enthusiastic about the good outcomes of many accommodations than you are but I fervently agree that 1) sometimes there are negative tradeoffs and 2) it’s harmful and dogmatic, not to mention infuriating, when people insist that this never happens or that negative consequences to non-users are unimportant. Am I missing someplace where my post dismisses the issues you’re talking about?
Not explicitly, no.
I would characterize the difference in our views (as I understand your views) as having primarily to do with expectations about the distribution of outcomes w.r.t. whether any given accommodation will be positive-sum, zero-sum, or negative-sum (and the details of how the benefits and harms will be distributed).
If one believes that the distribution is skewed heavily toward positive-sum outcomes, and zero-sum or negative-sum outcomes are rare or even essentially of negligible incidence, then the emphasis and focus of your post basically makes sense; in such a case, overlooking opportunities to provide accommodations is the primary way in which we end up with less value than we might have done.
If one believes that the distribution contains a substantial component of zero-sum or negative-sum outcomes (and, especially, if one believes that there are common categories of situations wherein a negative-sum outcome may be the default), then the emphasis and focus of your post is essentially mis-aimed, and the lack of discussion of costs, of harms, etc., is a substantial oversight in any treatment of the topic.
That said, I of course agree with the basic thesis which you express in the post’s title, and which you develop in the post, i.e. that not everything is a curb cut effect and that there are different dynamics that arise from different sorts of accommodations. You can think of my top-level comment in this thread as additive, so to speak—addressing a lacuna, rather than directly challenging any specific claim in your post. (My other top-level comment does directly challenge some of your claims, of course. But that’s a different subtopic.)
That makes sense, thanks. I should think more about cases where design for accessibility just generally makes something worse. You could shoehorn that into the handicapped parking paradigm but it’s not really the best fit—the challenge there isn’t allocating a limited resource, though there probably is an underlying limitation in terms of budget or attention. Those are frustrating because usually you can imagine a thoughtful solution that would make everyone happy, but you can’t count on it actually working out that way.