Accessible Marketing for Startups: What WCAG 2.2 Means for Your Website, Content and Campaigns

1. Blog
2. Conversion & Pricing

By Saroj Jha · October 24, 2026 · 25 min read

This guide is for founders and marketers at Seed to Series B startups, especially in EdTech and B2B SaaS, where public schools, colleges or government agencies are buyers. Read it as orientation: I can’t tell you whether your website conforms to WCAG, and neither can Ask AAJ. Only an evaluation of your actual pages can, and Step 6 explains what that involves.

This is general information, not legal, financial or medical advice. Check with a qualified professional.

Accessible marketing means people with disabilities can find, read, watch and act on everything you publish: pages, forms, videos, webinars, PDFs, emails, posts, ads and chat. WCAG 2.2 is the published W3C standard that sets out what that takes. Some public-sector buyers ask vendors about it (Step 2). This guide explains the standard, the rules behind those buyer questions, a checklist for each kind of marketing asset, how to test, how to fill in a VPAT without overclaiming, and the order I would fix things in.

Running case: Example Co. Fictional

Example Co. is a seed-stage EdTech startup with an AI reading coach, the same company as in the EdTech Marketing Playbook. It sells to tutoring centers and is preparing for its first district pilots. Its marketing estate: 12 web pages, two forms, a trial signup flow, 8 product videos, 4 webinar recordings, 3 PDFs and one sales deck. All details are illustrative.

Step 1: Understand what WCAG 2.2 asks for

The Web Content Accessibility Guidelines (WCAG) are a W3C standard. Version 2.2 became a W3C Recommendation on 12 December 2024. It is organised around four principles: content must be perceivable, operable, understandable and robust. Each principle holds testable success criteria at three conformance levels, “A (lowest), AA, and AAA (highest)”^[1].

The Title II rule and Section 508 both name Level AA (Step 2). In my view, build to WCAG 2.2 Level AA: it is current, and W3C states that “content that conforms to WCAG 2.2 also conforms to WCAG 2.0 and WCAG 2.1”^[1], the versions those two rules cite.

What is new in WCAG 2.2

WCAG 2.2 added nine success criteria and removed one, 4.1.1 Parsing^[1]. Six of the new ones are at Level A or AA, so they are part of a Level AA target:

The other three new criteria are at AAA^[1]. Much of what Steps 3 to 5 check comes from older criteria: alt text, captions, contrast, keyboard access and form labels. Those steps cover them asset by asset.

Do this

Write “WCAG 2.2 Level AA” into your website, design and content briefs as the target.

Step 2: Find out which accessibility rules your buyers work under

Accessibility questions in a sales cycle can come from rules the buyer follows, even when the vendor is not regulated directly. Knowing the rule tells you which WCAG version and documents to prepare. These are four rules a US startup may meet.

US public schools, colleges and state and local government (ADA Title II). On April 24, 2024, the Justice Department published a final rule that “adopted the Web Content Accessibility Guidelines (“WCAG”) version 2.1 Level AA” for web content and mobile apps that state and local governments “provide or make available, directly or through contractual, licensing, or other arrangements”^[6]. That last phrase reaches content a public entity provides through vendors, which is why a district may ask them about it. An interim final rule effective April 20, 2026 moved the compliance dates back by a year^[6]:

The amendments “do not alter any other provisions of the 2024 final rule”, and the Department “will consider issuing an NPRM” (a proposed rule) during the extension^[6]. The rule just extended the dates, so check the Federal Register for any later change before relying on them.

US federal agencies (Section 508). Federal ICT “must be accessible”, and vendors “need to demonstrate” that their product or service is accessible^[7]. The Revised 508 Standards “incorporate by reference the WCAG 2.0 Level AA Success Criteria” and apply them “to both web and non-web electronic content”^[8], which can include your PDFs and decks.

EU customers (European Accessibility Act). Directive (EU) 2019/882 sets accessibility requirements for listed products and for services “provided to consumers after 28 June 2025”^[9]. The listed services include consumer banking, “e-books and dedicated software” and “e-commerce services”^[9]. A consumer is a natural person acting “outside his trade, business, craft or profession”^[9], so it matters whether you sell to businesses or individuals. “Microenterprises providing services shall be exempt”^[10]: under 10 staff and annual turnover or balance sheet total of no more than EUR 2 million^[9]. Check the rules in each country where your customers are.

