Accessibility as an Engineering Discipline
Roughly one in four American adults lives with a disability that can affect how they use the web — vision, motor, cognitive, auditory. For a local business, that is not an abstraction; it is a measurable slice of every month's would-be customers. Accessibility done properly isn't a compliance checkbox bolted on at the end. It's a set of engineering decisions made at build time, most of which cost nothing when made early and are expensive to retrofit later.
The standard: WCAG 2.2 AA
The Web Content Accessibility Guidelines (W3C) are organized around four principles — perceivable, operable, understandable, robust — with three conformance levels. Level AA of WCAG 2.2 is the de facto legal and professional baseline: it's what the ADA's web guidance, Section 508, and the European Accessibility Act all converge on, and it's the level BYHS builds to. Level AAA is aspirational for specific content, not a site-wide target even by W3C's own admission.
The engineering core
Semantic structure is 80% of the work
Screen readers navigate by landmarks and headings the way sighted users scan visually. The
same markup that makes a page legible to assistive technology — one <h1>, ordered
heading levels, <nav>/<main>/<footer> landmarks, real <button>
elements instead of clickable <div>s, labeled form fields — is precisely what search
engines and AI systems parse. Accessibility and machine legibility are the same investment
(we've written about that overlap).
ARIA is a repair kit, not a foundation
The W3C's own first rule of ARIA: don't use ARIA if native HTML can do it. An
aria-label on an icon-only link, aria-current on active navigation, aria-hidden
on decoration — good. Div-soup rebuilt into a fake button with role attributes — worse than
the native element in every dimension. Audits routinely find sites where added ARIA
introduced the errors.
Contrast is arithmetic, not taste
AA requires 4.5:1 for body text and 3:1 for large text and UI components. This is computable at design time — no judgment calls, no excuses. Note what the rule does not require: garish colors. This site's gray-on-black palette passes throughout; the discipline is checking muted text (the classic failure) rather than assuming.
Keyboard paths and focus
Everything a mouse can do, Tab/Enter/Escape must do: visible focus indicators (WCAG 2.2 strengthened these), logical tab order, no keyboard traps, a skip link on nav-heavy layouts. Testing it takes five minutes — unplug the mouse and try to book, call, or buy.
Motion respects the visitor
Vestibular disorders make parallax and large animated movement physically unpleasant.
Every animation on a BYHS site — including the cursor glow on this page — sits behind a
prefers-reduced-motion media query and simply turns off when the visitor's OS asks.
Motion is a garnish, never a requirement.
The business case, honestly stated
Google does not use WCAG conformance as a ranking factor, and claiming otherwise is snake oil. The real connections are indirect but consistent: the semantic structure accessibility demands is what crawlers parse best; accessible pages tend to be lighter and faster; alt text is how image search understands photos; and every barrier removed is a customer who completes the call, the booking, the order. Add the legal exposure — U.S. web accessibility lawsuits run in the thousands per year, overwhelmingly against small and mid-size businesses — and "we'll get to it later" is simply mispriced risk.
How we verify
- Automated scans (axe-core, Lighthouse accessibility audit) on every build — knowing they catch roughly a third of real-world issues.
- Manual keyboard pass and screen-reader spot check on new templates.
- Contrast checked at design-token level, so a passing palette can't drift page by page.
- Reduced-motion verified by toggling the OS setting, not by trusting the CSS.