Hacker News Reader

As a blind person, I think that accessibility matters most in situations where there's little competition and/or high switching costs.

A startup building a new email client shouldn't be required to implement accessibility, certainly not from the start. There are enough accessible solutions in that space, and while accessibility would be nice, it would make the barriers of entry much higher.

On the other hand, Facebook, a company famous for prosecuting app developers for (mis)using their API, should absolutely be required to do so. If all your friends are on Facebook, you're not even allowed to build a more accessible Facebook client.

I also believe that we should legalize 3rd party apps if the original app is inaccessible, regardless of the TOS or presence of DRM.

I believe that we should legalize 3rd party apps full stop. The legal system should never be possible to use to enforce lack of interoperability.

FWIW, I'm very sure third-party apps are already legal (and have always been legal): the issue was never that you aren't legally allowed to make them, it is merely that, once you do, the company making the product goes out of their way to break your client or ban your accounts; so, what you'd really need to do is to make it actively illegal for a company to prevent you from making a third-party app... even by any such technical means that they will absolutely defend as some form of "spam prevention" or "security mitigation" or "content restriction".

What I mean is get rid of any way that the legal system can be used to prevent third-party apps. TOSs, CFAA, DMCA, contracts, etc. should all be null-and-void when used to prevent interoperable third-party apps.

Companies with large market share should also be actively required to facilitate interoperability, e.g. with APIs available on FRAND terms.

You would also need to mandate that they supply a reason for banning you that you can argue against. As it is now you could just get banned with no recourse or reason for using a 3rd party app on many platforms.

I am very confident the DMCA already doesn't apply even if this were a copyright issue (which I don't think it is) due to interop exemptions, terms of service generally aren't legal issues in the first place, and the CFAA doesn't apply as there is case law that this is not "access". I maintain: there already is nothing stopping you from making a third party client except 1) how people keep making the stupid mistake of violating trademark law in their third party client (which is trivially avoided) and 2) the legal right of the service to refuse service to anyone... you need to make that actively illegal, and then defend that that makes sense against the onslaught of arguments that they need to be able to ban people due to spam prevention, security mitigation, and content restriction (and the EFF coming out of nowhere with some kind of argument that this is going to undermine the right of free speech of the company due to similar arguments as to Section 230, etc).

Also, making webpages inaccessible usually takes work. Reasonable use of semantic HTML, styling, and alt tags for images are probably good enough. It's when you start doing ridiculous things with SPA frameworks (something no asked for or wants) that this gets hard.

SPA frameworks don’t make accessibility any harder.

I disagree. Even if an SPA framework (or more likely a library add-on) does a good job of reinventing the wheels of traditional HTML requests (e.g. announcing the name of the new "page" when it loads and setting focus), there are always going to be more details that will be at least a little harder to implement on each site.

I'm not fundamentally opposed to JavaScript frameworks, even when used to make SPAs. I think their downsides can be worth using them anyway and issues like accessibility can be overcome. They are a paradigm that are chosen too often without enough thought about the downsides and are a bad choice as default.

The art of standard serverside generated HTML and progressive enhancement or a page composed of JavaScript apps/widgets for interactive elements seems lost today. In the age of React everything is a SPA first by design from observations.

Having previously worked and taking a great interest in the schematic web last decade, progressive enhancement, accessibility, page size, etc etc the modern web is disappointing when what should be a simple HTML website instead be a blank white screen while it downloads 2mb+ of assets then a SPA bootstrap to show something loading json blobs embedded in the page and leaking information with the insistence of doing everything client side.

> I see some people are feeling conflicted trying to balance 1) Making the web more accessible with 2) Increasing business/startup costs.

Doesn't the ADA already have some exemption for startup/small businesses where it doesn't apply if you have less than X employees?

Less than 15

https://www.searchenginejournal.com/website-accessibility-la...

Ah yeah it does say that here: https://www.eeoc.gov/laws/guidance/ada-primer-small-business

Good to know

It appears that the exemption noted by others for businesses with fewer than 15 employees only relates to the obligation to accommodate employees, not customers. [1]

