01
Semantic HTML first
Every page uses real landmarks: header, nav, main, footer, with one H1 per page and a logical H2 to H3 outline. Screen readers and SEO crawlers see the same structure your visitors see.
No div soup, no role="button" on a span.
Trust Accessibility WCAG 2.1 AA
Accessibility built into the primitives, not added on top.
Every component in this site, and every component we ship for clients, is designed to meet WCAG 2.1 AA out of the box. This page documents what that means in practice and how to verify it.
Tested in NVDA, VoiceOver, keyboard-only, and reduced-motion modes
Why this matters
Accessibility is not a feature. It is a baseline.
Roughly 15 percent of the global population has a disability that affects how they use the web. For enterprise audiences in government, education, healthcare, and regulated industries, accessibility is also a procurement requirement and an ADA lawsuit-prevention measure. The work is the same either way.
We build accessibility into the component primitives so every new page inherits it automatically. Editors and copywriters never have to remember to "make it accessible" because the structure already is.
What we ship
Accessibility built into the design system.
02
Keyboard navigable end to end
Every interactive element is reachable by Tab in a logical order. Skip links bypass repetitive navigation. Focus indicators are clearly visible at 3px on all backgrounds.
You can drive the site without a mouse.
03
Reduced motion respected
When a visitor sets prefers-reduced-motion, all animations and transitions cap at 0.01ms. Auto-playing media is never used. Scroll-jacking never used.
Vestibular disorders are not triggered by visiting our site.
04
Color contrast verified
Body text holds 4.5:1 against background. Large text and UI controls hold 3:1. Active focus indicators hold 3:1 against adjacent colors. Verified per page, not assumed.
Low-vision visitors can read every word.
05
Touch targets sized
On mobile widths, every interactive element is at least 44 by 44 pixels per WCAG 2.5.5. Buttons spaced so adjacent targets do not overlap. Form fields have generous tap surfaces.
Motor-impaired visitors can tap accurately.
06
Forms with real labels
Every input has an explicit label, required state announced, error states described, fieldset and legend used for radio groups. No placeholder-as-label patterns.
Screen readers narrate the form correctly.
WCAG 2.1 AA
the standard we design, build, and verify against on every project
Plus targeted AAA for color contrast and link distinction where it does not compromise the design.
Standards we follow
The actual checklist.
- 1.1.1 Non-text content · Every image has alt text or is marked decorative with aria-hidden.
- 1.3.1 Info and relationships · Semantic HTML for headings, lists, tables, forms.
- 1.4.3 Contrast (Minimum) · 4.5:1 for body text, 3:1 for large text and UI.
- 1.4.10 Reflow · Pages reflow at 320 CSS pixels without horizontal scroll.
- 1.4.11 Non-text contrast · UI components and graphical objects hold 3:1.
- 1.4.12 Text spacing · Reading remains intact with custom user spacing.
- 2.1.1 Keyboard · All functionality available via keyboard.
- 2.1.4 Character key shortcuts · No single-key shortcuts that conflict with assistive tech.
- 2.3.3 Animation from interactions · prefers-reduced-motion respected.
- 2.4.1 Bypass blocks · Skip links to main, navigation, footer.
- 2.4.3 Focus order · Tab order matches visual order.
- 2.4.7 Focus visible · Visible 3px outline on every focusable element.
- 2.5.5 Target size (Enhanced) · 44 by 44 pixels minimum on mobile.
- 3.1.1 Language of page · lang attribute on every page.
- 3.3.1 Error identification · Form errors described in text.
- 3.3.2 Labels or instructions · Every form input has an explicit label.
- 4.1.2 Name, role, value · ARIA used correctly where native HTML cannot express the intent.
- 4.1.3 Status messages · Live regions for dynamic content updates.
Common questions
Frequently asked
-
What standard do you target?
WCAG 2.1 Level AA. The same standard required by ADA, AODA, EN 301 549, Section 508. We design and ship to AA, then verify with automated audits and screen-reader testing on real assistive tech.
-
Do you provide a VPAT or accessibility statement for client work?
Yes. For enterprise engagements we deliver a written accessibility statement and a VPAT 2.5 conformance report on request. Government and education clients usually need this for procurement.
-
How do you test accessibility on client builds?
Three-layer test: automated scan with axe-core in CI on every build, manual keyboard pass on every key flow, screen-reader walkthrough with NVDA on Windows or VoiceOver on macOS for any custom component or interactive flow.
-
What if I find an accessibility issue on this site?
Email connect@wbcomdesigns.com or note it in any project enquiry. We treat accessibility regressions as priority bugs. Fixes go out within five business days for confirmed AA violations on our own site.
-
Do AI-generated pages still meet accessibility standards?
Yes. Our component library bakes accessibility into the primitives: every button, link, form field, and landmark element comes pre-built with the right semantics, ARIA, and focus handling. AI-generated pages compose those primitives. Accessibility is structural, not editorial.
Building something that needs to be accessible?
We can help, audit, or remediate.
New project, accessibility audit on existing code, or compliance documentation for procurement. We do all three.