The DOJ just handed organizations an extra year on their WCAG compliance deadline, but that doesn’t mean the work stops. If anything, it’s a signal to accelerate.

On April 20, 2026, the Department of Justice issued an Interim Final Rule extending the ADA Title II web accessibility deadline by one year. State and local government entities serving populations of 50,000 or more now have until April 26, 2027, to achieve full WCAG 2.1 Level AA conformance. Smaller jurisdictions have until April 26, 2028. For organizations that have already been tracking Oomph’s earlier breakdown of the WCAG compliance landscape, this is the latest update, and the stakes are higher than the extension might suggest.

The Extension Doesn’t Change the Underlying Obligation

The DOJ’s rule revision pushes a deadline. It doesn’t remove one. WCAG 2.1 Level AA remains the legal standard under the ADA, and the obligation to make digital content accessible to people with disabilities has been codified since the original Title II rule was finalized in April 2024. The extension was issued in response to documented capacity constraints; some organizations were struggling with the scope of remediating thousands of PDFs and auditing vendor platforms. But organizations that have paused work in anticipation of a rollback shouldn’t interpret this as a signal to wait longer.

Private litigation hasn’t paused. ADA Title III lawsuits, which apply to private businesses, saw a 102% increase in recent years and aren’t tied to the DOJ’s enforcement calendar.

What the New Deadlines Mean for Your Organization

The updated compliance schedule breaks down by entity type:

• State and local governments (50,000+ population): April 26, 2027
• State and local governments (under 50,000 population) and special districts: April 26, 2028
• Private organizations that contract with or provide digital services to public entities: bound by the deadlines of their government partners, with contractual accessibility provisions becoming standard in procurement

If you work with public sector clients, including healthcare systems, universities, or municipalities, your contracts will increasingly reflect these requirements. Vendors are legally responsible for the accessibility of the tools and platforms they provide to covered entities. An extended deadline for your client doesn’t reduce your exposure.

Why an Extra Year Is Actually an Opportunity

Organizations that treat this extension as breathing room will spend it the same way they spent the last two years: waiting. The ones that use it intentionally will close the gap permanently.

True WCAG compliance requires more than fixing what’s broken today. It means building accessibility into your content production process, your procurement checklist, and your development workflow so that new content is compliant from the moment it’s published. There’s no grandfathering for content published after the compliance date; anything that goes live after your deadline has to meet the standard on day one.

The extension also offers something the original deadline didn’t: time to do the audit properly. A comprehensive audit, one that combines automated scanning with manual testing and includes real users with disabilities, takes time to execute and even more time to act on. Organizations that use this year to conduct a thorough audit, triage findings by risk, and implement remediation systematically will be in a fundamentally stronger position than those who rush a surface-level fix in the final weeks before a hard deadline.

What to Prioritize Now

The compliance work that matters most isn’t complicated, but it does require deliberate sequencing. Start with an honest inventory of what you have: web pages, PDFs, forms, video content, mobile applications. Identify which assets carry the highest user traffic and the highest legal exposure. That’s where remediation starts.

From there, the priorities are consistent regardless of organization type:

1. Audit your highest-traffic pages and mission-critical digital services first.
2. Address the underlying code. Overlay widgets don’t satisfy the standard and have been explicitly called out by the DOJ as insufficient.
3. Review vendor contracts and confirm that third-party platforms in your digital ecosystem meet WCAG 2.1 Level AA.
4. Build an accessibility policy that defines ownership, sets standards for new content, and creates a process for users to report issues.
5. Train staff who create and publish digital content, not just developers.

The organizations that will find April 2027 manageable are already working through this list. The ones who don’t have 12 months to close a gap that was supposed to be closed already.

The Bigger Picture Hasn’t Changed

The DOJ’s extension is administrative. The underlying direction of travel toward universal, codified digital accessibility standards has been consistent for years and isn’t reversing. WCAG 3.0, expected no earlier than 2028, will shift from a pass/fail model to a tiered scoring system with Bronze, Silver, and Gold levels. Organizations that achieve full WCAG 2.1 Level AA conformance now will enter that transition from a position of strength.

Let me be upfront about something. When I started digging into how universities handle student data, I genuinely expected to find a mixed bag. Some good, some bad, nothing too shocking. What I actually found was a picture far messier than most institutions would like to admit publicly.

The Data Challenge Universities Actually Face

Higher education has a data complexity problem that’s genuinely different in scale from most other sectors. On a single campus, you’ve got admissions offices, finance departments, health centers, libraries, research labs, and dozens of other units, all touching personal data in ways that rarely get coordinated. Then the General Data Protection Regulation arrived in 2018 and essentially said: sort it out, or pay for it.

Some universities sorted it out. Others are still finding their footing, six-plus years on.

That’s not a criticism. It’s a structural reality. A retailer knows roughly what data it holds and why. A university processes the personal information of students, staff, alumni, research participants, visiting scholars, applicants who never enrolled, donors, and contractors, often simultaneously, often under completely different legal bases. The scope is genuinely daunting.

Student records alone are an iceberg. Grades, health accommodations, financial aid history, disciplinary notes, mental health referrals. Each category carries its own sensitivity tier under the regulation, and special category data (health information, for instance) requires explicit protections that can’t be bolted on as an afterthought.

Research is where things get particularly complicated. Academic research can receive a degree of flexibility under GDPR, but that flexibility comes with strings attached: ethics board approval, data minimization obligations, retention schedules that actually get followed. A number of research departments are still operating on informal data management practices, and the gaps show.

What GDPR Actually Requires (Without the Legal Fog)

When people talk about GDPR compliance, they tend to either catastrophize it into a terrifying bureaucratic maze or wave it away as box-ticking. Neither framing is accurate.

At its core, the regulation asks institutions to answer some fairly practical questions. Do you know what personal data you hold? Where it lives? Who can access it? Under what legal basis are you processing it? And how long are you keeping it before you delete it?

That last one trips universities up constantly. Retention schedules exist on paper at most institutions. Whether the systems actually enforce deletion is a different conversation entirely.

Then there’s the rights side of things. Individuals, including students and staff, have the right to access their data, correct inaccuracies, request deletion under certain circumstances, and object to specific types of processing. Universities need workable processes for handling these requests, not a generic email address that someone checks when they get around to it.

Lawful basis matters too. There’s a tendency in higher education to lean on legitimate interests as a catch-all justification for data processing, but that’s not how it works. Processing needs a clearly identified basis, documented before the processing starts, not reverse-engineered after a complaint arrives.

The Consent Problem on Campus

Consent under GDPR must be freely given, specific, informed, and unambiguous. That last word does a lot of work.

