WCAG & Section 508 Accessibility: The Wheelchair Ramp Nobody Built for Strollers
Approximate reading time: 9 minutes. Last updated October 1, 2026.
Years ago, somebody decided to install a wheelchair ramp or an elevator in the place where you shop or eat. They did not ask whether the owner or landlord wanted one. Either the engineer or the architect voluntarily complied with a regulation, or an inspector issued a warning and a directive to install one.
Then a strange thing happened. The people using that ramp most days turned out not to be wheelchair users at all.
It was the mother with a stroller and a toddler on her hip. The 78-year-old with a cane and a healthy retirement account who now shops at this store instead of the one down the block with four granite steps. The delivery driver with a hand truck stacked with resupplies, who now gets in and out in three minutes instead of ten. The guy dragging a rolling suitcase. The couple carrying a heavy box between them. The movers. The first responders.
The ramp was built for a legally protected minority - Americans with disabilities, led in large part by the Paralyzed Veterans of America who paved the way for the Architectural Barriers Act of 1968 and the Rehabilitation Act of 1973, which led to the Americans with Disabilities Act of of 1990.
It ended up serving a large share of everyone who walked through your door, and it made your business easier to work with. Thank a wounded veteran for that.
A short history of being forced to do something good for yourself
The first curb cuts in the United States showed up in Kalamazoo, Michigan, in the 1940s, put in for veterans coming home from the war with disabilities. They stayed a local curiosity for about thirty years.
The thing that changed it was a fight. In 1972, disability rights activists in Berkeley, California, got tired of waiting for the city and went out at night with sledgehammers and bags of concrete and built their own ramps at intersections. Ed Roberts and the crowd around the Center for Independent Living turned that into a movement. The Architectural Barriers Act had already been on the books since 1968. The Rehabilitation Act followed in 1973. The Americans with Disabilities Act arrived in 1990 and made curb cuts and ramps a national expectation rather than a local favor.
Every one of those was compliance. A mandate. A cost line in somebody's budget that nobody volunteered for.
And every one of those ended up in the "good decision" column, because cities discovered that flat entrances move parents, seniors, luggage, carts, bicycles, and freight better than steps do. Nobody ran that study first. They found out by being made to do it.
Web accessibility is sitting in exactly the same spot, roughly forty years behind.
The law part, quickly
If you sell to the federal government, or you are the federal government, Section 508 of the Rehabilitation Act applies. The Revised 508 Standards took effect in January 2018 and pulled WCAG 2.0 Level A and AA in by reference. Every federal website, every PDF an agency posts, every piece of software an agency buys, every training video.
If you are a state or local government, ADA Title II now has teeth and a date on it. DOJ's 2024 rule set WCAG 2.1 Level AA as the standard. In April 2026, DOJ pushed the deadlines back a year without changing a word of the substance: large entities (population 50,000 and up) now have until April 26, 2027, and smaller entities and special districts until April 26, 2028. That extension is not a reprieve. It is a running clock with better lighting.
If you are a private business, ADA Title III applies to you through a decade of litigation rather than a published technical standard, and the courts have generally looked to WCAG.
For example, Target Corporation settled for $6 million in damages and agreed to sweeping website accessibility overhauls due to a law suit from the National Federation of the Blind. Netflix settled for $755,000 and agreed to add captions across its library due to a law suit by the National Association of the Deaf. Harvard paid $1.575M to settle its own case over online course materials and video content.
WCAG 2.2 is the current version of the guidelines, published by the W3C in October 2023. It is what a modern procurement asks for, even when the regulation still points to an older version, and it is what we build to.
That is the compliance argument. It is real, and you should take it seriously. It is also the least interesting reason to do this.
Now picture the actual user
Forget the legal category for a minute and picture specific people using your site today.
A woman with advanced ALS navigates with an eye tracker. She looks at a link and holds her gaze, or blinks, to click. Your dropdown menu that opens on hover and closes the instant the pointer drifts is, for her, a door that slams shut every time she reaches for it.
A man who lost the use of his hands dictates to his computer. He says "click Contact Us." If your button contains an icon and no text, or the visible label says "Contact Us" while the code underneath says "btn-cta-3," his command goes nowhere. He cannot see the mismatch. He just knows your site does not work.
A blind attorney runs a screen reader at 400 words per minute. She does not read your page. She pulls a list of its headings and jumps to the one she wants. If your page has forty paragraphs styled to look like headings and no actual heading structure, she has no map. She is in a building with no signs.
A deaf procurement officer hits your product video. Ninety seconds of a voice explaining what you do, no captions, no transcript. He leaves with nothing.
Every one of these people has money, authority, or a signature you want. None of them have eyes, ears, and hands all working the way your designer assumed.
What most people miss
Read that list again and ask who else it describes.
A search engine crawler has no eyes. It cannot see that the bold 24-pixel text at the top of your page is the title. It reads markup. If the title is a <div> with a CSS class, the crawler sees a div.
A crawler has no ears. Your ninety-second video is opaque to it unless there is a transcript or caption file. Whatever you said in that video is not in the index. It might as well not exist.
A crawler has no hands. It cannot hover, drag a slider, or click through a three-step wizard. Content that only appears after a mouse interaction is content it never reaches.
An AI assistant answering a question about your industry works under the same limits, and it is stricter. A search engine had a ranked list of ten blue links to hide behind. An AI assistant returns one answer, and it assembles that answer out of text it can parse, attribute, and trust. Clear headings, real lists, honest tables, captions, alt text, descriptive link text, and clean semantic markup are what make your content extractable. Vague link text like "click here" and "learn more" is a dead end for a screen reader user for the exact same reason it is a dead end for a language model: the phrase carries no information about where it goes.
So here is the thing worth sitting with.
The accommodations you build for a person who navigates without eyes, ears, or hands are the same accommodations that make your content legible to every machine that will ever decide whether to recommend you.
Not similar. The same. Alt text is a screen reader accommodation and an image indexing signal. Semantic heading structure is a screen reader navigation aid and a content hierarchy signal. Captions are a deaf user accommodation and an indexable transcript. Descriptive link text helps a blind user decide whether to follow a link and helps a crawler understand what is on the other side of it. Form labels tied to their inputs help a dictation user and help an AI agent that is trying to complete your quote request on someone's behalf.
You are not doing two jobs. You are doing one job and getting billed for it once.
There is a second-order benefit too. Accessible sites tend to be faster, because the work forces you to fix bloated markup, unlabeled images, and interactions that only exist because somebody wanted to show off. They tend to be more usable on a phone in bright sunlight with one thumb, which describes a large share of your traffic. They tend to survive redesigns better, because the structure is in the content rather than the styling.
That is the ramp. Built under duress, used by everyone, good for the business.
WCAG 2.2 and Section 508: what is the same and what is not
These two get used interchangeably and they are not the same thing. WCAG is a technical standard published by the W3C. Section 508 is U.S. federal law that points at a version of that standard and then adds requirements of its own. The practical differences matter most when you are writing a proposal, filling out an accessibility conformance report, or arguing with a contracting officer.
| WCAG 2.2 Level AA | Section 508 (Revised Standards) | |
| What it is | Voluntary international technical standard from W3C | U.S. federal law, 36 CFR Part 1194 |
| Who it binds | Nobody by itself; adopted by reference into laws worldwide | Federal agencies and anyone selling ICT to them |
| WCAG version | 2.2, published October 2023 | Incorporates WCAG 2.0 Level A and AA by reference |
| Scope | Web content | Web content, electronic documents, software, hardware, support documentation, and support services |
| Beyond WCAG | Nothing. It is the standard. | Adds Functional Performance Criteria (Chapter 3), hardware requirements (Chapter 4), software requirements (Chapter 5), and support documentation requirements (Chapter 6) |
| Documents | Covered only if delivered as web content | Electronic documents must meet WCAG 2.0 A and AA with four listed exceptions. Your PDFs count. |
| Proof of conformance | Self-assessed, no prescribed artifact | Accessibility Conformance Report, usually on a VPAT, commonly requested at proposal time |
| Enforcement | None directly | Section 508 complaints, plus contract and procurement consequences |
| Newest criteria | Six new A/AA criteria not in 2.0: Focus Not Obscured, Dragging Movements, Target Size, Consistent Help, Redundant Entry, Accessible Authentication | Not required, because 508 still points at 2.0 |
| Obsolete criteria | 4.1.1 Parsing removed in 2.2 | Still technically in scope under 2.0 |
The short version for anyone bidding federal work: build to WCAG 2.2 AA and you clear Section 508's web requirements with room to spare, but you are not done. Section 508 also asks about your documents, your software, your hardware, and your help desk. That gap is where proposals get marked down, and it is the part vendors most often skip.
The short version for anyone else: build to WCAG 2.2 AA. It is a superset of WCAG 2.1 AA, which is what ADA Title II requires, so hitting 2.2 satisfies the 2027 and 2028 deadlines and leaves you positioned for whatever comes next.
The WCAG 2.2 AA checklist
Work it in this order. The first section catches the largest share of real failures, and the last section is where the newest requirements live.
Perceivable
- [ ] Every meaningful image has alt text that says what the image conveys, not what it depicts. Decorative images have empty alt (alt="") so screen readers skip them.
- [ ] Every video has synchronized captions. Prerecorded video has an audio description or a text alternative.
- [ ] Every audio-only file has a transcript.
- [ ] Text contrast is at least 4.5:1 against its background, and 3:1 for text 24px and up or 19px bold.
- [ ] User interface components and meaningful graphics have 3:1 contrast against adjacent colors.
- [ ] Color is never the only way information is conveyed. Error states, required fields, and chart series need a second signal.
- [ ] Headings are real headings in code (<h1> through <h6>), in order, with no levels skipped. One <h1> per page.
- [ ] Lists are real lists. Tables are real tables with <th> headers and a scope, used for data and not for layout.
- [ ] The page reflows and stays usable at 400% zoom with no horizontal scrolling at 320px width.
- [ ] Text spacing can be increased (line height 1.5, paragraph spacing 2x) without losing content.
- [ ] Content works in both portrait and landscape.
Operable
- [ ] Every interactive element is reachable and usable by keyboard alone. Tab through the whole page and confirm.
- [ ] No keyboard traps. You can always tab back out of a widget, including modals and embedded players.
- [ ] Focus is always visible, and the visible focus indicator is never hidden behind a sticky header, cookie banner, or chat widget. (2.4.11 Focus Not Obscured, new in 2.2)
- [ ] Tab order follows the visual and logical reading order.
- [ ] A skip link lets keyboard users jump past the navigation to the main content.
- [ ] Anything you can do by dragging, you can also do with a single click or tap. (2.5.7 Dragging Movements, new in 2.2)
- [ ] Touch targets are at least 24 by 24 CSS pixels, or have adequate spacing around them. (2.5.8 Target Size, new in 2.2)
- [ ] Link text describes its destination on its own. No bare "click here," "read more," or "learn more."
- [ ] Page titles are unique and descriptive.
- [ ] Users can pause, stop, or hide anything that moves, blinks, autoplays, or auto-updates.
- [ ] Nothing flashes more than three times per second.
- [ ] Time limits can be turned off, adjusted, or extended.
- [ ] Multiple ways exist to find a page (navigation, search, sitemap).
Understandable
- [ ] The page declares its language (<html lang="en">), and any passage in another language declares its own.
- [ ] Navigation is consistent in placement and labeling across pages.
- [ ] Help options (contact link, chat, phone number) appear in the same relative place on every page that has them. (3.2.6 Consistent Help, new in 2.2)
- [ ] Nothing changes context automatically on focus or input. No auto-submitting on select, no surprise redirects.
- [ ] Every form field has a visible, programmatically associated <label>. Placeholder text is not a label.
- [ ] Error messages identify the field, say what is wrong in plain language, and suggest a fix.
- [ ] Legal, financial, and data-deletion submissions are reversible, checked, or confirmed before they commit.
- [ ] Information the user already entered is auto-populated or selectable rather than retyped in a later step. (3.3.7 Redundant Entry, new in 2.2)
- [ ] Authentication does not require solving a puzzle, transcribing a code, or recalling a password from memory without an alternative. Support password managers and paste. (3.3.8 Accessible Authentication, new in 2.2)
Robust
- [ ] Markup is valid, with no duplicate IDs and properly nested elements.
- [ ] Custom components expose the correct name, role, and value to assistive technology. Use native HTML elements before reaching for ARIA.
- [ ] Status messages, live search results, and form confirmations are announced without moving focus (aria-live, role="status").
- [ ] Landmark regions are present: <header>, <nav>, <main>, <footer>.
Verification
- [ ] Run an automated scan (axe, WAVE, Lighthouse, Pa11y) on templates and key pages. Expect it to catch roughly a third of real issues.
- [ ] Do a full keyboard-only pass on the most important user paths.
- [ ] Test with an actual screen reader: NVDA or JAWS with Chrome or Firefox, VoiceOver with Safari.
- [ ] Zoom to 400% and work through the same paths.
- [ ] Check the PDFs. On a federal site they are in scope and they are usually the worst thing on the domain.
- [ ] Get a person who uses assistive technology every day to try it. This finds things no tool and no checklist will.
Automated tools are the smoke alarm, not the fire inspection. Any vendor who hands you a green Lighthouse score and calls the site compliant is telling you what they tested, not what works.
Where this lands
We do this work for federal agencies, and the pattern is consistent. The ones who treat accessibility as a certification to pass end up with a site that clears a scanner and still frustrates people. The ones who treat it as a design constraint from the first wireframe end up with a site that is faster, cleaner, easier for their own content team to maintain, and considerably easier for machines to read and recommend.
The city that built the curb cut was not thinking about strollers. It got them anyway. The benefit was never limited to the group named in the regulation, and the organizations that figured that out early stopped arguing about the cost.
Your website works the same way. Build the ramp.
Find out where your site stands
If you are looking at the April 2027 ADA Title II deadline, a Section 508 requirement in an upcoming solicitation, or just a suspicion that your site would not survive a keyboard-only pass, that is a short conversation and a scoped audit.
Reach out to Agileana for a straight read: what fails today, what it costs to fix, what is a one-hour change versus a template rebuild, and how much runway you have.
Agileana is a Service-Disabled Veteran-Owned Small Business specializing in Drupal for federal agencies and mission-driven organizations, holding GSA MAS, NASA SEWP VI, and agency-specific BPAs with the U.S. Courts, NARA, and DOT.
Sources
- W3C, Web Content Accessibility Guidelines (WCAG) 2.2, October 5, 2023
- Section508.gov, Applicability & Conformance Requirements
- Section508.gov, Access Board Updates Requirements for Information and Communication Technology
- Accessible.org, DOJ Extends ADA Title II Web Compliance Deadline One Year, April 2026
- Angela Glover Blackwell, The Curb-Cut Effect, Stanford Social Innovation Review, Winter 2017
- Deque University, WCAG 2.2 Updates