Accessibility is the part of a school website nobody thinks about until a parent, a lawyer, or an auditor makes them. Then it becomes the only thing anyone thinks about. If you run a NYC school or PTA site, “WCAG 2.1 AA” is the standard that shows up in DOE guidance, in Section 504 complaints, and in the fine print of vendor contracts — usually asserted, rarely verified.
This article explains what that standard actually requires in plain English, why most low-cost school-website vendors quietly fail it, and how to check your own site in an afternoon. No legalese, no fear-selling. Just what the acronym means and what to do about it.
What WCAG 2.1 AA actually is
WCAG stands for the Web Content Accessibility Guidelines, published by the W3C — the same standards body that governs HTML itself. It’s the internationally recognized benchmark for whether a website works for people with disabilities: blind and low-vision users on screen readers, people who can’t use a mouse, people with color-vision differences, people with cognitive or motor differences.
The “2.1” is the version (published 2018; 2.2 exists but 2.1 AA is the level courts and agencies still cite). The “AA” is the conformance level. There are three:
- A — the bare minimum. Miss these and the site is broken for whole groups of people.
- AA — the real-world target. This is what the ADA, Section 508, and essentially every school/government accessibility requirement points to.
- AAA — aspirational. Nobody’s contract requires full AAA; parts of it aren’t achievable for all content.
When a policy says “accessible,” it almost always means WCAG 2.1 AA. That’s the number to hold every vendor to.
Why this is not optional for a NYC school
Three overlapping obligations land on school and school-affiliated sites, and PTAs often assume none of them apply to a “volunteer” website. They do.
Section 504 of the Rehabilitation Act and the ADA. Any program that receives federal funding — which covers public schools and most of what happens around them — has to provide equal access, and the Department of Justice has repeatedly held that “equal access” includes the website. In 2024 the DOJ finalized a rule explicitly adopting WCAG 2.1 AA as the technical standard for state and local government entities, including public schools. This isn’t a gray area anymore; it’s a named standard in federal regulation.
NYC DOE expectations. The DOE holds its own web properties to accessibility standards and expects school-affiliated sites to follow suit. A PTA site that lives at the school’s domain, or that’s linked as the school’s official web presence, inherits that expectation whether or not anyone signed a form. Our own schools and PTA build treats WCAG 2.1 AA as a baseline for exactly this reason — it’s the benchmark the DOE asks for.
The practical one: complaints and OCR. Most accessibility problems don’t surface as lawsuits. They surface as a parent who can’t read the lunch menu on a screen reader, files a complaint with the Office for Civil Rights, and now your board is spending its spring answering a federal inquiry instead of running the plant sale. The cost of non-compliance is rarely a judgment; it’s the disruption of being investigated.
The point isn’t to scare you. It’s that “we’re just a PTA” is not a shield here, and pretending it is quietly transfers the risk to whichever board is sitting there when a complaint lands.
Why most cheap vendors quietly fail it
Here’s the uncomfortable part. A large share of low-end school-website vendors claim WCAG compliance in their sales copy and don’t actually deliver it. This isn’t always dishonesty — it’s that accessibility is maintained, not achieved once, and the cheap model doesn’t budget for maintenance.
The common failure modes:
- The template was accessible; your content isn’t. A vendor can ship an accessible theme and still let you upload a scanned PDF of the newsletter (unreadable to screen readers), embed a color-coded calendar with no text alternative, or paste in text that fails contrast. Accessibility breaks on the content layer, and that’s the layer volunteers touch every week.
- An “accessibility widget” instead of real compliance. You’ve seen the little accessibility-symbol button that floats in the corner and offers “high contrast” and “bigger text.” These overlay tools are widely criticized by actual disability advocates, and courts have made clear they do not substitute for a site that’s accessible underneath. A widget is a fig leaf, not a fix.
- No re-check after edits. Compliance drifts. Every image uploaded without alt text, every low-contrast heading a volunteer adds, every “click here” link nudges the site back out of conformance. If nobody re-audits, an “accessible” site is only accessible on launch day.
This is the gap between a checkbox on a proposal and a site a screen-reader user can actually navigate. The word “compliant” on a vendor’s website is worth exactly nothing until you’ve tested it.
The 10-item self-check
You don’t need an auditor for a first pass. Here’s a practical checklist a board member can run on the current site this week. It won’t catch everything, but it catches the failures that matter most — and if your site fails several of these, you have your answer about the vendor.
- Keyboard only. Unplug your mouse. Can you
Tabthrough every menu, link, and form on the homepage and reach everything? If focus gets trapped or skips the navigation, that’s a failure. - Visible focus. As you tab, can you see which element is selected — a clear outline or highlight? Invisible focus fails AA.
- Alt text on images. Right-click a few key images (the logo, an event flyer) and inspect. Meaningful images need descriptive alt text; a flyer that’s just an image of text is a common, serious failure.
- Color contrast. Run the site through a free contrast checker (WebAIM’s is the standard). Body text needs a 4.5:1 ratio; large text needs 3:1. Light-gray-on-white “elegant” text almost always fails.
- Headings in order. View the page structure — headings should go H1 → H2 → H3 logically, not chosen for size. Screen-reader users navigate by heading; scrambled headings break that.
- Links that make sense out of context. Scan for “click here” and “read more.” A screen reader lists links out of context; each should describe its destination.
- Forms with labels. Every input on your contact/donation form needs a real, associated label — not just placeholder text that vanishes when you type.
- PDFs. Are your key documents (calendar, newsletter, forms) posted as real HTML pages or as PDFs? Scanned PDFs are frequently inaccessible; prefer HTML, and tag any PDF you must post.
- Video captions. Any embedded video — a principal’s message, an event recap — needs accurate captions, not auto-generated gibberish.
- Zoom to 200%. Zoom the browser to 200%. Does the layout still work, or does text get cut off and buttons overlap? AA requires the content to reflow.
Score yourself honestly. Zero to two failures: you’re in reasonable shape, keep it maintained. Three or more: your site is not meeting WCAG 2.1 AA today, regardless of what the vendor claims.
What “maintained” actually takes
The real lesson underneath the checklist is that accessibility is a practice, not a purchase. A compliant site drifts out of compliance the moment a well-meaning volunteer uploads an untagged PDF or a low-contrast graphic. Three things keep it in bounds:
- An accessible foundation — semantic HTML, proper focus management, tested contrast in the design system, so the baseline is right before anyone adds content.
- Guardrails on the content layer — a CMS that nudges volunteers toward alt text and warns on obvious problems, so the weekly edits don’t quietly break things.
- Periodic re-checks — someone running the 10-item pass a couple of times a year, especially before high-traffic seasons.
This is precisely why we build accessibility in and keep it that way rather than bolting on a widget: the sites we ship for NYC schools start from semantic, WCAG 2.1 AA foundations, and the CMS is designed so a board member’s ordinary edits don’t knock the site out of conformance. Accessibility that isn’t maintained isn’t accessibility — it’s a launch-day screenshot.
Bottom line
WCAG 2.1 AA is the accessibility standard NYC schools and PTAs are actually held to — through Section 504, the ADA’s 2024 DOJ rule, and DOE expectations — not a nice-to-have. Most low-cost vendors assert it and don’t deliver it, because they treat it as a one-time checkbox instead of an ongoing practice, and because the failures happen on the content layer their model doesn’t cover.
Run the 10-item self-check on your current site. If it fails, you’ve learned something specific and useful about your vendor — and you have leverage. If you want a second set of eyes, or a site built to meet the standard and stay there, send us a note. The first call is 20 minutes, free, and ends with an honest read on where your site actually stands.
Written by Full Stack Tech NYC. We build custom, WCAG 2.1 AA websites for NYC schools and PTAs — flat pricing, you own everything. See pricing and process →