The challenge with universities and consent is structural. When a student applies for a place, registers for courses, or uses campus health services, there’s an inherent power imbalance at play. Can a student genuinely refuse to consent to data processing when saying no might affect their access to university services? GDPR is fairly clear that where a meaningful power imbalance exists, consent isn’t a reliable legal basis. Yet plenty of institutions still rely on it for processing activities where a stronger basis would be more appropriate.

Alumni engagement sits in particularly awkward territory. Sending a fundraising appeal to a graduate decades later requires a legitimate legal basis.

“We’ve always done it” isn’t one. Neither is a pre-ticked opt-in buried in a registration form from years ago.

Third-Party Vendors and the Supply Chain Nobody Talks About

Universities run sprawling technology ecosystems. Student information systems, virtual learning environments, library databases, HR platforms, research repositories, catering apps. Behind each of those sits a vendor processing personal data on the institution’s behalf.

Under GDPR, data processors must have written agreements in place with controllers. Those agreements need to specify what data is being processed, for what purpose, under what security standards, and what happens to the data when the contract ends.

In practice, many universities have signed vendor contracts where the data processing terms weren’t exactly scrutinized closely. US-based edtech vendors in particular sometimes arrive with terms drafted for a pre-GDPR world, or for US legal frameworks that don’t map neatly onto European requirements. Negotiating those terms retroactively is tedious and uncomfortable. But it’s necessary.

The Schrems II decision added another layer of complexity. Transferring personal data outside the UK or EU requires additional safeguards: standard contractual clauses, transfer impact assessments, the full apparatus. International research collaborations and cloud services with US data centers both fall squarely into this territory.

Breach Notification: The 72-Hour Clock Nobody Loves

A personal data breach must be reported to the relevant supervisory authority within 72 hours of the institution becoming aware of it. Not three working days. Seventy-two hours, including weekends.

Universities experience breaches. Phishing attacks that compromise staff email accounts. Misconfigured databases. Laptops stolen from cars. The breach itself isn’t always the compliance failure. The failure is not having the detection and reporting processes in place so that when something goes wrong, the right people know quickly and the clock starts accurately.

Data protection officers at universities often describe the internal challenge as a political one. When a breach happens, the instinct from senior leadership is frequently to investigate quietly before involving regulators. That instinct is understandable. It’s also legally risky. The 72-hour requirement isn’t aspirational.

Where Universities Actually Stand

The honest answer is: it depends enormously on the institution.

Some large research universities have invested significantly in data protection infrastructure. Dedicated DPOs with real authority, properly resourced information governance teams, institution-wide data audits, staff training that goes beyond an annual click-through module. These institutions are in a reasonably strong position.

Smaller institutions, often with less resource and less specialist expertise, sometimes find GDPR compliance still sitting largely with whoever got handed the responsibility without the budget or headcount to match it. That’s a resourcing problem as much as a knowledge one.

The UK’s Information Commissioner’s Office has taken enforcement action in higher education. Fines have been issued. Reprimands published. The sector isn’t flying under the radar.

What Good Actually Looks Like

The institutions handling this well tend to share a few common traits. Data protection is genuinely embedded in how decisions get made, not consulted at the end of projects as a compliance sign-off. Their Records of Processing Activities document is actively maintained and regularly reviewed. Staff who handle sensitive data receive meaningful training rather than performative e-learning. And the DPO has a direct line to senior leadership, not a reporting line buried three layers down in legal or IT.

Perhaps most importantly, these institutions treat GDPR compliance as an ongoing discipline rather than a project with a finish line.

The data landscape keeps changing, the technology keeps changing, and the regulation, while stable in text, continues to be interpreted in new ways through enforcement decisions and case law.

Building systems robust enough to adapt to that reality is, ultimately, the whole game.

Summary

On April 20, 2026, the Department of Justice extended ADA Title II web accessibility compliance deadlines by one to two years for state and local government entities. The extension does not pause underlying accessibility obligations, and it does not extend the separate HHS Section 504 deadline that may apply to hospitals and nonprofits receiving federal funding. Organizations tracking a single calendar are exposed to what we call the two-deadline trap. The right response is to use the extension to systematize accessibility, not to defer it.

This article is not legal advice. Confirm which rules apply to your organization with qualified counsel.

Four days before the original compliance date, the DOJ reset the clock.

Per a summary from Jackson Lewis, state and local governments with populations over 50,000 now have until April 26, 2027 to comply with WCAG 2.1 Level AA under Title II. Smaller entities and special districts have until April 26, 2028.

If you run digital for a public entity, exhale. If the extension made you slow down, recalibrate. The deadlines moved, but the risk did not.

What actually changed, and what did not?

The DOJ pushed back the date that specific technical requirements become enforceable. 

What did not change: the underlying ADA obligation to provide accessible programs and services. Title III public-accommodation risk for hospitals, providers, and nonprofits is unaffected. Demand letters and accessibility-related litigation continued straight through the extension announcement; they did not pause for it.

The compliance date is a deadline, not a start date. Organizations that wait will spend the extension period accumulating debt in templates, content, and vendor contracts, then attempt to remediate it in a sprint. That sprint is where the avoidable risk lives.

Why doesn’t the extension help hospitals and nonprofits?

The DOJ rule covers state and local government entities. It does not cover hospitals and nonprofits whose accessibility obligations come from a different source: federal financial assistance under Section 504 of the Rehabilitation Act.

Jackson Lewis notes that HHS has a separate Section 504 web accessibility compliance date, and as of this writing it has not been extended. Until HHS acts, plan as if it holds.

If your organization receives HHS funding, operates patient portals, runs scheduling or billing flows, accepts donations online, or hosts learning and event platforms, your timeline is likely shorter than the DOJ headline suggests. Title III public-accommodation exposure runs alongside it.

What is the two-deadline trap?

The two-deadline trap is the assumption that a single, well-publicized accessibility deadline is the only one that applies to your organization.

It happens when leadership tracks the DOJ Title II extension and treats it as the program’s primary clock, while a separate Section 504 or Title III obligation governs the actual exposure. The result is a roadmap pegged to the wrong date and a remediation budget that arrives late.

Avoiding it requires confirming, in writing and with counsel, which rules apply, which deadlines govern, and which user-facing services fall inside each scope.

What does day-one compliance actually look like?

Day-one compliance is the day your organization can demonstrate that new content is published accessibly, high-impact user flows work with assistive technology, vendors are managed as part of your posture, and governance is in place.

In our experience working with regulated organizations, the failure mode is rarely the homepage. It is the publishing system that keeps creating new accessibility debt — new pages, new PDFs, new embedded forms, new third-party widgets — faster than remediation can clear it. A defensible program stops the inflow before it works down the backlog.