Private businesses in the US (ADA Title III). The Justice Department’s position on business websites is covered in The Legal Basics of a Startup Marketing Site.

Example Co., step 2 Fictional

The first pilot district serves about 60,000 people, and Example Co. plans for the earlier date in the rule, April 26, 2027, until the district says which date applies to it. The pilot starts in January 2027 and the district wants an accessibility conformance report (ACR) with the application, so Example Co. plans to test the product, website and signup flow by November 2026. With no EU revenue yet, the European Accessibility Act is a question for later.

Do this

For each public-sector or EU prospect, write down which rule applies and which WCAG version it cites.

This is general information, not legal, financial or medical advice. Check with a qualified professional.

Step 3: Make your website, landing pages, forms and signup flows usable

Your website, landing pages and forms are web content, so all of WCAG 2.2 applies. Run these checks on every page that carries a conversion.

Pages and landing pages

• Each page has a descriptive title (2.4.2 Page Titled) and a declared language (3.1.1 Language of Page, Level A)^[1],[12].
• Headings are marked up as real headings that reflect the page’s structure (1.3.1 Info and Relationships)^[1].
• A keyboard user can skip the repeated header and menu and reach the main content (2.4.1 Bypass Blocks, Level A)^[13].
• Link text makes sense on its own, or with its sentence: “See pricing”, not “Click here” (2.4.4 Link Purpose (In Context))^[1].
• Text contrast is at least 4.5:1; large-scale text (at least 18 point, or 14 point bold) at least 3:1; button borders and field outlines at least 3:1 (1.4.3 Contrast (Minimum), 1.4.11 Non-text Contrast). Logos are exempt^[1],[14].
• Everything works from a keyboard, with a visible focus indicator (2.1.1 Keyboard, 2.4.7 Focus Visible)^[1].
• The page works when zoomed and on a narrow screen without sideways scrolling (1.4.4 Resize Text, 1.4.10 Reflow)^[1].
• Carousels, auto-playing video and animated hero banners can be paused (2.2.2 Pause, Stop, Hide), and nothing flashes beyond the limits of 2.3.1 Three Flashes or Below Threshold^[1].
• Sticky headers, cookie banners and chat launchers never fully cover the element someone has tabbed to (2.4.11)^[1].

Forms and signup flows

• Every field has a label that is presented to all users, not one exposed only to assistive technology (3.3.2 Labels or Instructions, Level A)^[1],[15].
• Errors say what is wrong and how to fix it, in text, not only in red (3.3.1 Error Identification, Level A; 1.4.1 Use of Color)^[1],[16].
• Name, email and phone fields are coded so browsers can autofill them (1.3.5 Identify Input Purpose)^[1].
• In multi-step forms, nothing the user already entered is asked for again (3.3.7)^[4].
• Login steps allow password managers and pasting, and avoid transcription CAPTCHAs (3.3.8)^[5].
• Confirmation and error messages that appear without taking focus, such as “Your form was successfully submitted” or “5 errors on page”, are announced to screen readers (4.1.3 Status Messages)^[17].

These overlap with conversion work: W3C notes that testing with disabled users “usually reveals general usability problems that impact all users”^[18]. The Website and CRO Playbook covers the same forms from the conversion side.

Example Co., step 3 Fictional

The demo form asks for school name and role on step 1, then again on the calendar step. That breaks 3.3.7. The team carries the answers forward, and replaces its puzzle CAPTCHA with an email link check.

Do this

Run the checks above on your homepage, pricing page, demo form and signup flow first.

Step 4: Make images, video, webinars, PDFs and decks accessible

Here is the checklist by format.

Images and charts

• Write alt text that does the image’s job: for a chart, the finding (for a fictional example, “Weekly reading minutes rose in each of the last four months”), not “bar chart” (1.1.1)^[1].
• Mark purely decorative images so assistive technology can ignore them (1.1.1)^[1].
• Don’t put key words only inside an image. Where text can be real text, use real text (1.4.5 Images of Text)^[1].
• Chart lines and segments need 3:1 contrast against their neighbours, and should not rely on colour alone (1.4.11, 1.4.1)^[1].

