In addition to the ambiguity of the requirements, the difference in the regulatory culture between the US and the European Union is vast. I truly cannot stress how different they are, and that's an important thing to know because it can be easy to become fluent in one and assume the other is largely the same. It's not.
In this article, I’m going to use "regulations" and other derivations of the word to mean "all those things that carry the weight of law," be they laws, rules, directives, court orders, or what have you. I will explain why developers need to know about regulations, and then illustrate the fundamental differences between the US and European regulatory frameworks by comparing their approaches to accessibility.
Note: This is not legal advice.
None of the following is intended to be legal advice. The author is not a lawyer — has not even read that many John Grisham novels — and is providing this as background information for your use. If you have actual questions, take them to an actual lawyer. (Or you can try calling John Grisham, but I doubt he'd pick up.)
Why Should Developers Care About Regulations?
It seems like it should be really easy to figure this out — after all, shouldn't the client be aware of what laws pertain to their industry? Yes, they should, but they aren't always, and there are lots of regulations that specifically cover technology and/or internet-capable software that domain experts likely would not (and should not) be expected to be on top of.
In a consultancy context, hopefully both you and the client have excellent legal representation. Also hopefully, those lawyers are not spending their days watching you code. That's not going to be fun for them (or you).
You should absolutely use lawyers as a resource when you have questions or aren't sure if something would be covered under a specific law. But you have to know when to ask those questions, and possess enough knowledge when your application could be running afoul of some rule or another.
The most helpful thing a lawyer ever told me was, “If you’re ever in doubt, assume you’re going to get sued over it. Sooner, rather than later.” Knowing the troublesome spots ahead of time, getting your ducks in a row and documenting everything are the best ways to make sure you’re ready for any legal scenario.
It's also worthwhile to your career to know these things! Lots of developers don't, and your ability to point them out and know about them will make you more valuable (because you are!). It also will make you more competent and capable than another developer who does not — again, because you are! This stuff is a skillset just like knowing Django.
United States Regulations
The US tends, for the most part, to be a reactionary regulator. Something bad happens, laws or rules (eventually) get written to stop that thing from happening again.
Also, the interpretations of those rules tend to fluctuate more than in the EU, depending on which political party is in power (and controlling the executive branch, specifically) or what jurisdiction a lawsuit is filed in. I will not go in-depth into those topics, for they are thorny and leave scars, but it's important to note. The US also tends to give wide latitude to the defense of, "but it's our business model!" The government will not give a full pass on everything, but they tend to phrase things in terms of "making fixes" rather than "don't do that."
Because US regulations tend to be written in response to a specific incident or set of incidents, they tend for the most part to be very narrowly tailored. This leaves lots of room for unintended consequences or simply failing to achieve the stated goals. In 2003, Congress passed the CAN-SPAM Act to "protect consumers and businesses from unwanted [email]." As anyone whoever looks at their spam box can attest, CAN-SPAM's acronym unfortunately seems to have meant "can" as in "grant permission," not "can" as in "get rid of."
European Union Regulations
In contrast, the EU tends to issue legislation prescriptively; that is, they identify a general area of concern, and then issue rules about both what you can and cannot do, typically founded in some fundamental right.
This technically is what the US does on a more circumspect level, but the difference is the right is the foundational aspect in the EU, meaning it's much more difficult to slip through a loophole.
From a very general perspective, this leads to EU regulations being more restrictive in what you can and can't do, and the EU is far more willing to punish punitively those companies who run afoul of the law.
For example of the contrast, let's take a look at one of the few areas where both territories are (finally) in agreement: accessibility.
Accessibility
In both the US and the EU, the general standard for digital accessibility is WCAG 2.1, level AA. If your website or app does not meet (most) of that standard, and you are sued, you will be found to be out of compliance.
In the US, the reason you need to be compliant comes from a variety of places. The federal government (and state governments) need to be compliant because of the Rehabilitation Act of 1974, section 508. Entities that receive federal money (including SNAP and NSF grants) need to be compliant because of the RA of 1974, section 504. All other publicly accessible organizations (companies, etc.) need to have their websites compliant because of the Americans with Disabilities Act and various updates. And all of the above has only arisen through dozens of court cases as they wound their way through the system, often reversing each other or finding different outcomes with essentially the same facts. And even then, penalties for violating the act are quite rare, with the typical cost being (a) the cost of litigation, and (b) the cost of remediation and compliance (neither of which are small, but they're also not punitive, either).
In the EU, the Web Accessibility Directive says that access to digital information is a right that all persons, including those with disabilities, should have, so everything has to be accessible.
See the difference?
So for accessibility, there's a long list of standards developers should be meeting. Some of the more important ones that are most frequently not followed are:
Provide text alternatives for all non-text content: This means alt text for images, audio descriptions for video, and explainer text for data/tables/etc. You also need to pay attention to the quality — the purpose of the text is to provide a replacement for when the non-text content can't be viewed, so "picture of a hat" is probably not an actual alternative.
Keyboard control/navigation: Your site should be navigable with a keyboard, and all interactions (think slideshows, videos) should be controllable by a keyboard.
Color contrast: Header text should have a contrast ratio of 3:1 between the foreground and background; smaller text should have a ratio of 4.5:1.
Don't rely on color for differentiation: You cannot rely solely on color to differentiate between objects or types of objects. (Think section colors for a newspaper website: You can't just have all your sports links be red, it has to be indicated some other way.)
Resizability: Text should be able to be resized up to 200% larger without loss of content or functionality.
Images of text: Don't use them.
Give the user control: Videos or audio can autoplay if they must, but users must have the ability to stop or pause it.
There are many more, but these are the low-hanging fruit that lots of applications still can't manage to handle properly.
Software should aspire to be as widely accessible as possible, but the incentives don’t always lead to that outcome. The nature of our different regulatory environments can easily confuse teams, but learning more about the laws and regulations that impact your product will make you a better developer who can make a bigger impact by consulting on core pieces of your system.
