Today’s K–12 digital curriculum is only as strong as its weakest (accessible) link. When outsourcing eLearning content, every vendor must deliver materials that conform to WCAG standards. Accessibility isn’t a “nice to have” or a box to check – it’s mandated by law and essential for inclusive education. As a procurement or curriculum leader, your RFP and vendor checklist must elevate WCAG compliance above all. Below we lay out how to make WCAG non‑negotiable in your vendor selection process, with concrete steps, questions, and examples. This guide focuses on choosing eLearning content development partners (courses, videos, assessments, etc.) with proven accessibility practices. Wherever your district operates – US, UK, Europe, APAC or beyond – the bottom line is the same: demand WCAG at every stage.
Why Accessibility Matters: Legal and Pedagogical Imperatives
Accessibility in K–12 isn’t just a moral win for students with disabilities – it’s a legal requirement and an educational best practice. In the US, for example, the 2024 Title II rule explicitly adopts WCAG 2.1 Level AA as the standard for K–12 digital access.
Illinois, California, New York City and other states have passed laws mandating that all third-party digital materials (websites, textbooks, apps, and courses) meet WCAG AA. In the EU and UK, public education entities must follow the European Accessibility Directive and Public Sector Accessibility Regulations (requiring WCAG 2.1 AA, soon 2.2).
Even in Asia and the Middle East, countries like the UAE, India, Japan and Singapore have woven WCAG into their standards. In short, WCAG 2.x AA is the de facto global benchmark for eLearning. Courts and regulators view it as a “safe harbor” roadmap – meeting WCAG AA is generally treated as fulfilling legal obligations.
Beyond compliance, accessible design is proven to improve learning for all students. Features like accurate captions on videos help not only deaf or hard-of-hearing students but also English-language learners and any learner in noisy environments. Good alt text for images (WCAG 1.1.1) ensures blind or low-vision students get critical content, while also reinforcing descriptive literacy for everyone. Keyboard-friendly navigation and high-contrast layouts (WCAG 2.1.1, 1.4.3) aid students with motor or vision challenges – and make interfaces easier to use for all (e.g. in low light or on small mobile screens). In short, when content is accessible, everyone benefits. A dyslexic reader can enlarge fonts, a student with temporary injury can navigate without a mouse, and an ESL learner follows along with captions.
Global Accessibility Requirements: Key Standards to Mandate
Your RFP and vendor criteria should reference the relevant standards in your jurisdiction:
- United States: ADA Title II/III, Section 504, and (by extension) the DOJ’s new 2024 Title II Rule set WCAG 2.1 AA as the requirement for public school tech. Many states now specify WCAG AA in law – e.g. Illinois HB 26 (WCAG 2.0 AA rising to 2.1 AA) and California AB 434 (WCAG 2.1 AA). Include any applicable state rules (Florida, New York, etc.) in your documentation.
- United Kingdom: The Equality Act requires “reasonable adjustments” for disabled students, and public schools fall under Web Accessibility Regulations (WCAG 2.1/2.2 AA). (Note: UK law partially exempts primary/secondary schools from the 2018 regs, but key services like enrollment must be accessible.)
- European Union: Public education portals and tools must meet WCAG 2.1 AA (EU Web Accessibility Directive). Any provider selling eLearning content or software to EU schools will face these rules.
- Asia-Pacific & Middle East: Many countries mandate or encourage WCAG 2.x: e.g., the UAE Disability Act explicitly aligns with WCAG 2.1 AA, India’s disability law references WCAG, Japan’s JIS X 8341 standard mirrors WCAG, and Singapore’s IMDA guidelines adopt WCAG. Even where not codified, WCAG is widely accepted as the technical standard.
Key takeaway: In almost all markets, WCAG 2.0/2.1 AA (and moving toward 2.2 AA) is the required or recommended level. Your procurement documents (RFP, RFQ, contracts) should explicitly name WCAG AA as the baseline. For example, CoSN advises: “when issuing RFPs… explicitly require that digital products meet WCAG 2.1 AA standards”. By stating this plainly, you leave no doubt that accessibility is a non-negotiable technical requirement.
WCAG in Vendor Contracts: VPATs and Accessibility Clauses
Beyond stating WCAG in the RFP, build in contractual safeguards. Insist that vendors provide evidence of conformance – ideally via a Voluntary Product Accessibility Template (VPAT) or similar report. A VPAT is the standardized template where a vendor documents how its product (or content) meets each WCAG success criterion. Government agencies and school districts routinely require an up-to-date VPAT: it’s essentially the vendor’s accessibility “report card.”
Include clauses such as: “Vendor shall supply a current VPAT/Accessibility Conformance Report demonstrating WCAG 2.1 AA compliance for the specified product/version as part of its proposal.” CoSN explicitly recommends asking vendors for VPATs and ensuring they “correspond to the product under consideration” and are “current and accurately reflect the product’s accessibility status”. A VPAT more than a year old or covering a different version is a red flag. Also consider legal guidance: e.g. the HHS Section 508 contracting handbook suggests using the VPAT in RFPs, and Minnesota’s VPAT scoring system highlights this in procurement.
Finally, contractually require that the vendor fix any accessibility defects discovered after delivery (and provide ongoing updates for future WCAG versions). For example, you might include a warranty clause: “Vendor guarantees that all delivered materials will comply with WCAG 2.1 AA. If testing identifies any accessibility issues within X days post-launch, vendor will remediate them at no cost.” This ensures accessibility is not just a checklist item but an ongoing commitment.
Building Your WCAG Vendor Checklist
With context set, your Vendor Checklist can guide evaluation. Here are key criteria and questions to ask every eLearning content vendor:
- Accessibility Policy & Training: Does the vendor have a formal accessibility policy or team? Are their developers and ID teams trained in WCAG and Universal Design for Learning? (Vendors who take accessibility seriously will have documentation and training programs for WCAG.)
- Standards Conformance (WCAG Levels): What WCAG standard do they target? Require at least WCAG 2.1 Level AA (or 2.2 AA if your timeline allows). This is the legal benchmark in most regions.
- VPAT/Accessibility Report: Ask for a current VPAT (or Accessibility Conformance Report) for their product or course platform. Verify the report’s date and version match what you’re procuring. (A VPAT older than 12 months likely doesn’t reflect recent changes.)
- Accessibility Testing Process: Do they test with assistive technologies? For example, “We regularly test our interactive content with screen readers (JAWS, NVDA, VoiceOver) and keyboard-only navigation”. Automated checks only catch ~30% of issues; insist on manual checks and AT tests.
- Multimedia Compliance: All videos, animations, and audio must have precise captions and transcripts (WCAG 1.2.2/1.2.4). Ask for examples or transcripts from previous projects. (Captions benefit ESL learners and the deaf alike.)
- Images & Alt-Text: Every visual asset (photos, charts, diagrams, icons) should include meaningful alt text (WCAG 1.1.1). For instance, a vendor should describe each image, not just label it “image001”. Check sample course slides: is each diagram or picture described in text?
- Color Contrast & Layout: The vendor’s design templates should meet WCAG color-contrast ratios (4.5:1 for normal text) and allow text resizing (WCAG 1.4.4). Ask if their style guides avoid conveying information by color alone and if they test for contrast.
- Document Accessibility: Ensure PDF handouts, Word docs, PowerPoint slides, etc., are tagged and text-based (not just scanned images). Non-accessible PDFs are a common pitfall. For example, a checklist item: “Uploaded PDF worksheets and slides are accessible (proper structure, readable text).”
- Assistive-Technology Compatibility: Confirm the content works with alternative inputs. Quizzes and eLearning interactions should be operable by keyboard and labeled for screen readers. Ask the vendor: “Can a student complete your interactive activities using only a keyboard and hear/see understandable feedback?”.
- Known Gaps & Future Plans: Vendors should be transparent about any outstanding issues. As CoSN notes, “require vendors to disclose known accessibility gaps” rather than simply accepting “yes” or “no”. If a vendor says 95% of criteria are met, have them specify which 5% are pending (e.g. complex tables, authoring tool limitations). Also ask how they will handle future WCAG updates (e.g. WCAG 2.2).
- Support & Remediation: What is their process if issues are found? Do they commit to fix bugs promptly? Check if they have an internal process for accessibility tickets or if they work with external auditors. An ideal vendor will audit their own releases and patch any defects at no extra cost.
To help organize these points, a simplified WCAG Vendor Checklist table can be useful:
scroll right to read more
| Accessibility Criterion | Why It Matters | Questions/Verification |
|---|---|---|
| WCAG Conformance (AA+) | Legal benchmark (ADA Title II, UK/EU regs). | Which WCAG version and level do you guarantee? Request documentation or test plan. |
| VPAT/ACR | Shows vendor’s detailed compliance status. | Provide latest VPAT (with date). Confirm it covers this product/version. |
| Assistive Tech Testing | Ensures real-world use (screen readers, etc.). | Demonstrate content used with JAWS/NVDA/keyboard. Do you have testing logs? |
| Captions & Transcripts | Required WCAG criteria (1.2.2/1.2.4) and aids all learners. | Show samples of video content – are captions accurate? Provide transcript files. |
| Alt Text & Descriptions | WCAG 1.1.1 requires meaningful alt text. | Review sample images: does alt text convey essential info? |
| Color Contrast & Layout | Needed for low-vision/dyslexic learners (WCAG 1.4.3/1.4.4). | Do your templates meet contrast ratio? Can text scale and still remain usable? |
| Document Accessibility | PDFs/Docs must be structured/tagged or screen-readers can’t parse them. | Examine a PDF/Word doc for headings, tags, and selectable text. |
| Known Gaps & Commitments | Transparency avoids surprises. Vendors must own limitations. | List any WCAG failures in your product. How/when will they be fixed? |
| User Involvement & Testing | Final check with target users reveals hidden issues. | Have you done user testing with students with disabilities? Ask for results or testimonials. |
| Contractual Protections | Legal remedy if vendor fails on promises. | Are WCAG requirements and remediation in the contract? Is there a warranty period? |
Each row above can be turned into an RFP question. For example: “Please explain how your content meets each WCAG 2.1 AA success criterion (or list any exceptions). Attach your VPAT and sample content.” In short, your evaluation should be as rigorous as possible.
Vetting Vendors: Questions and Examples
Some concrete ways to probe vendors:
- Ask for Accessibility Case Studies: Do they have experience with accessible K–12 projects? (Prefer vendors who have delivered WCAG-compliant courses for other schools or publishers.)
- Demonstrations & Sample Content: In interviews or presentations, have them walk through a course. Watch for keyboard navigation, screen reader output, color contrast. For instance: ask them to load a module and narrate it to you via a screen reader – does it make sense? Weeding out vendors who rely solely on automated tools is key.
- PoC with Accessibility Focus: When you request a Proof of Concept, include accessibility criteria. For example, “Develop a short lesson segment including captions, alt text, and compliant HTML. We will test it for usability by all.”
- RFP Language: Use explicit clauses. For instance: “Vendor shall ensure all learning materials are designed for inclusive access. This includes providing WCAG AA-compliant media and content. Vendor shall submit a current VPAT/ACR and repair any accessibility defects discovered during the review or testing.” Many sample RFPs (see CoSN) already include WCAG language and VPAT requirements.
- Pricing Transparency: Vendors should not bill extra for basic accessibility features (alt text, captions, tagging). If they do, that’s a warning sign. Ideally, these are baked into the scope.
- Continual Improvement: Inquire how the vendor stays up-to-date. For example: “What is your process for ensuring future content and platform updates comply with upcoming WCAG versions (like 2.2)?”
By the end of the RFP process, you should have a clear picture of each vendor’s accessibility maturity. Score or weight this heavily alongside cost and quality. Remember CoSN’s advice to score vendors on their accessibility documentation: if a VPAT is missing or inadequate, the vendor shouldn’t advance.
International Considerations
While WCAG is universal, recall that education procurement can have local twists. In the UK/EU, public funding means EU directives apply. Ask UK vendors about adherence to the Public Sector Regs and Equality Act; for EU markets, ensure any LMS or content platform holds an EU Accessibility Act certification (which also targets educational software). In the Middle East or APAC, many tech companies are less aware of formal requirements, but international school systems often still demand WCAG. It may help to cite local laws: e.g., telling a UAE-based vendor that the UAE Disability Act requires WCAG 2.1 compliance puts an extra onus on them.
Internally, if your school district uses federal funds or affiliates with US/EU agencies, the strictest standard applies. The cost of non-compliance can be high: lawsuits in K–12 over digital access have surged (OCR saw a 96% spike in complaints by 2021). By contrast, investing in an accessible vendor from the start avoids expensive retrofits (20–50% more costly according to studies) and fosters trust in your community.
Pulling It All Together
WCAG must be treated as non-negotiable when selecting any eLearning content provider. From the RFP’s first draft to the final contract and beyond, accessibility deserves priority equal to cost, schedule, and learning outcomes. Keep these best practices in mind:
- Embed WCAG in Procurement: State the requirement, ask for VPATs, insist on proof. (CoSN’s checklist is a great model.)
- Test, Don’t Guess: Don’t accept blind assurances. Verify with real tests and ask detailed questions.
- Document and Enforce: Make accessibility part of the scorecard and the contract clauses.
- Iterate: Accessibility is ongoing. Plan for updates and continuous audit.
By following this playbook and using tools like a WCAG Vendor Checklist and RFP template, you ensure that your chosen vendor delivers truly accessible content. The outcome is richer learning for all students and legal peace of mind for your district.
Sources: The following guidelines and case examples (including CoSN and WCAG experts) were used to compile the above recommendations