That means accessibility moves upstream into design system components, CMS templates, content briefs, QA gates, and vendor intake. “Archived content” stops being a folder name and becomes a governance decision with rules. Procurement language changes so the next contract renewal does not lock in another year of vendor risk.

Will an accessibility overlay protect you?

No. Overlays can adjust some visual and interaction settings for some users, but they do not remediate the underlying barriers in your templates, components, content, or third-party tools. The Overlay Fact Sheet, signed by hundreds of accessibility practitioners and organizations, documents the consensus position.

If a widget is your strategy, assume you still need code-level fixes in templates, manual testing with assistive technology, content authoring training, and a third-party tool plan. The widget is not a substitute for any of those, and a number of overlay vendors have themselves been named in accessibility lawsuits.

What should accessibility leaders do this week?

Five actions, in order.

1. Confirm which rules apply, and which deadline governs. Title II, Section 504, Title III, or more than one. If there is uncertainty, this is a counsel question, not an internal one.
2. Name a single accessibility owner. Not a committee, but one person responsible for coordinating across IT, content, legal, and procurement. Accountability is the program.
3. Test your top five user-critical flows manually. Forms, authentication, scheduling, payments, donations, patient portal — whatever blocks access to your primary services. Manual keyboard-only and screen reader software spot checks find what automated scanners miss.
4. Inventory third-party tools and audit their contracts. Where contracts are silent on accessibility, flag them as priority renewals. Your compliance posture runs through every embedded vendor whether the contract says so or not.
5. Write a 90-day plan and share it with leadership. Specific, resourced, and tracked beats comprehensive and aspirational every time.

The extension is not a year off. It is a year to put a defensible program in place before the rules apply more explicitly than they already do. Use it wisely.

Compliance with the California Consumer Privacy Act (CCPA), as amended by the California Privacy Rights Act (CPRA), is a mandatory legal obligation for covered businesses, with significantly increased financial and operational risks starting in 2025.

The Critical Risk: Escalating Fines and Penalties

As of January 1, 2025, the California Privacy Protection Agency (CPPA) increased monetary thresholds and fines to align with the Consumer Price Index.

• Civil Penalties: Businesses face up to $2,663 per unintentional violation and up to $7,988 per intentional violation or those involving minors.
• No Total Cap: Because each individual consumer affected by a breach or non-compliant practice can count as a separate violation, total fines for large-scale data incidents can quickly reach millions of dollars.
• Private Right of Action: Consumers can sue for statutory damages between $107 and $799 per incident (or actual damages) following a data breach involving unencrypted personal data.

Key Deadlines and New Requirements (2026–2028)

Regulators have moved from a passive to an active enforcement model, removing the mandatory “grace period” for fixing violations before penalties are applied.

• Mandatory Risk Assessments (Effective Jan 1, 2026): Businesses must conduct risk assessments for “significant risk” processing, such as selling/sharing personal data or using sensitive information.
• Automated Decisionmaking (ADMT): New requirements for technologies that replace human decision-making (e.g., for credit or employment) go into effect, with a compliance deadline of January 1, 2027.
• Mandatory Reporting: Organizations must begin reporting their risk assessment activities to the CPPA by April 1, 2028.

Does This Apply to My Business?

A for-profit business must comply if it does business in California and meets any of the following:

• Gross annual revenue exceeds $26.625 million (updated for 2025).
• Buys, sells, or shares the personal information of 100,000 or more California residents or households.
• Derives 50% or more of its annual revenue from selling or sharing personal data.

Operational Impact of Non-Compliance

Beyond fines, non-compliance can lead to court-ordered injunctions, mandatory regular audits, and the required deletion of valuable data assets. It also risks significant reputational damage and customer churn, as modern consumers increasingly prioritize data security when choosing where to spend.

Is your website ready for California’s evolving privacy standards? Non-compliance isn’t just a legal risk — it’s a business one that can result in millions in fines, mandatory audits, and lasting reputational damage. Our team helps organizations like yours navigate complex regulatory requirements with confidence, so you can focus on what matters most. Talk to our team today.

Selecting a content management system in healthcare is no longer a purely technical decision. In today’s environment, a CMS directly impacts compliance, accessibility, speed to publish, and ultimately, trust. Healthcare organizations are under growing pressure to deliver accurate, timely information across multiple digital channels, while meeting strict regulatory and accessibility requirements. The CMS at the center of that effort needs to support far more than page updates.

Why Healthcare CMS Decisions Are Uniquely Complex

Healthcare websites serve a wide range of audiences, from patients and caregivers to providers, partners, and regulators. Content must be clear, accurate, and easy to update—often by multiple teams—without introducing risk.

At the same time, healthcare organizations face constraints that many other industries don’t. Accessibility standards, privacy expectations, and governance requirements are non-negotiable.

A CMS that lacks flexibility or control quickly becomes a bottleneck.

“The healthcare content management system market is projected to grow to over $61 billion by 2031, underscoring how healthcare organizations are prioritizing modern, scalable digital platforms to support compliance, multi-channel delivery, and governance.”

According to Mordor Intelligence

What Healthcare Teams Should Prioritize

• A healthcare CMS must support strong governance without slowing teams down. Role-based permissions, approval workflows, and auditability are essential to ensure content accuracy and accountability.
• Accessibility also needs to be built into everyday publishing, not treated as an afterthought. The CMS should make it easy for teams to maintain WCAG-compliant content as sites evolve.
• Equally important is the ability to scale across channels. Healthcare content increasingly lives beyond the website—patient portals, mobile apps, email, and emerging digital touchpoints all require consistency. Managing this content from a single system reduces duplication and risk.

Flexibility Without Compromising Security

Healthcare organizations often rely on complex digital ecosystems, including EHRs, portals, analytics tools, and consent platforms. A modern CMS should integrate cleanly with these systems rather than trying to replace them.

Flexibility matters, but not at the expense of security. The right CMS supports modular integration while keeping sensitive data protected and clearly separated from content operations.

Planning For Change, Not Just Launch

CMS selection shouldn’t be based solely on current needs. Healthcare regulations, digital expectations, and technologies continue to evolve. The most effective platforms are designed to adapt without requiring frequent replatforming.

This means supporting incremental improvements, phased rollouts, and long-term scalability—so teams can modernize at a pace that aligns with organizational priorities.

The Role Of Modern, Composable CMS Platforms

Composable CMS platforms are gaining traction in healthcare because they treat content as structured data rather than static pages. This approach supports reuse, consistency, and omnichannel delivery while maintaining governance.

For healthcare teams, this translates into faster publishing, fewer bottlenecks, and greater confidence in content accuracy without sacrificing compliance.

What This Means For Healthcare Teams

Healthcare CMS selection is about more than choosing a tool. It’s about enabling teams to communicate clearly, operate efficiently, and adapt responsibly in a complex digital landscape.

