What is the real liability for a scenario like this? Is there any grace period when a new app or startup becomes far more successful far sooner than expected? I imagine A11Y isn't a massive concern when it's not certain an idea will even work; outside of California I can't imagine being legally skewered if, once you attain unexpected success, you devote A11Y resources to address this issue.
I work for an information service that sells subscriptions to academic and other users.
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
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.
You're liable under the ADA everywhere in the US. Florida and New York are the big federal courts where people bring these cases. If it's found that you have created a barrier to accessing services, you can be sued.
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).
> What is the real liability for a scenario like this?
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.
It’s generally less of a legal liability and more of a reputation thing; as you grow you will get more and more users telling you off. See Wordle for an easy example.
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
While it's generally a good idea to make your app/site accessible to all users and user agents - the trouble usually comes when you're big enough to get sued.
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.
I don't recall the specifics - but I think the settlement usually included language around remediation or dismissal was pending remediation.
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.
> 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
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.
You should invest as much into accessibility as you do into scaling.
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?
"Premature optimization" is definitely a thing in scaling but not so much in accessibility. I suppose having a native feature to let users choose from a wide array of fonts and color schemes (vs. honoring OS settings for those) before you have users could be accessibility-related premature optimization.
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).
I follow this as part of my role and the number of lawsuits has been increasing steadily over the years. Last year was 4,600 (for websites/apps) in the US. So might not feel a lot but of course the bigger your app is the bigger the target.
'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?
Not a lawyer, but helped addressed these concerns on the dev side at a previous large company.
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.
I've worked for a couple of large corporations who were sued for accessibility issues.
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.
This. The problem isn't accessibility or the ADA. The problem is the US tort system and the way it is abused.
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".
In the long run, everybody is disabled. My eyesight is way worse than it used to be, as an example, and it's beginning to affect my ability to computer. Absent some miracle treatment (which is bound to cost an arm and a leg and NOT be covered by insurance anyway), it's not going to get any better.
You’re being downvoted but this is true - most accessibility work seems to be generated by the accessibility industry, and is focused on short term fixes (modifying every website) rather than long-term solutions (fixing web browsers for disabled people).
Are web browsers not accessible by default? If you make everything out of the core primitives they provide: lists, paragraphs, buttons, forms, etc, a screen reader will have no problem, and reader mode can let the user tweak it. It's only when people reconstruct primitives that assistive technology breaks. I don't see how you can fix that at the browser level except by taking away all the toys and breaking 99% of the web.
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.
Browser modifications to detect and modify things like font size, selection and contrast, designs transformed into modified versions suitable for different disabilities using ML. Things that actually scale versus asking every website to modify their code for every disability, which will never happen.
