Built to be usable by everyone we want to work with.

Our conformance target is the Web Content Accessibility Guidelines (WCAG) 2.1 at Level AA, published by the W3C's Web Accessibility Initiative. WCAG 2.1 AA is the level most U.S. and EU public-sector procurement frameworks reference, and it is the bar we hold ourselves to whether or not a given customer is required to ask for it.

In practice that means we work toward the following outcomes across every page on web-cited.com:

• Perceivable. Text and interactive controls present at sufficient contrast against background. Non-text content (logos, decorative marks) has appropriate alternative text or is marked as decorative.
• Operable. All navigation, links, and form controls are reachable and usable with a keyboard alone. There is no time-limited interaction. There is no flashing or motion content that could trigger seizures or vestibular discomfort.
• Understandable. Page language is declared. Headings follow a single logical hierarchy. Form labels are explicit and error messages are written in plain English.
• Robust. Markup is semantic HTML5 served as a single document per page; no client-side route changes, no JavaScript-gated content, and no widgets that override native browser behavior. Assistive technology gets a normal, well-structured DOM.

WCAG 2.1 AA is a target, not a certificate. We do not currently hold a third-party accessibility audit or a formal Voluntary Product Accessibility Template (VPAT). If your procurement function requires either, tell us and we will work with you on what we can provide as an interim.

These are the practices visible in the site code today; they are the controls we rely on to hit the conformance target above.

• Semantic HTML. Every page uses standard HTML5 landmarks: a single <header>, a single <main id="main">, and a single <footer>. Navigation lives inside role="navigation" with an explicit aria-label. Sections use <section> with aria-labelledby pointing at their own heading.
• Single H1 per page. Each page has exactly one <h1> in the banner block, followed by ordered <h2> and <h3> headings that do not skip levels.
• Skip link. Every page begins with a .skip-link that jumps to #main, visible on first keyboard focus so a keyboard or screen-reader user can bypass the header.
• Keyboard navigation. Every link, button, form control, and the menu toggle is reachable in tab order, in the order it appears in the DOM. Focus styles are not removed. No element relies on hover-only interaction.
• Color contrast. The site uses a high-contrast paper-white / ink-black palette with a single accent. Body text and link text are checked against WCAG AA contrast thresholds (4.5:1 for body text, 3:1 for large text and UI components).
• Form labels and error messages. Every form input on /contact and /start has an explicit <label for>. Required fields are marked. Error summaries use aria-labelledby and are placed before the submit row. Live status regions on submit use role="status" and aria-live="polite".
• Alternative text. Images that convey information have descriptive alt attributes; purely decorative graphics are marked aria-hidden="true" or have empty alt.
• Language declared. The root element on every page declares lang="en".
• No motion traps. No autoplaying video, no carousel that advances on its own, no parallax that ignores prefers-reduced-motion, no modal that traps focus without a documented escape.
• No third-party widgets. Marketing site loads zero analytics, zero chat widgets, zero embedded video, zero fonts from a third party, and zero advertising pixels. That means assistive technology never has to contend with a widget we did not write and cannot fix.
• Responsive and resizable. Layout reflows at viewport widths down to ~320 CSS pixels and supports text-only zoom to 200% without horizontal scrolling or content loss.

No known significant issues at the time of this review.

That said, we are a small team and accessibility work is never finished. If you encounter a barrier on any page of web-cited.com - something that does not work with your screen reader, a control that is not reachable from the keyboard, a contrast issue, a confusing label, a focus state that disappears - please tell us using the contact form below. We treat barrier reports as bugs and prioritize them accordingly.

The fastest way to report a barrier is the contact form with subject "accessibility". The form routes straight to a human inbox.

Useful detail to include, if you can:

• The page URL where you ran into the issue.
• What you were trying to do.
• What happened instead, and what you expected.
• Your browser, operating system, and the assistive technology you were using (screen reader, voice control, switch device, etc.), if relevant.

Our commitments on response time:

• Acknowledgement within 1 business day. A human will confirm we received the report.
• Substantive response within 5 business days. We will tell you what we found, whether we agree it is a barrier, and what we are doing about it.

If a barrier is blocking you from completing intake or contacting us at all, you are welcome to ask a colleague to submit on your behalf - we will follow up with you directly once we have a working channel.

This statement is a public commitment, not a one-time disclosure. We review it:

• Annually, on or before the anniversary of the date below.
• After any major design or template change to the marketing site - new page layout, new component, change to navigation, new form, change to the color system, or change in the JavaScript loaded at the page level.
• Whenever a barrier report identifies an issue that warrants updating the practices on this page.

When the page changes, the "Last reviewed" date below moves forward. If we ever stop conforming to a specific WCAG 2.1 AA success criterion on a specific page, that limitation will be named explicitly in the Known limitations section above - we will not let the gap go undisclosed.

Last reviewed: May 10, 2026.