Organizations that prioritize governance, accessibility, and flexibility position themselves to deliver trusted digital experiences today and in the years ahead.

Ready to Evaluate Your Healthcare CMS? Our team helps healthcare organizations navigate complex CMS decisions with a focus on governance, accessibility, and long-term scalability. Let’s talk about what the right platform looks like for your organization.

To avoid significant financial penalties, which increased on January 1, 2025 to up to $7,988 per intentional violation, your website must function as a compliant interface for consumer privacy rights. Use this checklist to assess your current standing.

1. Mandatory Homepage Links

• “Do Not Sell or Share My Personal Information”: A clear and conspicuous link must be in the footer or header if you sell or share data for targeted advertising. This includes:
  • Retargeting Ads: Uploading your email list to Facebook (Meta), Google, or LinkedIn to show ads to those specific users or to find “Lookalike” audiences.
  • Data Brokerage: Selling your email list to another company or “renting” it out for their own marketing.
  • Third-Party Analytics: Sharing email-linked identifiers with ad networks that track users across multiple unrelated websites.
• “Limit the Use of My Sensitive Personal Information”: Required if you collect sensitive data (e.g., precise geolocation, health info, or race) for purposes beyond providing the core service.
• Alternative Option: You may use a single, combined link labeled “Your Privacy Choices” or “Your California Privacy Choices” that includes an icon if desired.

2. Automated Privacy Signals (Global Privacy Control)

• GPC Detection: Your website must automatically detect and honor “Global Privacy Control” (GPC) signals from user browsers (e.g., Brave, DuckDuckGo) as a valid opt-out request.
• Status Confirmation: As of January 1, 2026, you must display a clear confirmation to the user, such as a message stating “Opt-Out Request Honored,” when a GPC signal is detected.

3. Notice at Collection

• Timely Disclosure: You must provide a notice at or before the point of collection (e.g., on a sign-up form or via a cookie banner).
• Content Requirements: The notice must list categories of personal and sensitive info collected, the specific purpose for each, and how long each category will be retained.

4. Consumer Rights Intake (DSARs)

• Dual Methods: You must provide at least two designated methods for submitting requests (e.g., a web form and a toll-free number).
• Verification: Establish a process to verify a consumer’s identity without requiring them to create a new account solely for the request.

5. Technical & Policy Maintenance

• Accessibility: All notices must follow Web Content Accessibility Guidelines (WCAG) and be available in every language in which you conduct business.
• Annual Update: The online Privacy Policy must be reviewed and updated at least once every 12 months.
• No “Dark Patterns”: Ensure the user interface is symmetrical; for example, it should not be significantly harder to “Opt-Out” than it is to “Opt-In”.

Is your website one missing link or undetected signal away from a costly CCPA violation? Oomph’s team can walk you through a compliance audit, identify gaps in your current setup, and help you implement the technical and content updates needed to protect your organization. Get in touch with us today to book your CCPA compliance call.

Website accessibility has shifted from a “best practice” to a strictly codified legal requirement. Federal and state regulations have eliminated previous ambiguities, making WCAG 2.1 Level AA the mandatory technical standard for digital content. With updated deadlines now in place, organizations have a renewed window to get it right.

1. The Compliance Deadline: What’s Changed

The U.S. Department of Justice (DOJ) finalized a rule under Title II of the ADA that sets a firm compliance deadline for many entities:

• April 24, 2027: Deadline for public entities (and many private partners) serving populations of 50,000 or more to achieve full WCAG 2.1 Level AA conformance.
• April 26, 2028: Deadline for smaller entities.
• Private Sector Impact: While the DOJ rule focuses on public entities, it solidifies WCAG 2.1 AA as the de-facto legal standard for private businesses in Title III lawsuits, which saw a 102% increase in recent years.

2. Why WCAG 2.1 Level AA?

Unlike older versions, WCAG 2.1 includes 17 additional criteria specifically designed for mobile accessibility and users with cognitive disabilities. Compliance is measured by the “POUR” Principles:

• Perceivable: Users must be able to see or hear content (e.g., Alt-Text for images, captions for video).
• Operable: The site must work without a mouse (e.g., Keyboard-only navigation, no keyboard traps).
• Understandable: Content must be predictable with clear error messaging on forms.
• Robust: Code must be “clean” enough to work with all current and future assistive technologies, like screen readers.

3. Compliance Risks to Keep in Mind

• No “Grandfathering” for New Content: Any digital asset (PDFs, videos, or web pages) posted after the compliance deadline must be compliant from day one.
• Vendor Liability: Business owners are legally responsible for their website’s accessibility, even if they use third-party platforms or templates.
• Inadequacy of “Overlay” Widgets: The DOJ has clarified that automated widgets or “overlays” alone cannot guarantee ADA compliance; true accessibility requires fixing the underlying code.
• California-Specific Penalties: Under California’s Unruh Act, businesses can face statutory damages of $4,000+ per violation in addition to federal ADA settlements.

4. Future-Proofing: Looking Toward WCAG 3.0

While WCAG 2.1/2.2 is the current law, WCAG 3.0 is in development (expected no earlier than 2028). It will move from a pass/fail model to a Bronze, Silver, and Gold scoring system. Achieving WCAG 2.1 Level AA now effectively places an organization at the “Bronze” level, providing a solid foundation for future shifts.

Is your website ready for the April 2027 deadline? Achieving WCAG 2.1 Level AA compliance requires more than a quick fix. It means addressing the underlying code, auditing every digital asset, and building accessibility into your process from the ground up. Whether you’re starting an audit, planning remediation, or building something new, get in touch with our team to start the conversation.

For many organizations, privacy regulations like GDPR and CCPA seem like distant legal concerns rather than operational priorities. In practice, however, websites serve as the primary point of data collection—making compliance far more relevant than most teams assume. If your site collects user data in any form, privacy compliance isn’t optional.

Understanding When GDPR and CCPA Apply

GDPR governs the collection of personal data from users in the European Union, while CCPA applies to personal data collected from California residents.

Crucially, these regulations are triggered by user location, not company headquarters. A U.S.-based organization serving a global audience may be subject to both frameworks.

Why Websites Are at the Center of Compliance

Most modern websites collect data through multiple channels:

• Contact and intake forms
• Newsletter subscriptions
• Analytics and tracking tools
• Cookies and personalization technologies
• Third-party embeds and integrations

Each of these collection points creates compliance obligations around consent, transparency, and user control.

Moving Beyond Cookie Banners

Meaningful compliance extends well beyond footer disclaimers. Effective privacy management requires:

• Clear consent and opt-out mechanisms
• Transparent communication about data usage
• The ability to update policies efficiently
• Controlled publishing workflows
• Comprehensive auditability for content and data modifications

