Accessibility | Apex Wraps

1. Our aim

This site was built targeting the Web Content Accessibility Guidelines (WCAG) 2.2 at Level AA. That is the standard the work was measured against during development; it is not a certification, and no formal third-party audit or assistive-technology testing has been carried out on this build.

2. What was implemented

Semantic HTML landmarks, a single h1 per page and heading levels that run in order without skipping
A skip link to the main content as the first focusable element
Visible focus indicators on every interactive element; focus styling is never removed
Full keyboard operation, including arrow-key navigation across the booking calendar's day grid
Touch and pointer targets of at least 44 × 44 px
Text contrast of at least 4.5:1, and at least 3:1 for interface boundaries and meaningful icons
Status, error and selection states conveyed by text or shape as well as color — never color alone
Form fields with visible persistent labels, helper text, inline error messages tied to their field, and an error summary that receives focus after a failed submission
Live-region announcements when a date or time is selected, without moving focus
Descriptive alternative text on meaningful images; decorative images and icons hidden from assistive technology
Full support for prefers-reduced-motion: the scrolling hero animation and all reveal transitions are disabled, and the hero collapses to a static image rather than leaving three screens of empty scroll
The site remains readable and navigable with JavaScript disabled

3. Known limitations

The scroll-driven hero animation conveys atmosphere rather than information. Its content is fully described by the alternative text on its first and last frames, but visitors who cannot scroll will not see the transition itself.
Two decorative background videos (the Process section and the Contact page) autoplay on a loop. Both are muted, carry no information, and are hidden from assistive technology, and both are replaced by a still image when the visitor's system asks for reduced motion. Neither has an in-page pause control, so a visitor who finds motion distracting but has not set that system preference cannot stop them. This is a known gap.
No testing has been performed with screen readers, voice control or switch access on this build.

4. Before this design goes live

A real deployment should be tested with at least one screen reader on each platform (NVDA or JAWS on Windows, VoiceOver on macOS and iOS, TalkBack on Android), verified at 200% zoom and 400% reflow, checked for keyboard traps, and reviewed by someone who uses assistive technology daily. Automated tooling catches roughly a third of real issues and should not be the only check.

5. Feedback

Accessibility problems with this demonstration can be reported to Black Oak Consulting.