Video and webinars

• Caption every recorded video (1.2.2), and caption live webinars (1.2.4, Level AA)^[1]. Check automatic captions against the audio before you publish.
• For recorded video, provide audio description of what matters on screen (1.2.5)^[1].
• Publish a transcript with each webinar recording (W3C’s Easy Checks list transcripts among the multimedia alternatives to check)^[19], and make the registration page and player usable from a keyboard (2.1.1). How to run a webinar that creates pipeline covers the rest.

PDFs and slide decks

• Section 508 covers documents as well as websites (Step 2).
• PDFs: build from a source file with real headings (1.3.1), set the title (2.4.2) and language (3.1.1), add alt text (1.1.1), and keep text as real text rather than a scan (1.4.5)^[1]. Section508.gov says electronic documents in any format, including PDF, must meet WCAG 2.0 Level A and AA^[8].
• Decks: add alt text (1.1.1) and check contrast on the template itself (1.4.3)^[1].

The Content Creation Playbook already puts alt text, reviewed captions and 4.5:1 contrast in its pre-publish check; add these format checks to it.

Do this

Add alt text, reviewed captions and a contrast check to your pre-publish checklist.

Step 5: Check emails, social posts, ads and chatbots

This step applies the criteria to emails, social posts, ads and chatbots. WCAG was written for web content, but Section 508 applies WCAG criteria to non-web electronic content as well (Step 2). In my view, using the same criteria for these assets is a sound working standard.

Emails

• Send real text, not one image of the whole email (1.4.5)^[1].
• Use real headings, descriptive links, alt text on images and buttons with 4.5:1 contrast (1.3.1, 2.4.4, 1.1.1, 1.4.3)^[1].
• Make sure it reflows on a phone without sideways scrolling (1.4.10)^[1].

Social posts

• Use the platform’s alt-text field on every image, and caption every video, including short clips (1.1.1, 1.2.2)^[1].
• Put the message in the post text, not only inside the image.

Ads

• Treat ads as images: avoid images of text, keep contrast high, add alt text where the platform allows, caption video ads, and avoid flashing (2.3.1)^[1].
• The landing page behind the ad is a web page, so Step 3 applies in full.

Chatbots and chat widgets

• The launcher meets target size (2.5.8) and never covers focused content (2.4.11)^[1].
• The chat works from a keyboard and nothing traps the keyboard (2.1.1, 2.1.2 No Keyboard Trap)^[1].
• New replies that arrive without a page change are announced to screen readers without taking focus (4.1.3)^[17].
• A chatbot is “a fully automated contact mechanism” under 3.2.6, so keep it in the same order relative to other page content on every page where it appears^[3].
• Any time limit the chat sets meets 2.2.1 Timing Adjustable^[1].

Do this

Check your next email, social post, ad and chat widget against these lists before it ships.

Step 6: Test accessibility the way W3C recommends

Testing your marketing for accessibility needs three layers: automated tools, manual checks and people with disabilities. W3C is direct about the limits of the first: “Web accessibility evaluation tools can not determine accessibility, they can only assist in doing so”, tools “cannot check all accessibility aspects automatically”, and they “can produce false or misleading results”^[20]. W3C also says “no tool alone can determine if a site meets accessibility standards”, and “knowledgeable human evaluation is required”^[21].

Layer 1: Automated checks. Run a free checker on every template and high-traffic page. Treat the output as leads, not a score; a clean report does not mean a page conforms.

Layer 2: Manual checks. W3C’s Easy Checks cover page title, alt text, headings, contrast, text resizing, keyboard access and focus, forms, moving, flashing or blinking content, multimedia and basic structure^[19]. W3C warns that these checks “cover just a few accessibility issues”, and a web page “could seem to pass these checks, yet still have significant accessibility barriers”^[19]. Two checks need only your own machine:

• Keyboard: put the mouse away. Tab through the page, open every menu, submit every form, close every pop-up. Can you always see where you are?
• Screen reader: listen to the page from the top with a screen reader. Do headings, links, buttons and errors make sense unseen?

Layer 3: People with disabilities. Testing with disabled users “identifies usability issues that are not discovered by conformance evaluation alone”, but on its own “cannot determine if a website is accessible”; W3C says to combine it with a conformance evaluation^[18]. Pay participants and give them real tasks: “request a demo”, “start a trial”.

Getting a verdict. Whether a site conforms takes a full evaluation against every criterion at your target level. W3C’s method, WCAG-EM, is “an approach for determining conformance”^[21]. W3C says knowledgeable human evaluation is required, so if you need a verdict for a buyer I would hire a specialist; ask for their method and the list of pages tested.

Free tool

Scan your pages for the basics

The free Website Conversion Audit includes some automated accessibility checks. Like any tool, it can’t tell you whether a page conforms.

Example Co., step 6 Fictional

Example Co. sizes the work with a method, not a benchmark. The founder times one keyboard-and-screen-reader pass on the homepage: 40 minutes. Twelve pages × 40 minutes = 8 hours; two forms and the signup flow at an hour each = 3 hours; checking captions on 12 videos and recordings at roughly running time ≈ 6 hours. About 17 hours, or two working days, for a first pass, plus an external evaluation before the district application. All figures are fictional: time one page of your own and multiply.

Do this

Do one keyboard pass and one screen reader pass on your demo form this week.

Step 7: Be careful with overlays and “instant compliance” claims

Overlays are products that promise to make a website accessible or compliant automatically. I’d be wary of them. W3C says tools “can only assist” in determining accessibility^[20]. And in April 2025 the Federal Trade Commission approved a final order requiring the overlay vendor accessiBe to pay $1 million, alleging that its accessWidget “did not make all user websites WCAG-compliant”^[22]. The order bars claims that its automated products can make “any website WCAG-compliant”, or keep sites compliant over time, without supporting evidence, and bars presenting reviews or articles as independent when they are not^[22].

In my view, fix the template, form and content instead, because the FTC alleged that the overlay did not make all user websites WCAG-compliant. The FTC case is also a warning about your own claims: if your site, ACR or deck says “fully accessible” or “WCAG compliant”, you need evidence. The claims-and-proof-check skill and the Claims & Proof Checker help you test that wording before it ships.

Do this

Search your site, deck and ACR for “compliant” and “fully accessible”, and remove any claim you can’t evidence.

This is general information, not legal, financial or medical advice. Check with a qualified professional.

Step 8: Write an honest accessibility statement

An accessibility statement is a public page saying what you do on accessibility, where you fall short, and how to reach you. Section508.gov suggests that services vendors “Provide a concise accessibility statement outlining your accessibility approach or capability”^[7].

W3C says a statement should contain at least a commitment to accessibility, the standard you apply (such as WCAG 2.2) and “contact information in case users encounter problems”, and advises listing known limitations in plain terms, such as “videos do not have captions”^[23]. It is clear that “accessibility statements are not technical assessments or declarations of conformity”, and it offers a statement generator^[23].

What I would put on the page:

1. Your target: “[Company] aims to meet WCAG 2.2 Level AA.”
2. What you have done, dated: “Website and signup flow evaluated externally in October 2026.”
3. Known limitations: “Webinar recordings before September 2026 have unreviewed automatic captions.”
4. A contact route and a response time you will meet.
5. A link to your ACR, or how to request it.

Avoid “compliant” or “fully accessible” unless an evaluation supports them.

Do this

Draft your statement with W3C’s generator and list at least one known limitation honestly.

This is general information, not legal, financial or medical advice. Check with a qualified professional.

Step 9: Prepare a VPAT or ACR honestly for procurement

A VPAT is the “Voluntary Product Accessibility Template” from the Information Technology Industry Council (ITI); “Once completed, the VPAT® with documented testing results is referred to as an Accessibility Conformance Report (ACR)”^[11]. Federal buyers ask for one, and other buyers may too. For federal sales, “Without the ACR, the government may not proceed with the purchase”^[24].

