WCAG 3.0 for Startup Apps: Should You Wait, or Design to WCAG 2.2 AA Now?
No, a startup app shouldn't wait for WCAG 3.0: design to WCAG 2.2 Level AA now. WCAG 3.0 is still a W3C Working Draft (the latest was published on 10 September 2026), and the W3C says it isn't expected to be a finished standard for a few more years. The W3C's own advice is that the best way to prepare for WCAG 3 is to meet WCAG 2.2 today, and WCAG 2 won't be deprecated for several years after WCAG 3 is finalised.
That's the short answer. The rest of this guide covers where WCAG 3.0 actually stands, which standard regulators and enterprise customers ask a startup to meet, the WCAG 2.2 rules that startup apps miss most often, and the design habits that satisfy WCAG 2.2 now and will still count when WCAG 3.0 lands. For the fundamentals of WCAG itself (the four principles, contrast, alt text, testing), start with our practical web accessibility guide.
Is WCAG 3.0 out yet?
No. Here's where each version stands as of November 2026, from the W3C's own pages:
| Version | Status | What it means for a startup |
|---|---|---|
| WCAG 2.1 | W3C Recommendation (2018) | Still the version many laws and standards reference, including the EU's EN 301 549 |
| WCAG 2.2 | W3C Recommendation (October 2023, updated December 2024); also ISO/IEC 40500:2025 | The current standard. Design and test to Level AA. Meeting 2.2 AA also meets 2.1 AA |
| WCAG 3.0 | Working Draft (latest 10 September 2026), described by the W3C as incomplete and likely to change | Read it for direction, don't design to it, and don't claim conformance to it |
WCAG 3.0 is a deeper rewrite than the jump from 2.1 to 2.2. Its guidelines are written as outcomes ("image alternatives", "clear language", "keyboard focus appearance") backed by core and supplemental requirements, and its scope goes beyond web pages to apps, wearables, and VR and AR. The conformance model is still being debated: the September 2026 draft proposes that you must meet all core requirements to conform, with tiers reporting progress beyond that, and the W3C is still asking for feedback on an alternative scoring approach. Anything you read claiming a fixed WCAG 3.0 "Bronze, Silver, Gold" system or a final contrast formula is out of date or guessing.
If a vendor, plugin or overlay advertises "WCAG 3.0 compliance", treat it as a red flag. There's nothing final to comply with yet. Ask instead for a WCAG 2.2 AA audit, and an Accessibility Conformance Report if enterprise buyers want one.
Which accessibility standard do customers and regulators actually ask startups for?
Every route that matters to a startup today points at WCAG 2.x Level AA, not 3.0:
| Source | What it asks for | Who it hits |
|---|---|---|
| EU European Accessibility Act (in force since 28 June 2025) | Accessible e-commerce, banking, e-books, transport ticketing and similar services. EN 301 549 is the presumed route, and it incorporates WCAG 2.1 AA (a newer edition moves to 2.2) | Startups selling these services to EU consumers. Microenterprises providing services (under 10 staff and no more than €2 million turnover or balance sheet) are exempt |
| US ADA lawsuits and settlements | The ADA doesn't name a technical standard for private businesses, but demand letters and settlements typically cite WCAG 2.1 or 2.2 AA | Consumer-facing US sites and apps, especially e-commerce |
| Enterprise and public-sector procurement | An Accessibility Conformance Report (often on the VPAT template) mapped to WCAG 2.x and, in the EU, EN 301 549 | B2B SaaS selling to large companies, universities or government |
| Apple's App Store | Accessibility Nutrition Labels on product pages for features like VoiceOver, Larger Text, Sufficient Contrast and Reduced Motion. Voluntary for now | Every iOS app. Only claim a feature if users can complete the app's common tasks with it |
The legal details vary by country and by what you sell, so check your own position with a qualified adviser. The design conclusion doesn't vary: WCAG 2.2 AA is the target that covers all four rows.
What does WCAG 2.2 add that startup apps often miss?
Most teams know the WCAG 2.1 basics: contrast, alt text, labels, keyboard access. WCAG 2.2 added six Level A and AA criteria, and they land squarely on the patterns startup apps use most: sticky headers, drag-and-drop boards, small icon buttons, one-time passcodes and long sign-up flows.
- Focus not obscured (2.4.11, AA). When a keyboard user tabs to a control, it can't be completely hidden behind a sticky header, cookie banner or chat widget. Design sticky elements with enough scroll padding that focused items stay visible.
- Dragging movements (2.5.7, AA). Anything done by dragging, such as reordering a Kanban card, moving a slider or adjusting a map, needs a single-pointer alternative: arrow buttons, a "Move to" menu, or tap-to-set on the slider track.
- Target size minimum (2.5.8, AA). Tap and click targets need to be at least 24 by 24 CSS pixels, or have enough spacing around them. That's the legal floor; Apple's guidance of about 44 by 44 points and Google's 48 by 48 dp are the better target for an app.
- Accessible authentication (3.3.8, AA). Don't make people solve a cognitive test, such as remembering a password or transcribing a code, without help. Allow paste and password managers in login fields, let one-time codes autofill, and offer passkeys, email links or a non-puzzle CAPTCHA.
- Consistent help (3.2.6, A). If you offer help (chat, a help link, a phone number), put it in the same place on every screen.
- Redundant entry (3.3.7, A). Don't ask for the same information twice in one flow. Pre-fill the billing address from shipping, or offer a "same as above" option.
Of these, accessible authentication and target size are the two most often locked in by the design file itself: a login screen that blocks paste, or an icon toolbar drawn at 20 pixels. They're cheap to fix in Figma and expensive after build. The same applies to onboarding flows, which are where redundant entry and hidden help usually creep in; our guide to SaaS onboarding UX design covers how to keep those flows short.
What in WCAG 3.0 is worth designing for now?
Even though it's a draft, WCAG 3.0 shows where accessibility is heading. These habits meet WCAG 2.2 today and line up with the direction of the WCAG 3.0 drafts, so nothing you do now is wasted:
- Design strong focus styles, not just visible ones. WCAG 2.2 AA only asks that focus is visible; its AAA criterion and the WCAG 3.0 drafts both care about how clearly it shows. A thick, high-contrast focus ring in your design system costs nothing and helps everyone using a keyboard.
- Write in plain language. "Clear language" is a guideline in the WCAG 3.0 drafts. Short sentences, familiar words and specific button labels ("Get IPO updates", not "Submit") are good UX regardless of any standard.
- Keep contrast to the WCAG 2.x ratios. Body text at 4.5:1 and large text and UI components at 3:1. How WCAG 3.0 will measure contrast isn't settled, so don't adopt an alternative formula on its own and risk failing the standard that's actually in force.
- Document how you do accessibility. The WCAG 3.0 drafts introduce assertions: statements about your process, such as a style guide, usability testing or content review. Writing accessibility rules into your design system and recording what you tested is useful evidence now for procurement, and it may count for more later.
- Treat native apps as first-class. WCAG 3.0 covers apps directly. Until then, the W3C's WCAG2Mobile guidance (first published as a draft note in May 2025) explains how WCAG 2.2 applies to native and hybrid apps, treating each screen like a web page.
What should a startup's WCAG 2.2 AA checklist look like?
Most accessibility is decided before any code is written, so this checklist is split by where the decision gets made:
| Area | Decide in design (Figma) | Check in the build |
|---|---|---|
| Colour and contrast | Every text and UI colour pairing passes 4.5:1 or 3:1; status never shown by colour alone | Run an automated scan; check dark mode separately |
| Type and zoom | 16px+ body text, a type scale that survives 200% zoom and large system text | Test at 200% browser zoom and the largest iOS and Android text sizes |
| Focus and keyboard | A designed focus ring in the design system; sticky elements that don't cover focus | Tab through every flow without a mouse; nothing traps focus |
| Targets and gestures | Targets at 44pt or 48dp where possible; a button alternative for every drag or swipe | Try each gesture-based action with a single tap |
| Forms and login | Visible labels, errors in text, no repeated fields, paste allowed, passkeys or email links offered | Test with a password manager and a screen reader |
| Screen readers | Name every icon button and plan the heading order | Run the key tasks with VoiceOver and TalkBack |
If your app is already live, a website UX audit is the quickest way to find which of these rows you fail. If you're submitting an iOS or Android app, our guide to designing a mobile app UI that passes App Store review covers Dynamic Type, tap targets and labels from the review side. Apps that handle money or health have the most to lose from a confusing interface; calm UI design for fintech and health apps shows how clarity and accessibility support each other.
One caution on speed: AI design and prototyping tools now produce full screens in seconds, but they don't reliably check contrast, target size or focus order. If you use them, and our roundup of the best AI design tools in 2026 compares the main ones, run the table above on whatever they generate before it reaches users.
How do we build accessibility into a startup design project?
FRPROTECH has designed 3,000+ projects for clients in 30+ countries over 8+ years, with a 100% Job Success score and Top Rated Plus status on Upwork. If you're about to design or rebuild an app and want WCAG 2.2 AA built in from the first screen, our UI/UX design service covers research, Figma design and a developer-ready handoff.
Frequently asked questions
Is WCAG 3.0 released yet?
No. WCAG 3.0 is still a W3C Working Draft; the latest was published on 10 September 2026. The W3C describes it as incomplete and likely to change, and says it isn't expected to be a completed standard for a few more years. WCAG 2.2 is the current W3C Recommendation, and WCAG 2 won't be deprecated for several years after WCAG 3 is finalised.
Should my startup design to WCAG 2.2 or WCAG 3.0?
Design to WCAG 2.2 Level AA. It's the current standard, it's what laws, lawsuits and enterprise procurement reference, and the W3C says meeting WCAG 2.2 is the best way to prepare for WCAG 3. Meeting 2.2 AA also meets 2.1 AA, which is what the EU's EN 301 549 standard currently incorporates.
Does WCAG apply to native mobile apps?
WCAG was written for web content, but regulators and buyers apply it to native apps too, and the W3C's WCAG2Mobile guidance explains how WCAG 2.2 maps to native and hybrid apps, treating each screen like a web page. The EU's EN 301 549 standard also covers non-web software. WCAG 3.0 is being written to cover apps directly.
What are the new rules in WCAG 2.2?
WCAG 2.2 added six Level A and AA success criteria: focus not obscured (2.4.11), dragging movements (2.5.7), target size minimum of 24 by 24 CSS pixels (2.5.8), accessible authentication (3.3.8), consistent help (3.2.6) and redundant entry (3.3.7). It also removed 4.1.1 Parsing. For apps, the target size and accessible authentication rules usually need the most design changes.
Want this done for you?
FRPROTECH is a Top Rated Plus Upwork agency with 3,000+ projects delivered across 30+ countries. Tell us your goals and we'll handle the rest.
Written by Faisal Rizwan, CEO & Founder of FRPROTECH. 8+ years and 3,000+ projects building brands and websites for clients in 30+ countries, with a 100% Job Success Score as a Top Rated Plus freelancer on Upwork.
