The compliance basics every site needs

What compliance covers

Three families of rules touch nearly every public website.

Accessibility: can people with disabilities use the site, including those who use a screen reader, a keyboard instead of a mouse, or captions instead of sound. In the United States the Americans with Disabilities Act is the basis of many web accessibility claims. In the European Union the European Accessibility Act extends similar duties to many products and services sold there.

Privacy: what you collect, why, who gets it and how a person can see or delete it. Laws such as the GDPR in Europe and the CCPA and CPRA in California set the rules, and many other US states have their own.

Consent: when you need a person's agreement before you set a cookie or fire a tracker, and how you record it.

Compliance in Growth Score is the score for the technical basics of these: accessibility basics such as link text and image descriptions, and the privacy and consent signals on a page.

Which law applies to you depends on where your visitors live and what you do, so treat the rest of this guide as a way to cover the common ground.

Step 1: fix accessibility first

The standard to aim at is the Web Content Accessibility Guidelines, level AA (version 2.2 is current). You do not have to read it all to make real progress. These fixes cover the most common failures:

• Every meaningful image has alt text that says what it shows or does. Decorative images get an empty alt so a screen reader skips them.
• Text contrast is at least 4.5 to 1 for normal text. Light grey on white is the usual offender.
• Every form field has a visible label tied to it, not just a placeholder that vanishes when you type.
• Everything works with the keyboard alone, and you can always see where focus is.
• Links say where they go. "Click here" and "Read more" mean nothing when a screen reader lists all the links on a page.
• Touch targets are big enough to hit with a thumb. WCAG 2.2 sets a minimum of 24 by 24 CSS pixels.
• Video captions, audio transcripts.

The link text check reads every link on a page the way a screen reader announces it out of context, and finds the empty ones wrapped around an icon.

Step 2: test by using it

Automated tools catch a share of the problems, not all of them. Spend ten minutes doing what a user with a disability would do:

1. 1Put your mouse away. Tab through your home page and your checkout. Can you reach everything? Is the focus ring visible? Can you open and close menus and dialogs?
2. 2Zoom the page to 200 percent. Does anything overlap or disappear?
3. 3Turn on the screen reader that comes with your computer and listen to the first screen. Does it make sense?
4. 4Turn off images. Does the page still explain itself?

Fix what you find, and write down what you could not fix. An accessibility statement that says what you support, what you know is not yet fixed and how to reach a person is better than silence. Be careful with accessibility overlay widgets that promise to make a site compliant with one line of code. They do not fix the underlying markup and have drawn criticism and legal challenges.

Step 3: know what you collect

You cannot write an honest privacy page until you know what the site does. Make an inventory:

• Forms: what fields, where the data goes, who can see it.
• Analytics, ad pixels, session recorders, chat, fonts, maps and video embeds: each is a third party that may receive your visitors' data.
• Cookies and local storage: who sets them, for what purpose, for how long.
• Email: where the list lives and how people join and leave.

Then apply data minimisation: collect only what you need for a stated purpose and delete it when that purpose ends. Every field you remove is a risk you no longer carry. The tracker check lists the third parties a page really loads, which is almost always more than the team thinks.

Keep a short record of why each one is there. When somebody asks, or a client sends a security questionnaire, you will be glad you did.

Step 4: write a privacy page people can read

A privacy policy is a promise. Write it about what you actually do, and update it when you change.

Cover, in plain words:

• What you collect and why.
• Who you share it with (your payment provider, your email service, your analytics).
• How long you keep it.
• How a person can ask for a copy or ask you to delete it, and how fast you will answer.
• How to reach a real person.
• Which rights apply where they live.

If you serve California residents, honour opt-out requests, including the Global Privacy Control signal that a browser can send automatically.

If you serve people in the European Union, you need a lawful basis for each use of personal data, and you must be able to act on access and erasure requests.

Do not paste a template from another company and hope. It will describe tools you do not use and miss the ones you do.

Step 5: get consent right

Where the law requires consent before non-essential cookies or trackers, the banner has to do real work.

The rules of thumb:

• Nothing non-essential fires before the visitor agrees. A banner that loads every tracker first and asks afterwards is not consent.
• Accepting and declining are equally easy. Two buttons of the same size, not a bright "accept" and a hidden grey link.
• The visitor can change their mind later, from a link that is always there.
• You store a record of the choice.
• Signals such as Do Not Track and Global Privacy Control are respected where you have promised or are required to.

A cookieless approach to analytics removes much of this burden, because there is nothing to consent to. The Surfil pixel is built that way: no cookies and no browser storage, no names, emails or IP addresses, and raw events deleted after seven days.

Test it yourself. Open the site in a private window, decline everything and check in the network panel that the trackers stayed quiet.

Step 6: email and quiet rules

A few smaller duties catch businesses that did everything else right.

Email: US law requires a working unsubscribe link and a physical postal address in commercial email, and honest subject lines. Honour unsubscribes quickly. Do not buy lists.

Security: privacy law expects reasonable safeguards. Serving the site over https and setting the standard security headers are part of that.

Vendors: if a service handles your visitors' data on your behalf, you may need a data processing agreement with them, and a list of those subprocessors is good hygiene to keep.

Breaches: know in advance who you would tell, and how fast, if customer data leaked. Some laws set a deadline measured in days.

None of this needs a big budget. It needs a named owner and a calendar entry.

When to bring in a professional

This guide covers what you can check yourself. Bring in a lawyer or an accessibility specialist when:

• You sell in a regulated field such as health, finance or children's products.
• You have received a demand letter or a regulator's inquiry. Do not answer it alone.
• You are about to collect sensitive data: health details, precise location, government identifiers.
• You operate in several countries and are not sure which rules apply.
• You need a formal accessibility audit with a written report.

A good rhythm for everyone else: review the inventory, the privacy page and the accessibility basics every quarter, and after any change to your tools. Growth Score reads the technical signals daily and flags the ones that flip. The free Growth Diagnosis shows where you stand today.