Legacy CMS platforms frequently lack the flexibility and governance capabilities needed to meet these requirements.

The Role of Your CMS in Privacy Compliance

Your content management system is instrumental in supporting privacy obligations. A modern, composable CMS enables organizations to:

• Decouple content from data logic
• Integrate consent and privacy tools seamlessly
• Manage access and publishing permissions effectively
• Deploy compliance updates across all channels instantly
• Minimize risk by limiting unnecessary data exposure

For regulated and mission-driven organizations, CMS limitations can translate directly into compliance vulnerabilities.

The Cost of Non-Compliance

While regulatory penalties are a concern, the greater risk lies in eroding user trust.

Today’s users expect transparency and control over their personal information. Organizations unable to deliver on these expectations risk damaging their reputation with customers, donors, and partners.

Final Thoughts

GDPR and CCPA represent more than legal obligations—they present fundamental digital experience challenges. Websites built on flexible, compliance-ready platforms are better positioned to adapt as privacy expectations continue to evolve.

In today’s environment, privacy compliance shouldn’t be viewed as a constraint. It’s an essential component of delivering a modern, trustworthy digital experience.

Need help ensuring your website meets modern privacy standards? Our team specializes in building compliance-ready digital platforms that protect your users and your organization. Let’s discuss your requirements.

Digital accessibility can be difficult to stay ahead of. The laws have been evolving and now the European Union (EU) has entered the arena with their own version of the Americans with Disabilities Act (ADA).

If your business sells products, services, and/or software to European consumers, this law will apply to you.

The good news: 

• The EU enacted this legislation to make it easier for businesses to comply across its various member states.
• Just like the ADA, many EU member states have specified the Web Content Accessibility Guidelines (WCAG) as their basis for measuring conformance.

The bad news:

• Each member country can define its regulations and its penalties. One infraction within the EU could accumulate fines from multiple countries. 

Keep reading for a breakdown of how the Act works and what your business needs to prepare.

What is the European Accessibility Act? 

In 2019, the EU formally adopted the European Accessibility Act (EAA). The primary goal is to create a common set of accessibility guidelines for EU member states and unify the diverging accessibility requirements in member countries. The EU member states had two years to translate the act into their national laws and four years to apply them. The deadline of June 28, 2025 is now looming.

The EAA covers a wide array of products and services, but for those that own and maintain digital platforms, the most applicable items are:

• Computers and operating systems
• Banking services and bill payments
• E-books
• Online video games
• Websites and mobile services, including e-commerce, bidding (auction) services, accommodations booking, online courses and training, and media streaming services

Who Needs to Comply?

The EAA requires that all products and services sold within the EU be accessible to people with disabilities. The EAA applies directly to public sector bodies, ensuring that government services are accessible. But it goes further as well. In short, private organizations that regularly conduct business with or provide services to public-facing government sites should also comply.

Examples of American-based businesses that would need to comply:

• Ecommerce platforms with customers who may reside in Europe. Ecommerce is typically worldwide, so this category is particularly important
• Companies that provide healthcare support via Telehealth services if offered to travelers from Europe. Drug manufacturers who offer products available to a European audience and are required to post treatment guidelines and side effects
• Hospitality platforms that attract European tourists. This includes hotels, cruise lines, tour guides and groups, and destinations such as theme parks and other amenities
• Universities and colleges who attract foreign students from Europe and elsewhere
• Banking and financial institutions who have European customers

There are limited exemptions. Micro-enterprises are exempt, and they are defined as small service providers with fewer than 10 employees and/or less than €2 million in annual turnover or annual balance sheet total.

What is required?

Information about the service

Service providers are required to explain how a service meets digital accessibility requirements. We recommend providing an accessibility statement that outlines the organization’s ongoing commitment to accessibility. It should include:

• A broad overview of the service in plain (non-technical) language
• Detailed guidelines and explanations on using the service
• An explanation of how the service aligns with the digital accessibility standards listed in Annex I of the European Accessibility Act

Compatibility and assistive technologies 

Service providers must ensure compatibility with various assistive technologies that individuals with disabilities might use. This includes screen readers, alternative input devices, keyboard-only navigation, and other tools. This is no different than ADA compliance in the United States.

Accessibility of digital platforms

Websites, online applications, and mobile device-based services must be accessible. These platforms should be designed and developed in a way that makes them perceivable, operable, understandable, and robust (POUR) for users with disabilities. Again, this is no different than ADA compliance in the United States.

Accessible support services

Communication channels for support services related to the provided services must also be accessible. This includes help desks, customer support, training materials, self-serve complaint and problem reporting, user journey flows, and other resources. Individuals with disabilities should be able to seek accessible assistance and information.

What are the metrics for compliance?

The EAA is a directive, not a standard, which means it does not promote a specific accessibility standard. Each member country can define its regulations for standards and conformance and define their penalties for non-compliance. Each country in which your service is determined to be non-compliant can apply a fine, which means that one infraction could accumulate fines from multiple countries. 

Just like the Americans with Disabilities Act, most EU member states are implementing Web Content Accessibility Guidelines 2.1 AA as their standard, which is great news for organizations that already invest in accessibility conformance.

If a member country chooses to use the stricter EN 301 549, which still uses WCAG as its baseline, there are additional standards for PDF documents, the use of biometrics, and technology like kiosks and payment terminals. These standards go beyond the current guidelines for business in the United States.

Accessibility overlays (3rd Party Widgets)

It should be noted that the EAA specifically recommends against accessibility overlay products and services — a third-party service that promises to make a website accessible without any additional work. Oomph has said for a long time that plug-ins will not fix your accessibility problem, and the EAA agrees, stating:

“Claims that a website can be made fully compliant without manual intervention are not realistic, since no automated tool can cover all the WCAG 2.1 level A and AA criteria. It is even less realistic to expect to detect automatically the additional EN 301549 criteria.”

The goals for your business

North American organizations that implemented processes to address accessibility conformance are well-positioned to comply with the EAA by June 28, 2025. In most cases, those organizations will have to do very little to comply. 

If your organization has waited to take accessibility seriously, the EAA is yet another reason to pursue conformance. The deadline is real, the fines could be significant, and the clock is ticking.

Additional Reading

Deque is a fantastic resource for well-researched and plain English articles about accessibility: European Accessibility Act (EAA): Top 20 Key Questions Answered. We suggest starting with that article and then exploring related articles for more.

A world without third-party cookies is fast approaching. Big-name browsers like Safari and Firefox already block them by default, and Google Chrome —  the biggest browser of them all —  is set to follow. 

First, a quick refresher: Websites use cookies to store data in your browser specific to that website and other sites. The question, though, is who the website is storing the data for. Third-party cookies store data that allows advertising services to track your behavior on any given site, while first-party cookies are those a website uses for its own purposes. 

