← All posts

Consent isn't just a legal checkbox: rethinking how your website asks for information.

Cookie banners, newsletter opt-ins, intake forms—most websites collect consent in ways that are technically compliant and genuinely not. Here's what meaningful consent looks like in practice.

When people in the nonprofit sector talk about consent, they’re usually talking about it in relation to the people they serve—making sure clients understand what they’re agreeing to, have the ability to say no, and aren’t being pressured into something. It’s a foundational principle in social work, healthcare, and advocacy.

The same principle almost never gets applied to how those organizations collect information on their websites. And the gap is worth examining.

Most website consent collection—cookie banners, newsletter popups, data sharing disclosures—is designed primarily around legal compliance. The goal is to have documentation that consent was given, not to ensure that the person giving consent actually understood what they were agreeing to or had a genuine choice. Those are different goals, and the design choices that serve one often undermine the other.

Cookie banners with asymmetric design. A cookie banner that has a large, colorful “Accept All” button and a small, gray “Manage Preferences” link buried below it is communicating a preference to the user through visual hierarchy. The design is nudging toward a specific choice while maintaining the technical position that a choice was made. That’s not meaningfully different from a contract with a legally binding clause in footnote text.

Newsletter popups that appear immediately. A popup that appears the moment someone arrives on your site, before they’ve had any chance to understand what your organization does or why your newsletter might be valuable to them, is not asking a question in good faith. It’s interrupting before the relationship has been established to extract an agreement. Even if the person clicks “yes,” that’s not meaningfully informed consent.

Form fields that collect more than stated. If your contact form says “we’ll use this information to respond to your inquiry” but your platform also adds everyone who contacts you to your email newsletter list, you’ve collected email addresses for a purpose that wasn’t disclosed. This isn’t hypothetical—it’s a common default in many CRM and form tools that nobody changed.

Privacy policies that function as legal disclaimers rather than communication. A privacy policy that says “we may share your information with third-party service providers” without specifying which third parties or what kinds of information is technically disclosing something without actually informing anyone of anything. Most people don’t read privacy policies, and most privacy policies are not written to be read. That’s a design problem, not just a compliance problem.

Why this matters more for organizations serving vulnerable populations

For most commercial websites, the stakes of imperfect consent design are relatively low. Someone gets more emails than they wanted. They have to unsubscribe from a few things. It’s annoying but not harmful.

For organizations serving people who are navigating legal systems, health decisions, housing crises, or unsafe home situations, the stakes are different. Someone who was added to an email list without clear consent might receive an email with your organization’s name in the subject line on a shared device. Someone who didn’t understand what data your intake form was collecting might have disclosed information that creates risk for them.

Meaningful consent matters here not just as an ethical principle in the abstract, but as a concrete safety practice.

It’s actually not complicated. Genuine consent has a few properties: the person understands what they’re agreeing to, the explanation is in language they can understand, agreeing is genuinely optional and the consequences of not agreeing are clear, and they have an easy way to withdraw consent later.

For a newsletter signup: a short sentence about what the newsletter contains and how often it goes out, an unchecked box, and a clear unsubscribe link in every email. The design should be neutral—not weighted toward a particular choice.

For a cookie banner: if you’re using cookies for anything beyond essential site function, you need to explain what those cookies do and give people a genuine way to decline them. If the “decline” option is significantly harder to find or use than the “accept” option, the design is doing the heavy lifting that the words aren’t.

For an intake form: a brief note at the top explaining what the information will be used for, who will see it, and how long it will be kept. If there are any circumstances under which the information might be shared outside the organization—mandatory reporting obligations, for example—say so before the person fills out the form.

For your privacy policy: it should be written in plain language, it should accurately describe what your site actually does (not what you intend it to do in principle), and it should be easy to find from any page. A real privacy policy is a communication to the people who use your site, not a legal defense document.

A useful exercise: go through every place on your site where you’re asking for something from a visitor—their email address, their personal information, their agreement to cookies—and ask two questions. First: does the person have a genuine, friction-free way to decline? Second: do they have enough information to understand what they’re agreeing to?

If either answer is no, you have a consent design problem.

The bar isn’t perfection. It’s sincerity. Designing consent with genuine respect for the person’s autonomy, rather than as a compliance checkbox to get past as quickly as possible, is both the right thing to do and—for organizations whose entire mission involves advocating for people—the only position that’s internally consistent.

If you’d like help reviewing how your site handles consent and data collection, I’d love to take a look.