Accessibility Statement | Pikes Peak Web Designs

Last updated: April 25, 2026

Conformance target: Web Content Accessibility Guidelines (WCAG) 2.2, Level AA, plus Section 508.

Conformance status: partially conformant. Most of the site fully meets the standard; specific known limitations are listed below.

My commitment

Accessibility is a baseline on every site I design and build, including this one. My working standard is WCAG 2.2 Level AA, the Web Content Accessibility Guidelines from the W3C. This covers color contrast, keyboard navigation, screen-reader support, focus visibility, motion, language, and clear labeling. It's the same standard I write into my client agreements; not aspirational, contractual.

Beyond the legal floor, I treat accessibility as a quality marker. A site that fails screen-reader users tends to fail search-engine crawlers, color-blind visitors, mobile keyboards, and aging eyes too. Building accessibly means building well.

What I do on every site

Real contrast ratios. I verify every text/background combination against WCAG AA (4.5:1 for normal text, 3:1 for large text and UI components) using the TPGi Colour Contrast Analyser. Every combination, every theme.
Full keyboard navigation. Every interactive control is reachable by Tab and operable by keyboard alone. Focus rings are visible (3 px gold ring at 3 px offset) and predictable. Tab order matches visual order.
Semantic HTML. Headings in order, landmarks labeled, lists that are actually lists, buttons that are actually buttons. Screen readers get a clean structure to navigate by region or heading.
Skip links. "Skip to content" appears as the first focusable element on every page so keyboard and screen-reader users can bypass the navigation.
Landmarks. Each region of the page (header, nav, main, aside, footer) is a real HTML5 landmark, with aria-label where multiple instances exist.
Image alt text. Decorative SVGs are hidden from assistive technology with aria-hidden="true" and focusable="false". Meaningful images get real alt text. Complex images (charts, diagrams) get long descriptions.
Motion respected. Animations honor prefers-reduced-motion. If your system says slow things down, I do; transitions and movement effects are disabled.
Forms with proper labels. Every field has a visible label, not just placeholder text. Errors are announced via role="alert" and explained in plain language with a path to fix them.
Light and dark themes. Color pairs meet contrast targets in both modes. The toggle has three states (Light, System, Dark) with the user's choice saved across sessions.
44 x 44 CSS pixel touch targets. Interactive elements are comfortably large on a phone. Spacing between adjacent targets prevents accidental taps.
Forced-colors mode (Windows High Contrast). The site renders legibly when the OS forces colors; I use forced-colors: active media queries where component styling needs to defer to system colors.
Screen reader hidden text via .sr-only utility class for context that's visually obvious but missing from a screen-reader's serial reading order.
Language attribute set on <html lang="en"> so screen readers use the right pronunciation engine.
Color is never the only carrier of meaning. Status badges combine color with an icon or label; required form fields have an asterisk plus a visible label suffix.
aria-current="page" on the active nav link so screen-reader users know where they are.

WCAG 2.2 highlights we specifically test

WCAG 2.2 added nine new criteria over 2.1. I test the ones most relevant to a marketing site:

2.4.11 Focus Not Obscured (AA). The focused element is never fully hidden under a sticky header, modal, or cookie banner.
2.4.12 Focus Not Obscured (AAA). No part of the focused element is hidden. I treat this as a hard target on this site.
2.5.7 Dragging Movements (AA). No interaction depends on dragging. Where I use carousels, they have button alternatives.
2.5.8 Target Size Minimum (AA). 44 x 44 px minimum on every interactive control.
3.3.7 Redundant Entry (A). If a form asks for the same information twice in a multi-step flow, we pre-fill or skip the second prompt.
3.3.8 Accessible Authentication (AA). N/A; I do not have user authentication on the site.

How I test

Every site, before launch and on every significant change, we run through:

Automated audits: Lighthouse (Chrome DevTools), axe DevTools, and WAVE. Zero criticals and zero serious issues required to ship.
Keyboard-only navigation from the first focusable element to the last on every page. Every interactive control reachable, operable, and visibly focused.
Screen-reader testing: VoiceOver on macOS and iOS; NVDA on Windows. I read every page top to bottom to catch landmark, heading, and label issues.
Browser zoom up to 200% without horizontal scrolling and without content clipping.
Color-contrast verification on every text/background combination in both light and dark themes.
Reduced-motion verification with the OS-level setting enabled. All animations and transitions disabled when set.
Forced-colors testing in Windows High Contrast mode.
Manual review of any new component for: heading order, label binding, focus order, ARIA usage, and color independence.

Known limitations

I am not perfect and I do not pretend to be. Current known limitations on this site:

Demo sites under /demo/ share most of my accessibility posture but are designed to showcase distinct typographic and visual systems for different industries. Each demo's own accessibility statement documents any deviations specific to its design system.
Third-party embeds (Pagefind search UI, Tippy.js tooltips). I have configured both to use accessible defaults, but their internal markup is theirs to maintain. I monitor releases and audit on each upgrade.
PDF documents (if any are linked from the site) are not always tagged for screen readers. Where we link to a PDF, we provide an HTML alternative or a plain-text summary.

If you find something else on the site that does not work for you, please tell me. Accessibility issues skip the queue and get handled fast on most business days, and the fix tends to land in short order from there.

Standards we conform to

WCAG 2.2 Level AA: the W3C's accessibility standard.
Section 508 of the US Rehabilitation Act, as updated in 2018 to align with WCAG 2.0 AA.
EN 301 549: the European accessibility standard for ICT, which references WCAG 2.1 AA. I exceed this with my 2.2 AA target.
ADA Title III: while the ADA does not formally specify WCAG, US courts have routinely treated WCAG AA as the de facto standard. My work is built to that bar.

Assistive technologies I test against

Screen readers: VoiceOver (macOS, iOS), NVDA (Windows), TalkBack (Android, when relevant to a build).
Magnification: macOS Zoom, Windows Magnifier, browser zoom up to 400%.
Speech input: Voice Control (macOS, iOS), Dragon NaturallySpeaking (Windows).
Keyboard-only: every interaction tested without a pointing device.

How to reach me

If any part of this website isn't working for you, or if you need information in a different format (large text, audio, printed, plain text email instead of an HTML form), contact me any way you like. I will respond quickly and work with you to fix it.

Email: hello@pikespeakwebdesigns.com with the subject "Accessibility". I tend to reply quickly on most business days.
Call or text: (928) 315-9094. Direct line, no menu.
Quick form: /ask/ with topic set to "Accessibility issue or feedback". Same inbox.

If I can't resolve the issue, you can also escalate to:

The US Department of Justice's ADA Information Line: 1-800-514-0301 (voice) or 1-833-610-1264 (TTY).
Your state's protection and advocacy organization.

My commitment on client sites

Every site I build for a client ships with an accessibility statement like this one, tuned to that business. It's one of the operational pages I include on every project, at no extra cost and without counting against your page total. Accessibility is part of the deliverable, not an upsell.

Everyone should be able to use the web.