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.

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.

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.

This is clearly a negative-sum solution.

That doesn’t mean it’s zero-sum: The existence of a handicapped parking spot that I can’t use might cost me an extra 20 seconds of walking, but save an extra five minutes of painful limping for the person who uses it.

This does not demonstrate that handicapped parking spots aren’t zero-sum (or, indeed, even that they’re not negative-sum). Merely comparing the advantage to one handicapped person of parking in a reserved spot, and the disadvantage to one non-handicapped person of having one less spot (in an optimal location) available, is not enough; you must multiply both quantities by the number of instances affected (respectively, the number of occasions on which a handicapped person uses one of the reserved spots, and the number of occasions on which a non-handicapped person uses one of the regular spots), and compare those quantities.

It is very, very easy for an accommodation like this to end up being negative-sum.

Or for past me, on a couple of occasions when I’ve been injured

To be able to use a handicapped parking space, it is not sufficient to be injured; one must also apply for a handicapped parking permit, which is not a trivial process.

I have, several times in the past, been injured in such a way that I would have benefited from being able to use a handicapped parking spot. On zero of those occasions was it even remotely practical to apply for, and receive, a permit that would enable me to do so. Because of this, while handicapped parking spaces could have helped me on a number of occasions, they have actually helped me never.

Zulip, Discord and Slack are all options as well

However, these are all very bad for searchability, archiving, multimedia content, and creation of permanent content of any sort.

In-general, bot issues are one of the top reasons for websites that accept user submissions either need to have a strict manual review phase, or be continuously updated with defenses.

Indeed. And what you’ll generally find is that mature, widely-used platforms tend to have many and varied tools for dealing with this sort of thing, whereas if you build custom software, you end up having to handle many more edge cases, attack types, etc., than you’d expected (because it’s very hard to think of all such possibilities in advance), and the project just balloons massively due to this.

(For example, Simple Machines Forum—which runs Data Secrets Lox, and which I, on the whole, do not recommend—has all sorts of options for gating user registration behind verification emails / manual moderator approval / captcha / verification questions / etc.; it has moderation tools, including settings that let you enforce per-post approval, on a per-subforum basis; it has a karma system; it has built-in GDPR compliance features; and all of this before you consider all the optional modifications that are available… and SMF is not even one of the better platforms in this category! How much development work would it take a small team to get a discussion forum platform to this state? How much work would it take even to just build the core functionality plus the moderation/security/anti-spam tools…?)

I don’t agree with most of this.

I agree with this part:

I would advise against setting up the software for yourself (unless this is the type of thing you also do for a job)

Yes, if you are not a “tech person” / programmer / engineer of some sort / otherwise have experience with software, you should not set this sort of thing up yourself. You should find/hire someone to do it for you. That is not difficult.

I disagree with the rest of what you say.

Choosing a free solution that is well-maintained is better than rolling your own. A standardized solution plus standardized exploits plus standardized mitigations to those exploits is better than a custom solution.

Basically, remember the situation when one person practically took down Less Wrong, and it had to be reprogrammed from scratch, because updating the original Reddit codebase would be too much work? Similar thing can happen when you use a free solution, and defending against it can turn out to be too much work.

First of all, as I recall, that wasn’t an “exploit” in the usual “software vulnerability” sense. Perhaps someone from the LW team who was around back then can better describe the details, but as I understand it, it was a design flaw in the “if someone does this bad thing, we have no good tools to catch them and/or prevent someone from doing it” sense. There is no reason whatsoever why a custom solution can’t have arbitrarily many such design flaws, and such an “exploit” in no way relies on having access to the source code or… anything like that.

And—again, to my recollection—old Less Wrong was never “hacked”.

But more importantly, the reason why any of this was a problem at all is that old LW used the old Reddit codebase—that is, one which had been deprecated and was no longer maintained. Indeed, it is a bad idea to choose such a platform, if you do not have a dedicated engineer to service it! This is why you should choose something popular and well-maintained.

For example, I linked MyBB in my earlier comment. It is updated regularly, and the developers clearly take security very seriously. I don’t know how much money you’d have to spend to get this degree of protection in a custom solution, but it sure ain’t a small number.

When you speak of standardized exploits to standardized solutions, I expect that you have Wordpress in mind, which is infamous for its exploitability (although I am unsure to what extent that reputation is still accurate; it may be an outdated characterization). But most web forums (which, note, Wordpress is not) get hacked approximately never. Ones based on well-designed, well-maintained, popular software like MyBB, even less so.

I also disagree with the advice to “use some cheap and simple solution that can (and will) be thrown away later”. In my experience, such platform choices tend to be quite “sticky”, and migration is often painful, expensive, and time-consuming. That is not to say that you should never migrate to a custom solution (although I am very skeptical about OP’s use case requiring anything more advanced than a good PHP bulletin board)… but even if you expect that you’ll want to migrate, it is far better to migrate from a basically working site which merely lacks some features you want, or has some annoying limitations, etc., than to migrate from a site which has broken or been hacked or otherwise exploded.

The fact is that a decent PHP-bulletin-board-type platform already is “a cheap and simple solution”. (Which can, of course, be thrown away later, but doesn’t have to be.) Trying to go even cheaper is setting yourself up for pain later on.

That’s true, but I’m not aware of one that does this combo and is good (uses a good forum software, is reliable, etc.). Are you?

Re-construction of Pathfinder game mechanics in setting

(Done poorly)