Choose the right edition. The current version is VPAT 2.5Rev, dated April 2025^[11]. ITI publishes four editions^[11]:

For federal buyers, Section508.gov says to use a VPAT that covers the Revised Section 508 Standards^[24].

Fill it in honestly.

• Test before you write. ITI says users should test “against each section of the VPAT”, and the form has an “Evaluation Methods Used” field^[11]: name the tools, manual checks, assistive technologies and who did the work.
• Use the terms as defined: supports, partially supports, does not support, not applicable^[11]. Explain every partial and every “does not support” in the remarks column^[24].
• Expect buyers to read closely. Federal guidance treats “partially supports” as not conforming, says “not evaluated” gives no assurance, and tells buyers to verify claims with their own testing^[25].
• Give each gap a dated fix. Because federal guidance tells buyers to verify claims with their own testing, I would mark “partially supports” wherever I know of a gap rather than “supports”.
• Keep it current: “every time your product is changed or updated ... an updated ACR may be required”^[24]. Date and version the cover, and say whether it covers your site, help center and documents or only the product.

ITI is clear that there is “no ‘pass/fail’ scale”^[11]. An ACR describes your product; it does not certify it.

Example Co., step 9 Fictional

Example Co. uses the WCAG edition for its district application. Its evaluation finds three gaps: the reading-progress chart relies on colour, two older videos lack reviewed captions, and the trial signup’s error message isn’t announced to screen readers. The ACR marks 1.4.1, 1.2.2 and 4.1.3 “partially supports”, with an explanation and fix date for each, and sits beside the security summary on one trust page, as in How to Make Security a Selling Point.

Do this

Download the VPAT edition your next buyer needs, and book testing before you fill it in.

This is general information, not legal, financial or medical advice. Check with a qualified professional.

Step 10: Fix things in a sensible order

If a first evaluation produces more findings than you can fix at once, use the order below. It is my judgment, not W3C’s. The test I use: can a person with a disability still complete the task a visitor came to do?

The order is also a conversion order. A demo form someone can’t finish costs you that lead, which is why I start with the pages that carry a conversion (Step 3) before the archive of older assets. Put each fix in your normal backlog with an owner and a date, and write the dated gaps into your ACR (Step 9).

Do this

List your five worst findings, tag each with one of the four levels above, and put the first-level ones in this week’s sprint.

What changes by stage?

• Pre-seed — Pick an accessible website template and check its contrast and keyboard behaviour before you customise it. Caption every video from the first one. Write alt text as you go.
• Seed — Run the Step 3 to 5 checklists on every page and asset that carries a conversion. Publish an accessibility statement. If you sell to schools, colleges or government, get an external evaluation of the product and the website, and complete an ACR before your first public-sector deal, not during it.
• Series A–B — Build the checks into design and content review, templates and briefs, not a yearly audit. Re-test and update the ACR when the product changes (Section508.gov says an updated ACR may be required), add disabled users to your research plan, and revisit Step 2 before selling in the EU.

What mistakes should I avoid?

• Treating an automated score as a verdict. Tools can only assist; they can’t determine accessibility (Step 6).
• Claiming “fully compliant” without an evaluation. The FTC order turned on claims without evidence (Step 7).
• Relying on an overlay instead of fixing the page. The FTC alleged one overlay did not make all user websites WCAG-compliant (Step 7).
• Image-only emails, ads and social graphics. Without alt text or real text, a screen reader has nothing to read (Steps 4 and 5).
• Unreviewed automatic captions on webinars. Check them against the audio (Step 4).
• Chat launchers and cookie banners that cover focused content. 2.4.11 is new in WCAG 2.2 (Steps 1, 3 and 5).
• An ACR that is never updated. Section508.gov says an updated ACR may be required when the product changes (Step 9).

Method and limits

Every W3C, Section 508, ITI, Federal Register, legislation.gov.uk and FTC page cited here was opened on October 24, 2026. The Directive’s wording comes from its copy on legislation.gov.uk; check the current text before relying on it. I did not read the regulation text of the Title II rule, so this guide does not describe its exceptions. Lines marked “in my view” and the order in Step 10 are my judgment, not W3C’s. Time estimates for Example Co. are fictional.