Accessibility Statement

1. Commitment

The Site is designed against the Web Content Accessibility Guidelines (WCAG) 2.2 at Level AA. We treat accessibility as part of the design system rather than an afterthought; the regulated-industries buyers we serve include people inside those organizations who use assistive technology.

2. Standards we target

• WCAG 2.2 Level AA — w3.org/TR/WCAG22
• Section 508 of the US Rehabilitation Act (private-sector framework) — section508.gov
• ADA Title III (US private-sector accessibility) — ada.gov/topics/title-iii
• European Accessibility Act (EAA), effective June 28, 2025 — European Commission EAA

3. What is implemented

• Semantic HTML5 landmarks are part of the shared site template: <header>, <nav>, <main id="main-content">, <footer>.
• Skip-to-content link is part of the shared template; it is off-screen until focused, then becomes visible. Activating it moves keyboard focus into <main>, so the next Tab continues inside the page content instead of returning to the header. Every in-page jump link on the site behaves the same way.
• ARIA wiring on interactive widgets: the mobile navigation toggle (aria-expanded, aria-controls). FAQ content renders fully expanded with semantic headings — no disclosure widget is required to read any answer.
• Contact access uses the intake form on the contact page. Every visitor-facing field carries a visible <label> bound by for / id; required fields are marked in the label text as well as with the required attribute; the required-data acknowledgment is a labelled checkbox, not a colour cue; validation and submission messages are written into a role="status" aria-live="polite" region so they are announced rather than only shown; a control that fails validation carries aria-invalid="true" and points through aria-describedby at a message that names that field in text, the summary in the live region names every field still to complete, and focus moves to the first of them, so no error is ever carried by colour alone; and the fields follow document order, so keyboard and screen-reader users reach the submit control last.
• Color contrast. Primary text (#14100C) on the ivory page ground (#FBF9F4) is approximately 18:1 (WCAG AAA). Secondary text (#63594B) on ivory is approximately 6.5:1 (AA). Gold used as text is the darkened #6F5826 (approximately 6.4:1, AA); the brighter gold #C4A35A is reserved for rules, edges, and fills, never body text on light surfaces. Type on the inverted band (#EFE8DA on #14100C) is approximately 15.5:1.
• Focus indicators via :focus-visible — a 2px solid outline at 3px offset on every focusable control, one geometry site-wide. Two colours, because no single colour clears the 3:1 non-text contrast floor on both grounds: the darkened gold #6F5826 on light surfaces, and the ivory page ground #FBF9F4 where the control sits on the inverted band.
• Prefers-reduced-motion: every transition and reveal animation is wrapped in a @media (prefers-reduced-motion: reduce) override that disables them.
• No autoplay video, no auto-rotating carousels, no automatic timing-based focus shifts.
• Resizable text without horizontal scroll: no page scrolls the document sideways at 200% browser zoom, or at 320 CSS pixels — the width WCAG 2.2 Reflow is written at, which a 1280px window reaches at 400% zoom.
• Theme-color meta set to the ivory page ground (#FBF9F4) so mobile browser chrome matches the document surface.

4. Testing approach

The design system targets WCAG 2.2 contrast and keyboard operation. Current automated release checks run in a real browser against every page on every release. They cover structure, routes, claims, responsive overflow at 390 and at 320 CSS pixels, in-situ computed contrast for text and for the focus indicator, real-key control of the mobile navigation, the focus destination of every in-page link, the rendered error state of the contact form read from the accessibility tree, the heading outline, and link purpose. A complete assistive-technology audit — a screen reader driven by a person — has not yet been recorded.

Planned before any public production launch: NVDA (Windows) and VoiceOver (macOS / iOS) screen-reader walks of the full site, and a Lighthouse + axe-core lab audit.

5. Known limitations

• The Open Graph share image at /assets/og.png is a rasterized brand card, and a PNG carries no alt text inside the file. What the Site does carry: every page that publishes og:image also publishes og:image:alt and twitter:image:alt, holding one text description of what appears on the card — the Vertical Edge AI name, the headline, and the supporting sentence. A release check asserts that both fields are present and non-empty on every such page, in the source and in the built files; that the source and the built copy carry the same value; that the value is the description derived from the one card-content file the image itself is rendered from; and that the shipped image matches the render recorded for that file. A change to the card text without a matching change to the description, or the reverse, fails the release. Whether a given social platform reads those fields, or renders any alt text at all, is that platform’s behaviour and outside our control.
• The site has not yet undergone a third-party VPAT (Voluntary Product Accessibility Template) audit. We will commission one when a customer engagement requires it.
• Long-form articles in the Resources section use EB Garamond italic for editorial emphasis. Italic serif at small sizes can be slightly harder to read for users with low vision; we keep italic use limited to short accent phrases, never full paragraphs.

6. Conformance posture

We design the Site against WCAG 2.2 AA. We do not claim AAA, and we do not claim certification by any accessibility body. The known limitations listed in Section 5 are tracked and will be addressed in subsequent updates.

7. Reporting an accessibility issue

If anything on the Site is not working for you, please submit a report through the intake form on our contact page and write “Accessibility feedback” in the message. Please tell us: (a) which page; (b) what assistive technology you are using; (c) what you were trying to do; and (d) what happened. We aim to acknowledge accessibility reports within a few business days and to share a remediation timeline within two weeks.

8. Remediation process

Reports are triaged by severity. Critical issues (anything that blocks access for users of assistive technology) are addressed first. Lower-severity issues are batched into design-system updates.

9. Related resources

• WCAG 2.2 — w3.org/TR/WCAG22
• Section 508 of the Rehabilitation Act — section508.gov
• ADA Title III — ada.gov/topics/title-iii
• European Accessibility Act — European Commission EAA

10. Contact

Accessibility inquiries: the intake form on our contact page
Vertical Edge AI LLC

Last updated: 2026-08-26. We update this statement annually or as the Site’s accessibility posture changes.