For example, one of the links provided elsewhere is to an EEOC website. The EEOC is the Equal Employment Opportunity Commission, which only relates to employment, not to accommodating customers.

1: https://www.accessibility.com/blog/do-small-businesses-with-...

Even if the ADA does have carve outs, if a small business wants to do business with any government/public entity they most likely will have to meet some level of accessibility. A VPAT[1] is commonly asked for in these cases.

[1] https://en.wikipedia.org/wiki/Voluntary_Product_Accessibilit...

Basic accessibility is nearly 'free' if someone uses modern web standards, and runs a tool to check during development. Things like alt tags, proper html tag usage, keyboard navigation (logical and without traps), and good contrast are good programming/design and good for every user.

Totally. Especially if you design correctly from the start. Adding accessibility to a site/app/etc that was designed for years without it in mind is a pain in the ASS, but doing it from the start is simple.

The contrast issues sometimes make design a bit harder, but it's totally worth it I believe.

I agree that following web standards gets you a lot in terms of accessibility and is a part of good programming and design.

There's a lot that automated checkers don't find. They can detect if an image lacks an alt attribute, they can't tell if an alt attribute's value is bad. Many are pretty good at at least flagging where there might be a color contrast problem for a human to double-check. They don't automatically find interactive components that aren't keyboard navigable or operable. They don't know when the DOM order of content doesn't make sense.

Sure, no tool is perfect.

For me though, making sure keyboard navigation works properly early on speeds up the develop and test cycle. I also think that in many cases, perfect ends up the enemy of the good. It's a different conversation if a disabled person contacts someone about a site with a suggestion for improvement rather than it doesn't work at a all.

For the web, screen readers are easy, the only thing I find problematic are some of the color contrast requirements. There have been several instances where we've had to make designs definitively worse in order to accomodate those.

I somewhat question the need, as well—at some of the contrast levels we're talking about, if your vision is that bad, you should really consider enabling a magnifier, color filter, or even a screen reader.

What becomes really problematic, however, are PDFs, which are supposed to be a quick way to offer printed documents digitally, without too much extra work. Making those work with screen readers can take a long time, and there have been some cases where clients decided to just remove them from their websites. I'm not sure what to do about that, but I'm concerned we're creating barriers to sharing information, with anybody.

I don't think that's a solution; sure, making the site more accessible makes you reach more users even beyond the "disability" angle, but that doesn't make it a winning cost-benefit tradeoff immediately if ever.

EDIT: By analogy, it's very like software portability. If you make your software support Windows and MacOS and assorted Linux distros and the major BSDs and Haiku, you'll get more users. But if you only target Windows you'll get 80% of the market, and Windows+MacOS will get you 90%, and after that you really need to think about whether it's a good investment to target more platforms. By all means, be accessible because it's the right thing to do or legally required, but it's not obvious that it's a sound business move.

I agree it's still not going to win the cost-benefit tradeoff in most markets. OTOH - I imagine making your software support more OSs is much more expensive than designing your website to be more accessible, at most $1M/year. If you've got billions in annual revenue that's pennies in the bucket.

In my view, it's about trying to provide more 'equal opportunity' in this world where it's financially feasible. This seems like a case where it is more often that not. Again, for medium+ businesses.

The reason the ADA exists is that it's almost never a profitable cost-benefit tradeoff to accommodate people with disabilities.

But I'd much rather work at a company that was 1% less profitable or live in a society that was 1% less wealthy and accommodated people with disabilities than one that left them in the gutter.

Well, it’s easy to comply with ADA cheaply if you do it right the first time but a pain in the ass to retrofit things later.

At least with webdev the problem is most people stumble into it and are not formally taught much about webdev specifically if at all. My undergrad never taught me a single thing about webdev practice. It’s not like, say, architecture, where you not complying with accessibility regulations will be taught formally, or later when you actually implement it some code compliance inspector is going to deny you a permit to build. It really is the wild west in webdev still.

I was specifically responding to a comment that said accessibility wasn't expensive because it lets you reach more people (or at least that was my reading of it). Yes, by all means be accessible because it's the right thing to do - I object only to the idea that we should do it because it makes sense from a pure money perspective. It's a good thing, that's just not the reason.