Comment by hiAndrewQuinn

Comment by hiAndrewQuinn 16 hours ago

7 replies

These are great and humanistic sentiments, until you have to talk price. When price comes into the equation, the approach of specialized accessibility software seems to work much better in a lot of cases.

Consider a rosy hypothetical: A SaaS under truly great, enlightened leadership. The team lead knows that it would take only one two week sprint, for one focused developer, to go the last mile and make it truly accessible for all. The fully loaded cost of those developer-hours, in a very optimistic scenario, is $1000, and optically closer to $4-8000 for a US based team.

First, do those extra steps towards accessibility even break even? Second, if so, are they truly the revenue maximizing move for what that dev can do with that 2-week sprint? Sometimes, rarely, they are. In practice I suspect market research would show the opposite. This is before we add in all of the usual fog of war around how long things really take to build, whether the leadership is really as enlightened as they seem, etc.

Consider an alternative model where one company specializes in creating high quality accessibility-enhancing software. This software aims to work as a compatibility layer across most to all of the other programs a user is likely to use; perhaps they use frequent in-memory screenshots and detailed image analysis to help blind users understand what's going on. Or perhaps it's as simple as a FOSS dev focusing on making sure every terminal program they can run works well with their screen reader.

There are a plethora of benefits to this model, not least that you aren't imposing a heavy tax on everyone else for a really small customer base. This is also very specialized, customer-facing work. If there is anywhere in software you would want dedicated frontend or UI/UX expertise it would probably be the guy designing the screen reader compatibility layer.

I point to the popular extension Dark Reader as an example of this paradigm; it does a wonderful job on most websites, is easy to disable on websites where it doesn't, and doesn't cost the website runner anything to use.

Some might take issue with this for aesthetic reasons. It feels kludgy to suggest someone run a whole third interface layer just to use the same software you and I use right out of the box. I think this aesthetic violation is misplaced in this case - the factors at play suggest to me that this work would benefit heavily from specialization. Indeed, that seems to be what has happened in practice; making the web accessible in 2025 is much easier than it was in 2000, because third parties have stepped up and improved the situation dramatically enough that hooking into accessibility layers "merely" requires things like writing semantically correct HTML.

Now imagine if a Dark Reader existed, that could reliably insert all the finer details into the page which are obvious from a screen grab of the page, but non-obvious to the web designer - that would clearly be a much better approach for the majority of businesses.

ChrisMarshallNY 15 hours ago

In my experience, developing the habit of writing accessible software, substantially reduces the friction (and cost) involved in adding it.

Definitely, the most expensive way to add accessibility, is to retrofit it.

  • hiAndrewQuinn 15 hours ago

    My hypothetical assumes that the team was writing 95% accessible software already. The last 2 weeks are for the final push.

    Of course, if this is a truly all-or-nothing thing where you need to do it 100% perfectly to incur no extra cost, then that strengthens my argument for the compatibility layer, it doesn't diminish it. Very few non-specialists can get something 100% right on the first shot.

    • ChrisMarshallNY 15 hours ago

      Fair enough.

      > Very few non-specialists can get something 100% right on the first shot.

      But that certainly doesn’t stop managers from assuming 100%, first shot.

      In my experience, a realistic plan can save huge amounts of cost; in far more areas than just accessibility.

      Also in my experience: realistic plans are unicorns.

askew 15 hours ago

Is that extra development cheaper than the risk of a lawsuit or loss of reputation? Not forgetting the ~20% of potential customers you might be missing out on…

> not least that you aren't imposing a heavy tax on everyone else for a really small customer base.

Ah. Seeing your disabled customers as a burden. One day you might encounter barriers when it comes to computing.

  • hiAndrewQuinn 15 hours ago

    >Is that extra development cheaper than the risk of a lawsuit

    It probably isn't cheaper, no. The base risk of a lawsuit in this domain seems very low for all but the largest of websites; the largest of websites generally have large enough user pools that investing in out of the box accessibility makes sense anyway. In fact I would wager Facebook makes more advertising money off of its median blind user than its median fully-sighted user, simply because that's a very easy demographic to target ads to.

    I'm willing to change my mind on this if you can provide evidence if even, say, 1% of all inaccessible websites on the Internet have been sued on these grounds.

    >Seeing your disabled customers as a burden

    Disabled potential customers, for one. Disabled people aren't dumb, and they don't pay for things they can't actually use. I'm surprised you assume they would.

    But, and and this may come as a surprise, I genuinely think the compatibility layer approach is the much better option here. There are plenty of reasons to think so, which I outlined in the original post. Your slander is not welcome or acceptable just because you disagree with me.

hombre_fatal 14 hours ago

Yeah, it's like RSS: a solution that requires every single operator to implement something you need is quite a bad solution. For you who needs it and for every operator who has to implement it.

Instead, it's superior if you didn't need RSS at all to generate and consume feeds of website because your software did it for you.

Same for screen readers and accessibility. The superior solution is for software to derive the UX just like a sighted person can.

It will be nice when we get the tech for this so that accessibility convos don't just get stuck in these weird shaming rituals where you're supposed to feel guilty that you never tried your website with macOS VoiceOver when you're not even sure if your business will exist in a year.