Accessibility Statement

Last Updated: August 1, 2026

Our Commitment to Accessibility

Van Alstine Construction is committed to making our website usable and comfortable for everyone, regardless of ability or the technology they use to browse the web. We believe that access to information about our services, our work, and how to reach us should not be a barrier for any visitor.

We take a hands-on, first-party approach to accessibility — meaning that rather than purchasing a generic third-party overlay or widget and bolting it on top of our site, we have built our accessibility tools directly into the website from the ground up. This matters, and we want to explain exactly why.

1. Why We Don't Use a Third-Party Accessibility Overlay

Third-party accessibility overlays (sometimes marketed as "one-click WCAG compliance") are external scripts — typically a JavaScript file loaded from another company's servers — that sit on top of a website and try to fix accessibility issues after the fact. While they may seem like a convenient solution, they come with significant drawbacks:

• They don't know your website. A generic overlay has no understanding of your specific content, layout, or interactive elements. It applies blanket transformations that frequently conflict with or break existing design and functionality.
• They load from a third-party server. Every page load involves a network request to an external company's infrastructure, introducing performance overhead, an additional point of failure, and a dependency you don't control.
• They collect data. Many overlay providers collect usage analytics about your visitors as part of their service — data that leaves your site without your users' full awareness.
• They can be fragile. Overlays often break when a website is updated, because they rely on guessing at element structure rather than knowing it.
• Legal exposure remains. No overlay can guarantee compliance. Accessibility lawsuits have named websites that used overlays, because automated tools cannot replace genuine inclusive design.

For these reasons, we chose a different path entirely.

2. Our First-Party, Integrated Accessibility Widget

The accessibility panel on this website — the floating blue button in the bottom corner of every page — was designed and coded by us, specifically for this website. It is loaded as a same-origin JavaScript file (JS/accessibility.js) served directly from our own server. No external company is involved, no third-party script runs, and no data leaves your device.

Because the widget is integrated into the site from the start rather than layered on top of it, it works with the site's real structure. Every feature targets the actual CSS custom properties, layout classes, and element hierarchy of this website — not a generic approximation of what a website might look like.

What the Widget Offers

The accessibility panel provides the following controls, all of which are applied through the site's own stylesheet and persist across your visit via your browser's local storage:

• Text size adjustment — A stepper that scales all text proportionally in five steps (100% up to 150%). This scales the root font-size, so every element on the page — headings, body copy, labels, buttons — grows in unison and the layout reflows correctly rather than just enlarging one piece.
• Small-text booster — A separate control that raises only small text on the page to a comfortable minimum, without inflating headings or large display type. An "Auto" mode computes a fluid minimum based on your current display resolution, so fine print stays legible whether you're on a laptop screen or an unscaled 4K monitor. Fixed S, M, and L steps are also available for users who prefer a specific size.
• Color filter — A cycler offering six visual filters: None, Grayscale, Invert, High Saturation, Low Saturation, and Dark (Sepia). These are applied to the entire page through a CSS filter on the HTML root element — a deliberate technical choice that prevents the floating widget button from being repositioned or obscured, a known failure mode when filters are applied naively to the document body.
• Dark / Light theme — A toggle between dark and light themes, mirrored from the footer control so you can reach it without leaving the accessibility panel.
• High contrast mode — Intensifies foreground/background contrast ratios across the entire site, targeting text, borders, interactive elements, and the navigation.
• Highlight links — Adds a persistent underline and distinct color to all hyperlinks on the page, making them visually unambiguous even for users who may have difficulty distinguishing links from surrounding text.
• Readable font — Switches all body text to a dyslexia-friendlier typeface with wider letter spacing, improving readability for users with dyslexia or related reading difficulties.
• Text spacing — Increases line height, letter spacing, and word spacing across all body copy, meeting or exceeding the WCAG 2.1 Success Criterion 1.4.12 (Text Spacing) spacing values.
• Keyboard focus highlight — Adds a high-visibility focus ring to every keyboard-focusable element on the page, making it easy for keyboard-only users to see exactly where focus is at all times.
• Hide images — Removes all decorative and content images from the visible page, reducing visual noise and improving performance for users on constrained connections or who find imagery distracting.
• Reduce motion — Pauses or eliminates all CSS transitions, animations, and JavaScript-driven motion including the hero slideshow and scroll-driven header animations. This is essential for users with vestibular disorders or motion sensitivities. It also exposes a window.__a11yReduceMotion flag and fires a custom browser event so every animation script on the site can respond correctly.
• Larger cursor — Replaces the default browser cursor with a significantly larger custom cursor, useful for users with motor control or vision impairments who have difficulty tracking a small pointer.
• Reset all — Clears every accessibility preference saved for this site from your browser's local storage and returns the page to its default appearance in a single click.