Like most things, not all cookies are created equal. As browsers transition to these new defaults, some will make the grade, while others will be blocked for good. What does this mean for your website, and how can you get ahead of the change? We’ll walk you through it. 

Are Cookies Really Going Away? 

That depends on the type of cookies your site uses. Browsers are slowly blocking third-party cookies by default — those associated with cross-site tracking for ad networks like Facebook or LinkedIn — but first-site, or same-site, cookies will remain. 

That means that if retargeting is essential to your paid marketing strategy, you may need to rethink your approach. But any cookies you use to support your site features and functionality can keep on keeping on, assuming your users have agreed to the use of those cookies on your site. For example, you may be able to keep track of previously viewed content and use that information to suggest other relevant content to that user. So don’t say goodbye to your cookie consent services either; you still have to give users the chance to opt out of any first-party cookies. 

Why Now? Haven’t We Been Using Cookies Forever? 

While cookies have been a web-surfing staple for almost as long as we’ve been using the internet, that’s not necessarily a good thing. 

Legislation like GDPR in Europe, the California Consumer Privacy Act, and the New York Privacy Act are tightening restrictions on the use of consumer data, and rapidly increasing cybersecurity threats in recent years have illuminated the risks of large-scale data storage. Consumers have also begun to prize their privacy, realizing that their information is valuable and no organization should be looking over their shoulder as they browse. 

Ultimately, phasing out third-party cookies is about doing what’s best for your users. Making the move now can help instill trust in your website, since users know you aren’t capturing their data behind the scenes. Cookie consent forms also put the data you do use out in the open, showing users that your organization takes their privacy seriously and is prepared to protect it. 

How Will The End of Third-Party Cookies Impact My Industry? 

Not all organizations will feel the shift equally. We’ve seen some verticals get ahead of the curve, while others are naturally less reliant on third-party cookies. Here are some key industry-specific areas to consider. 

Healthcare

Strict privacy laws and regulations like the Health Insurance Portability and Accountability Act (HIPAA) have turned healthcare organizations into pioneers in this area. The Office of Civil Rights even published a bulletin warning organizations about third-party cookies. 

Many of the healthcare brands we support at Oomph are already focused on safeguarding user privacy because they’re used to doing it with medical records. One of our clients, for example, is already exploring adopting an in-house analytics tool hosted on their own server. If your healthcare organization is relying on third-party cookies for any marketing efforts, analytic insights, or other website features, start thinking now about the best way to phase them out. 

Higher Education

Many institutions we work with are using third-party cookies because of digital efforts to drive student enrollment. When implementing personalization cookies, be sure they are implemented with the proper “SameSite” attribute value. Then be sure to engage your vendors; we’ve encouraged many of our higher education clients to explore how their vendors are preparing for this transition.  

Nonprofits

Like higher education, nonprofits should review the vendors and larger ad networks they rely on to build their volunteer base or drive donations. Many nonprofits don’t use these services, but those that do should get ahead of the change, otherwise you may stand to lose an important fundraising channel. 

4 Steps To Prepare for the End of Third-Party Cookies

Cookies, analytics, and cross-site tracking might all sound like areas best left to the pros. But there’s a lot you can do to prepare your organization for the move away from cookies, as well as critical opportunities to pull in a vendor to maintain the functionality you need. 

Audit Your Site

A website audit should always be your first step. Taking stock of the cookies you use is the best way to get a handle on the changes you’ll need to make. Tapping your web partner is a great idea here, too. Your vendor should be able to identify existing third-party cookie warnings, which can help shape your audit. 

For example, while we were updating a client’s email marketing integration recently, Chrome notified our developer that our client’s vendor was sending third-party cookies. We then reached out to the vendor to continue the conversation, knowing that those cookies had to be addressed.

Identify Affected Cookies 

The goal of your audit is to identify all third-party cookies that won’t make the cut. Don’t stop by just listing the cookie, either. Review what function it serves and the role it plays in your organization’s digital footprint. You may have to get rid of the cookie, but that doesn’t mean you have to ditch the strategy it’s tied to. 

Reach Out to Your Vendors

Ask vendors about their plans to handle the transition away from third-party cookies, and feel out whether they’ll still be able to offer the service they currently provide. Consider it a red flag if the vendor is uninformed or unprepared; you might have to seek out alternatives if there’s even the slightest chance your current vendor will be defunct by the end of the year. 

Design Alternatives

The end of third-party cookies is daunting, but it’s also exciting. Take this opportunity to innovate on your users’ behalf. How can you design engaging new experiences that still exceed their expectations? That’s more than possible, so long as you have the right tools in place.

This could be a self-hosted analytics tool you build yourself or new local storage solutions to replace the role of cookies. You might also consider a fully authenticated experience for the users of your site. Lean on a trusted partner here, too. Vendors with website expertise can guide you toward the right solution for you and your users.

Cookies on the Brain? 

For many organizations, this is the most they’ve thought about cookies in years. Third-party cookies have become so essential to building a business online, and yet they’ve largely flown under our radar. But while this change may feel overwhelming, making the switch doesn’t have to be. 

Here at Oomph, we see this as a golden opportunity for organizations to put their users first, and we’re already taking steps to help our clients do just that. 

Need a hand bringing your website into a world beyond third-party cookies? Let’s talk about it.

Change is the only constant in life, and the same goes for accessibility. Our understanding of how to create truly accessible websites is always evolving, and so are the standards for measuring if we’ve succeeded. 

The most recent update to the Website Content Accessibility Guidelines (WCAG) — released on October 5, 2023 — is the latest attempt to help brands make their digital experiences more accessible for all users.

Don’t panic, WCAG 2.2 isn’t an overhaul. But it does shift the previous standards, delivering more specific and, in some cases, more realistic guidelines that make compliance easier (good news, website managers!). While WCAG 2.2 isn’t cause for alarm, it is something to get out in front of. Here’s what to know about WCAG, the ins and outs of the latest updates, and what it all means for your website.

What Is WCAG, Anyway? 

The Web Content Accessibility Guidelines set the standard for accessible website design. WCAG first issued design guidance in 1999, but the 2008 WCAG 2.0 laid the groundwork for accessibility today. Those standards created a framework for designing websites that are perceivable, operable, understandable, and robust for people of varying abilities. 

2018’s WCAG 2.1 wasn’t a radical departure from its predecessor, but it did add criteria related to mobile devices and users with vision and cognitive impairments. By 2023, accessibility had become widely understood and embraced as essential for inclusive design. That shift helped usher in WCAG 2.2, an update based on multiple years of research and review.

WCAG 2.2 adds nine new success criteria split across three different levels, A, AA, and AAA:

• Level A: This is the WCAG minimum, and it now includes two additional success criteria.
• Level AA: Websites that achieve AA status go beyond the basics. We advise our clients to achieve Level AA as much as possible, depending on their audience. 
• Level AAA: Websites that implement all WCAG guidelines to the highest degree can achieve AAA status. We recommend our clients do so when it suits their website and their users’ needs. For example, a healthcare organization serving older patients may need the highest level of color contrast on its site, while a university serving young students may not.

The WCAG 2.2 update didn’t just add criteria; it made some criteria obsolete, others weaker, and still others more essential than ever. Specifically, WCAG 2.2 promoted 2.4.7 Focus Visible from Level AA to Level A, which means all websites will need visual indicators that show which page feature is in focus. It also changed the recommended size of touch targets, making it easier for designers everywhere to comply.

What WCAG Standard Am I Required to Meet? 

The standard you’re required to meet depends on your industry: 

• State and Local Governments: Organizations in the public sector have the most explicit accessibility requirements. The Department of Justice (DOJ) recently announced a proposed rule that requires state and local governments to meet WCAG 2.1 Level AA standards for their websites and mobile apps.
• Private Sector: Accessibility in the private sector is less regulated, but complying with WCAG guidelines is in your best interest. One reason is that noncompliance could open your company up to a lawsuit. A recent report estimated that 4,220 ADA website lawsuits would be filed by the end of 2023 — almost double the number filed in 2018.

Though there is no official standard in courts, the DOJ has referenced WCAG 2.1 Level AA in past filings. We expect the courts to slowly start referencing 2.2 as cases catch up, but it might take another year for version 2.2 to become the standard. 

While wanting to stay out of court is understandable, legal requirements are only one reason to adopt WCAG. Millions of users around the world use screen readers and other assistive devices. Those users have buying power and they want to engage with your organization, whether that’s registering to vote, signing up for a class, or making an appointment with their healthcare provider. When your website is accessible, you’re able to connect with the broadest audience possible — likely earning more loyal users in the process.

WCAG 2.2 Checklist

While achieving inclusive website design is an exciting prospect, the nuts and bolts of getting there can feel anything but. Here, we help you visualize what the new guidelines mean in practice. You might be surprised by how accessible your website already is. 

Guideline 2.4: Navigable

The standards under guideline 2.4 address anything that will make it easier for users to move through your website.

2.4.11 Focus Not Obscured (Minimum) (AA)

• What It Means: The indicator that signals which page element is in focus is unobscured. “Sticky” elements on the page that don’t move as the user scrolls are the most common culprits that obscure key features. 
• How To Succeed: People who can’t use a mouse need to see where the keyboard has focus. You’ll have succeeded if the item that has keyboard focus is at least partially visible as a user moves from one interactive element to another. 

2.4.12 Focus Not Obscured (Enhanced) (AAA)

• What It Means: This also addresses the visibility of the keyboard focus, but it offers a path for organizations that want to go the extra mile.
• How To Succeed: You can satisfy 2.4.11 with partial visibility, but 2.4.12 requires complete visibility of the keyboard focus. 

2.4.13 Focus Appearance (AAA)

• What It Means: This is an additional measurement criterion for how a website visually indicates what the keyboard focuses on. WCAG recommends a 3:1 contrast ratio for the colors for the focus state vs. the non-focus state and an outline or border around the entire element that is at least 2 CSS pixels thick. Background colors are acceptable as long as they still satisfy the contrast ratio.
• How To Succeed: WCAG 2.1 was ambiguous about what it meant for a focus indicator to be visible. This update clarifies what’s required with clear benchmarks for contrast and thickness/visibility.

Guideline 2.5: Input Modalities

An “input” is an action a user takes to elicit a response from your website — think clicking a button or dragging and dropping a feature. These standards govern the design of those inputs. 

2.5.7 Dragging Movements (AA)

• What It Means: When an interface provides drag-and-drop functionality, there should be a simple pointer alternative that does not require drag-and-drop. This is more relevant for apps and web tools that will need to provide an alternative interface. 
• How To Succeed: This standard serves users who can’t use a mouse or touch screen to drag items. You meet the standard by allowing a user to choose not to use the supplied drag-and-drop functionality unless dragging is considered “essential.”

2.5.8 Target Size (Minimum) (AA)

• What It Means: A minimum size and minimum space for an interactive element allows a user to choose one action without accidentally triggering a nearby action.
• How To Succeed: Some people with physical impairments may not be able to click buttons that are close together. For example, they might hit the “Cancel” button instead of “Submit,” forcing them to start the process over again. You can succeed with this guideline by ensuring the size of the target for pointer inputs is at least 24 by 24 CSS pixels, with some exceptions. 

Guideline 3.2: Predictable

This guideline covers repeating features that may appear across your web pages, such as email sign-up forms or support widgets. 

3.2.6 Consistent Help (A)

• What It Means: When a site or app has a help feature, it appears in the same location consistently.
• How To Succeed: People who need help can find it more easily if it’s in the same place. If a web page contains help mechanisms that repeat across pages, they should occur in the same order relative to other content on the page — unless the user initiates the change. Those help items can include human contact details, human contact mechanisms, self-help options, or a fully automated contact mechanism (i.e., a chat feature). 

Guideline 3.3: Input Assistance

Many websites include elements that help users take certain actions. This could include directing a user to re-enter information or to make sure two fields match. Guideline 3.3 addresses this type of assistance, increasing WCAG’s support of those with cognitive disabilities. This puts the onus on developers to provide simple and secure methods for all users.

3.3.7 Redundant Entry (A)

• What It Means: Ask for information only once in the same session.
• How To Succeed: Some people with cognitive disabilities have difficulty remembering what they entered. If you’re asking the user to re-enter information they previously added, the field must either be auto-populated or the previous answer must be available for the user to select. The exception is if the user is re-entering information essential or required for security or the previous information is no longer valid.

3.3.8 Accessible Authentication (Minimum) (AA)

• What It Means: Don’t make people solve, recall, or transcribe something to log in.
• How To Succeed: Some people with cognitive disabilities can’t solve puzzles, memorize a username and password, or retype one-time passcodes. This guideline considers remembering a password or solving a puzzle (like a CAPTCHA) a cognitive function test. Websites that comply won’t require that step unless the step also provides an alternate authentication method, an assistive mechanism, a test with simple object recognition, or a test to identify non-text content the user provided to the website. 

3.3.9 Accessible Authentication (Enhanced) (AAA)

• What It Means: This builds upon 3.3.8, offering developers a greater opportunity to include users with cognitive disabilities. 
• How To Succeed: The success criteria for 3.3.9 are narrower than for 3.3.8. Websites meet the enhanced standard when a cognitive function test isn’t part of authentication unless the website also offers an alternative authentication method or a mechanism to assist the user with the test. 

