There are two ways a team can meet Section 508. The first: design the product, build the product, run a scanner, and fix what it flags until the report turns green. The second: treat accessibility as a constraint that shapes the design from the first wireframe, the way performance budgets or security requirements do.
Both can produce a passing audit. Only one produces good software. Having done federal work under both regimes — early in our history, we did it the first way, like everyone — we're firmly in the second camp now, and the difference shows up everywhere: in the design files, the codebase, the audit timeline, and the product itself.
What 508 actually asks for
A quick grounding, because the folklore is worse than the law. Section 508 of the Rehabilitation Act requires federal agencies to make their information and communication technology accessible. Since the 2017 refresh, the technical standard incorporates WCAG 2.0 Level A and AA — the same criteria as mainstream web accessibility — and in practice, agencies increasingly evaluate against the newer WCAG 2.1 and 2.2 criteria as well. Vendors document conformance in an ACR (Accessibility Conformance Report, built on the VPAT template), and procurement teams read them more carefully every year.
Note what that means: 508 compliance is a procurement gate. An honest, strong ACR is a competitive asset; a vague one gets your bid discarded by reviewers who have learned exactly what evasive conformance language looks like. That alone should move accessibility out of the "cleanup" phase and into the design phase — but the better argument is what it does to the product.
The checklist mindset fails at the wireframe
Here's the structural problem with audit-at-the-end: by the time a scanner runs, the expensive decisions are already made.
A low-contrast text style isn't a bug — it's a brand decision that got ratified in a style guide, propagated through two hundred screens, and now costs a redesign to fix. A custom dropdown that can't be operated by keyboard isn't a missing attribute — it's a component architecture problem. Meaning conveyed only by color, focus order that fights the visual order, a data table built out of divs — these are design-phase decisions wearing engineering-phase costumes. Remediating them after the fact means either doing the design work twice or shipping the awkward patch version.
So we moved the constraint upstream. It's cheaper there, and it's also where it belongs.
Contrast and focus are brand decisions
Two examples of what "accessibility as design input" means concretely.
Contrast. WCAG's 4.5:1 ratio for body text isn't a suggestion to check later; it's a boundary on the palette itself. When we build a design system for federal work, every approved foreground/background pairing is contrast-tested before it enters the token set — the tokens are the audit. Designers pick from combinations that cannot fail, rather than remembering rules. The discipline pays off in unexpected ways: it forces real decisions about visual hierarchy instead of the lazy gradient of five gray text colors, and the resulting palettes read as more confident, not less. (It's also why muted text on this very site stays above the threshold in both themes.)
Focus. Every interactive element needs a visible focus indicator — so make it a signature instead of an apology. The default blue outline looks like an afterthought because it is one. A deliberate focus style, designed in the brand's accent with proper offset and contrast against every surface it can land on, reads as craftsmanship to sighted keyboard users and works for everyone else. Focus order, skip links, and landmark structure get decided in design review, when they're a conversation, not in remediation, when they're a refactor.
Scanners find the easy third
Automated tools — axe, WAVE, Lighthouse's accessibility audit — are genuinely useful, and we run them in CI so regressions surface in pull requests. But the widely-replicated finding, consistent with our own experience, is that automated scanners detect only a minority of real accessibility issues — roughly a third to a half depending on the study and the site. A scanner can verify an image has alt text; it cannot tell you the alt text is image_final_v2.png. It can find a missing label; it can't tell you the form's error message is announced to nobody.
So the test plan on every federal engagement goes beyond the scanner, every release:
- A keyboard-only pass. Unplug the mouse, complete every critical user journey. Can you see where you are at all times? Can you get everywhere, and back?
- Screen reader sessions. Actual task completion with NVDA on Windows and VoiceOver on macOS and iOS — because assistive-technology behavior differs by pairing, and because listening to your own product is the fastest empathy lesson in software.
- 200% zoom and reflow. Does the layout hold at 200% text scaling? Does content reflow at narrow widths without horizontal scrolling?
- Reduced motion and forced colors. Animations honor
prefers-reduced-motion; the UI survives Windows High Contrast Mode without disappearing borders.
None of this is exotic. It's a few hours per release cycle once it's routine — and it's the difference between an ACR you can defend in front of an agency evaluator and one you hope nobody reads closely.
Constraints are where the craft is
The quiet secret is that 508 work makes the product better for everyone, in ways that have nothing to do with disability. Captions serve the person watching in a waiting room. Keyboard operability serves the power user who never touches the mouse. Clear focus states serve anyone on a laggy remote desktop. Semantic structure serves search engines and screen readers with the same markup. Reflow discipline is just responsive design done honestly. The curb-cut effect is real, and we see it in analytics on every project: the "accessibility" work gets used constantly, by everyone.
Good design has always been design under constraint — the canvas size, the material, the budget. Accessibility is simply another material property of software, and designers who treat it as one produce sharper work than designers who treat it as a tax. That's the actual thesis of this post: 508 isn't the reason the work is worse. Handled early, it's frequently the reason the work is better.
The checklist still exists, of course. We still produce the ACR, still run the scanners, still track criteria. But by the time the checklist arrives, it should be a transcript of decisions already made — not a to-do list of decisions being unmade.