3. System-Level Preference Detection

Modern operating systems allow you to declare accessibility needs at the system level — for example, requesting reduced motion, higher contrast, or a dark color scheme. Our widget reads these declarations automatically using the browser's matchMedia API and activates the relevant features on your first visit, without you needing to open the panel at all:

• Prefers reduced motion (prefers-reduced-motion: reduce) → "Reduce motion" is enabled automatically.
• Prefers more contrast (prefers-contrast: more) → "High contrast" is enabled automatically.
• Prefers reduced transparency (prefers-reduced-transparency: reduce) → "Hide images" is enabled automatically.
• Prefers dark color scheme (prefers-color-scheme: dark) → The dark theme is enabled automatically (handled by the site's broader theming system).

Importantly, these are defaults, not forced settings. If you prefer to manually override any system preference for this site — for example, enabling high contrast on the page even if your OS doesn't request it, or disabling reduce-motion on our site specifically — the widget panel lets you do exactly that. Your explicit choice in the panel always takes precedence over the detected system setting.

The widget also listens for live changes to these system preferences mid-session. If you toggle your OS dark mode while the page is open, the site updates immediately.

4. How Preferences Are Saved

All accessibility settings are saved in your browser's localStorage under a single key (vac_a11y) as a small JSON record. This means:

• Your settings persist across pages — Once you set a preference, it applies to every page on this site for as long as you use this browser.
• Nothing is sent to our servers — Your accessibility choices are stored exclusively on your own device. We never see them, log them, or transmit them anywhere.
• No accounts or cookies required — You don't need to log in or accept a cookie banner for your preferences to be remembered.
• You can clear them at any time — Use the "Reset all" button in the accessibility panel, or clear your browser's local storage for this site through your browser settings.

5. Broader Accessibility Design Practices

Beyond the widget, accessibility is considered throughout the site's design and markup:

• Semantic HTML — We use proper heading hierarchy (<h1> through <h4>), landmark elements (<main>, <nav>, <footer>, <section>), and meaningful element choices throughout so screen readers can navigate the page structure efficiently.
• Skip link — A "Skip to main content" link is the very first focusable element on every page, allowing keyboard and screen-reader users to bypass the navigation and jump directly to the page content.
• ARIA attributes — Interactive components including the navigation, accessibility panel, modals, and review forms use appropriate aria-* attributes to communicate roles, states, and properties to assistive technology.
• Keyboard navigation — All interactive elements on the site are reachable and operable via keyboard alone. Focus management is handled carefully in dynamic components to prevent focus from becoming lost or trapped unexpectedly.
• Color contrast — Text and interactive element colors are chosen to meet or exceed WCAG 2.1 AA contrast ratio requirements (4.5:1 for body text, 3:1 for large text and UI components) in both the light and dark themes.
• Alt text on images — Content images carry descriptive alternative text; purely decorative images are marked with empty alt="" attributes so screen readers skip them.
• Form labels — All form inputs are associated with visible labels and include descriptive aria-label or aria-describedby attributes where needed.
• Responsive design — The site reflows gracefully at all viewport sizes and supports browser-level text zoom up to 200% without loss of content or functionality.
• No keyboard traps — Focus is never locked into a component without a clear keyboard path to escape (such as pressing Escape to close a panel or modal).

6. How We Test

This website is designed, built, and maintained by a single developer. There is no QA team, no automated test suite, and no release pipeline with separate review stages. What there is, is a genuine commitment to testing everything personally before it ships — not just accessibility features, but every piece of functionality: forms, navigation, the review system, animations, the admin dashboard, layout at different screen sizes, and all the site's interactive components. When something new gets built or something existing gets changed, it gets tested.

Testing is done by hand, on real hardware, across a deliberately wide spread of devices, operating systems, screen resolutions, and browsers. The goal is to catch issues before a real visitor does, and to ensure the site behaves consistently and correctly for as many people as possible, regardless of what they use to access it.

Devices

Every site feature is verified on a mix of hardware that reflects the range of devices real visitors are likely to use — from constrained budget hardware to high-end machines:

• Low-end laptops — Older or budget machines where CPU, memory, and GPU headroom is limited, ensuring that animations, JavaScript-driven interactions, and layout rendering do not become sluggish or broken on less capable hardware.
• High-end MacBooks — Including a 16-inch MacBook Pro with M1 Max, representing the top end of the laptop market in terms of both display resolution and processing power.
• Older mobile phones — Devices with smaller screens, older rendering engines, and slower CPUs, where touch targets, text sizes, viewport scaling, and scroll behavior are most likely to reveal problems.
• iPads — Tablet-scale viewports with touch interaction. iPadOS testing is planned for upcoming cycles, including keyboard-attached usage.

Operating Systems

Rendering, font smoothing, system font stacks, scroll behavior, and system-level accessibility settings all vary meaningfully between operating systems. Testing covers:

• macOS — Primary development platform; tested extensively including system dark mode, reduced motion, and high contrast preferences via System Settings.
• Windows — Tested for layout consistency, font rendering differences, ClearType vs. macOS antialiasing, and Windows-specific scroll and focus behavior.
• Linux — Tested on desktop distributions to catch differences in font rendering pipelines and GTK-level interface behavior that can expose CSS edge cases.
• iOS — Mobile Safari on iPhone, including pinch-to-zoom, viewport meta behavior, and touch-target sizing.
• Android — Chrome and other browsers on Android phones, covering the most widely used mobile OS globally.
• iPadOS — Planned — Tablet layout and split-screen behavior, with and without a physical keyboard.

Screen Resolutions

Layout, text sizing, and the accessibility widget are tested across a deliberate range of display resolutions and pixel densities:

• 720p (1280×720) — Low end of common laptop and external monitor resolutions; verifies nothing clips, overflows, or becomes illegibly small.
• 1080p (1920×1080) — The most common desktop resolution; the primary baseline for visual design decisions.
• Up to the native display of a 16-inch MacBook Pro with M1 Max — One of the highest-density laptop displays available (3456×2234 at 2× DPR). The small-text booster's "Auto" mode is specifically calibrated for displays at this end of the spectrum to ensure fine print stays legible.

Intermediate resolutions (1440p, 1366×768, etc.) are also checked by resizing browser windows during testing, and responsive breakpoints are verified to transition smoothly.

Browsers

Testing spans all major browser rendering engines, not just the dominant Chromium-based vendors:

• Safari — Apple's browser, used by a significant share of iPhone and Mac visitors. Safari has its own WebKit engine with its own CSS and JavaScript behavior, and has historically been stricter about certain web standards.
• Firefox — Mozilla's Gecko-engine browser, which interprets some web standards differently from Chromium and has historically been more proactive about accessibility APIs.
• Chrome — The most widely used browser globally; the Chromium engine is the baseline that underlies most other browsers on this list.
• Edge — Microsoft's Chromium-based browser; tested to confirm cross-Chromium consistency and to check for Edge-specific quirks.
• Brave — A privacy-focused Chromium browser; tested partly because its aggressive content blocking can interact unexpectedly with site scripts — another reason we avoid third-party dependencies.
• Opera — Tested for Chromium compatibility and Opera-specific interface differences.
• Orion — A WebKit-based browser for macOS and iOS by Kagi, with native extension support for both Chrome and Firefox extensions; tested as a representative of the growing category of non-mainstream WebKit browsers.

Browsers that have reached end-of-life or fallen below roughly 0.5% global market share are not included in routine testing. If you encounter an issue in an unlisted browser, please let us know — we'll look into it.

A Note on Accessibility Hardware

We want to be upfront about a meaningful limitation: we do not have access to dedicated accessibility hardware. Screen readers (such as JAWS, NVDA, or VoiceOver beyond basic macOS/iOS testing), braille displays, switch access devices, eye-tracking systems, and other assistive input and output technologies used by people with disabilities every day are not part of our test setup.

This matters. Because we lack these tools, our testing of screen reader behavior is limited to what the built-in platform screen readers on macOS and iOS happen to expose during general testing — not the kind of targeted, in-depth testing that a developer who owns and uses a full assistive technology stack can perform. It also means we may not fully know what "industry standard" truly looks like in practice for assistive technology users. We have studied the specifications and guidelines, we have followed the best practices as best we understand them, and we have built thoughtfully — but we acknowledge honestly that there are things we may have gotten wrong that we cannot see because we are not testing with the tools that would reveal them.

If you use assistive technology and encounter problems on this site, your feedback is especially valuable to us. You have visibility into your experience that we simply cannot replicate without your help. Please reach out — we take every report seriously.

7. Honest Acknowledgment — We May Not Be Perfect

We want to be transparent: this website may not achieve full WCAG 2.1 AA conformance in every area. We are a small construction business, not a large organization with a dedicated accessibility team. We have made a genuine effort to build a site that is accessible, and we continue to improve it — but we are human, our site evolves, and gaps may exist.

Known areas where we acknowledge limitations:

• User-submitted content — Customer reviews submitted through our review system are written by third parties. We cannot guarantee that user-submitted text always follows accessible writing guidelines.
• Photos and gallery images — Project photos may not always have detailed descriptive alt text beyond basic context. We aim to provide meaningful descriptions but acknowledge this is an area for ongoing improvement.
• Third-party embeds — Should we ever include embedded maps, videos, or social media content from third parties, those elements are subject to the accessibility practices of their respective providers, which are outside our direct control.
• Browser and assistive technology compatibility — While we test with modern browsers and aim for broad compatibility, we cannot guarantee a flawless experience with every combination of assistive technology, browser, and operating system.

We do not hide behind these limitations. They are presented here honestly so that users who rely on assistive technology can set accurate expectations, and so we hold ourselves accountable to address them over time.

8. Feedback and Contact

If you encounter an accessibility barrier on our website — something you cannot access, a feature that doesn't work with your assistive technology, or content that is unclear — we genuinely want to hear from you. Your feedback directly informs how we improve the site.

Please contact us at:

• Email: anthony@vanalstineconstruction.com
• Phone: (531) 284-3135

When you reach out, please describe:

• The page or feature where you experienced the barrier
• The assistive technology or browser you were using (if applicable)
• A brief description of what you were trying to do and what happened instead

We will do our best to respond promptly and to resolve the issue or provide the information you need in an alternative format.

9. Standards Reference

Our accessibility efforts are guided by the Web Content Accessibility Guidelines (WCAG) 2.1, published by the World Wide Web Consortium (W3C). We aim to meet Level AA conformance as our baseline standard, with Level AAA improvements applied where practical.

This statement was last reviewed and updated on August 1, 2026.