Walking the Walk of WCAG

A commitment to accessibility is two-fold. It requires understanding what the most recent guidelines are (the talk) and putting those guidelines into practice (the walk). 

While it might seem like Level AAA accessibility is the way to go, the reality is that accessible websites are nuanced. Some level of accessibility is non-negotiable, but the ideal level for your site very much depends on your industry, your users, and how mature your website is — all factors we can better assess with an accessibility audit. 

If you’re building a new website, embedding WCAG principles is smart. But if you’re WCAG 2.1 compliant and a refresh is a year or two off, WCAG 2.2 may be able to wait. Curious about where your website stands? Let’s talk about it.

You may call your site audience your “users,” but ultimately, they’re just people. Imperfect people with imperfect lives — sometimes to an extreme degree.

During the COVID-19 pandemic, there was a massive rise in domestic violence. This type of violence can take many forms, including technical abuse, where technology is used to control, harass, or intimidate someone. It can look different in various situations, from an abuser constantly sending phone or text messages to controlling the sites or devices their partner can access. Even sharing a store rewards phone number can have unintended consequences. The range of opportunities for abuse is endless.

In the book Design for Safety,” author Eva PenzeyMoog cites an NPR survey that found “85 percent of shelters they surveyed were helping survivors whose abusers were monitoring their activity and location through technology.” This is an alarming statistic. Domestic violence prevention isn’t something that is taught in schools — how would people know how to protect themselves before it’s too late?

As professionals creating digital products, it’s our responsibility to create “for good.” How can we be advocates for safety in design? According to Design for Safety, as an advocate, you must “support vulnerable users to reclaim power and control.” A website could have an easy-to-use interface but still provide pathways for users to experience abuse from domestic perpetrators. Ultimately, this leaves victims vulnerable while giving them a false sense that they have more control than they genuinely do.

During the website creation process, you should aim to design for safety. A key step is to identify “ways your product can be abused, then ways to prevent that abuse.” For example, to help address any abuse or harassment captured while on a call, Google Meet has the function to “report abuse.” You can attach a video clip when you report, and they will investigate and then take action on their end. By proactively planning around safety, your organization can deepen trust with users while doing your part to prevent domestic violence.

Case Study

This past year, Oomph worked with a nonprofit website, which helps the general public understand their legal issues, to perform a user experience discovery and redesign. The site provides individuals with low incomes and limited English with local laws written in plain English. Users visit the site for legal information on various topics, including evictions, government benefits, domestic violence restraining orders and family law. A subsection of the audience uses the website to look for resources dealing with domestic violence.

When designing for this audience, we needed a way to support users who may need to exit a page quickly if they are interrupted by a potential abuser while scrolling through sensitive information, such as divorce or domestic violence resources. The site had previously utilized an “Escape” button on pages that dealt with those sorts of topics. When approaching the redesign, we wanted to ensure this button would always appear but wouldn’t interfere with other audiences, such as someone looking for information about traffic tickets. It had to walk a fine line between in-your-face and too subtle to be helpful to ensure users could see and interact with it.

When dealing with “trauma-informed” design, designers must “prioritize comfort over technological trends” (Design for Safety). Our challenge was amplified by a lack of standards for a quick exit button’s function, especially for a site with multiple audiences. Since these buttons are a relatively new best practice and little research on them exists, we were careful in our strategic approach. A quick exit button is not ingrained in a user’s mental model, making its intended action new to most people. Those who feel they might need it have to recognize its function as soon as possible.

Approach to the Quick Exit Button

While designing the quick exit button, we considered its placement, colors, and typographic style to ensure that:

• The button was easy to understand and used by people who needed it,
• The language was not retraumatizing,
• The button wasn’t so big and distracting that it took away from the overall experience of the site for those who didn’t need it, and
• The button’s position was easily accessible on a range of device sizes and types.

Our first wireframe called the button “Quick Exit.” When we tested the prototype, all five participants did not understand what the exit button meant. This emphasized how important the language on the button is. For those who have dealt with domestic violence, even the word “escape” could be harmful to hear. Additionally, since audiences view the website in different languages, we wanted to ensure that the button’s translation would not adversely affect the layout.

On our next iteration, we tried using the term “Exit” with the icon globally known for “external link.” But this still wasn’t clear enough for our users: Where would the exit bring you? To a page called “Exit”?

We needed to explain exactly what the button did, so we opted to use the universal external link icon with “Exit Site” as a label to best communicate what the button would do. Although it does not describe where you will end up, it clearly explains that you will leave the website.

To further help users understand what the button was for, we then created a pop-up at the start of the user’s journey that educates people on the button’s purpose:

Overall, there was a delicate balance we had to achieve in managing all audiences that typically view the site. We wanted to ensure that we were educating all users but not preventing users from getting help for other topics, such as information about the right to an education or disability. The pop-up, however, had additional considerations we needed to weigh as well: What if their abuser sees it upon landing? What if the user who needs it ignores it?

An alternate approach focused more on domestic violence victims is the California Victims Resource Center’s (CVRC) website, 1800victims.org. When landing on the site, visitors are first educated with a pop-up, which includes reading the website’s Terms of Use and agreeing to the terms before they can enter.

Additionally, when the user clicks the escape button (or uses the keyboard short-cut “Delete”), they are brought to a new tab that displays ABC News. The 1800victims site is changed to Netflix — with all traces of the CVRC gone. According to Columbia Health, this follows best practice because “a blank history can raise suspicion from your abuser.” This would be the safest approach for users.

To give back to the open-source community, the Oomph team turned our approach for this client into the “Quick Exit” Drupal Module. If you would like to add this kind of functionality to your own Drupal website, the module is a great place to start.

Designing for Safety

We must consider how users dealing with domestic violence may feel when they are visiting a site with sensitive content. By including information to educate users upon landing, we can help more people understand how to use a quick exit button if they find themselves in a situation where they need to swiftly leave a website. As an advocate for user safety and domestic violence prevention, you can proactively create a safety net for others by starting to review your work through the lens of how it may be abused prior to releasing it into the world.

This article is just one look at how organizations can design for safety using a quick exit button. By talking about these issues and advocating to protect users in your own design process, we can all take a step toward helping prevent domestic violence. Even if one person is helped or informed by Oomph’s quick exit button design on the website, it will be a success in our eyes.

Need help incorporating safety-focused design into your website or mobile apps? Let’s chat about your needs.

If you or someone you may know is struggling with domestic abuse, please visit or call the National Domestic Violence Hotline at 800-799-7233. For further reading on creating digital products with a safety mindset, we recommend Eva PenzeyMoog’s book Design for Safety available from A Book Apart.