Accessibility

Accessibility
statement.

Last updated August 2, 2026. This statement covers forefrontindustries.io and describes the standard we hold our own site and our client builds to.

01

Our commitment

Forefront Industries is committed to making this website usable by as many people as possible, including people who browse with a screen reader, navigate by keyboard only, use voice control, rely on high contrast or magnification, or have limited motor control.

Accessibility is not a compliance checkbox for us. It is part of how a site is engineered. A page that a screen reader cannot parse is usually also a page that a search engine cannot parse well and that converts worse for everyone.

02

Standard we build to

We target conformance with the Web Content Accessibility Guidelines (WCAG) 2.1, Level AA. In practice that means:

  • Semantic HTML structure with a single logical heading order per page, real landmarks, and real lists rather than styled divs.
  • Every interactive element reachable and operable by keyboard, with a visible focus indicator.
  • Text contrast that meets or exceeds the 4.5:1 ratio for body copy and 3:1 for large text and interface components.
  • Descriptive alternative text on meaningful images, and empty alt attributes on purely decorative ones so screen readers skip them.
  • Form fields with programmatically associated labels, and errors announced in text rather than by color alone.
  • No content that relies on color alone to convey meaning.
  • Motion and parallax effects that are subtle by design and that respect the operating system prefers-reduced-motion setting.
  • Responsive layouts that remain usable at 200 percent zoom and at 320 CSS pixels wide.
03

How we test

Accessibility checks happen during development, not as a pass at the end. Our process includes automated auditing with Lighthouse and axe, manual keyboard-only walkthroughs of every template, contrast verification against the design system tokens, and screen reader spot checks using VoiceOver on macOS and iOS.

Automated tools catch roughly a third of real issues. The manual pass is where the rest are found, which is why we do not rely on an overlay widget or a plugin. Accessibility overlays frequently make the experience worse for the assistive technology users they claim to help, and we do not install them on client sites.

04

Known limitations

We are transparent about the areas where this site does not yet fully meet our own bar:

  • Some third-party embeds, including live client site previews shown inside iframes on our industry pages, are outside our control. The surrounding page remains navigable, and each embed is labeled and paired with a direct link to the same content.
  • A small number of decorative canvas and gradient background effects are presentational only. They are hidden from assistive technology, but they can increase GPU load on older devices.
  • Older case study imagery may carry shorter alternative text than we would write today. We are updating this as pages are revised.

If you find something not listed here, we want to know. Reports get fixed, they do not get filed.

05

Compatibility

This site is designed to work with current versions of Chrome, Edge, Firefox, and Safari on desktop and mobile, paired with current versions of VoiceOver, NVDA, JAWS, and TalkBack. It may not perform correctly on browsers older than three years, which no longer receive security updates.

JavaScript is required for full interactivity, but every page is server rendered so the core content and navigation are present in the initial HTML.

06

Report a barrier

If any part of this site prevents you from doing what you came to do, contact us and describe what happened, the page you were on, and the browser or assistive technology you were using. We aim to acknowledge every report within two business days and to resolve confirmed issues in the next release cycle.

If you need information from this site in an alternative format, ask and we will provide it.

07

Accessibility in client work

Every custom build we ship is delivered against the same WCAG 2.1 AA target described above, and accessibility criteria are written into the project acceptance criteria rather than treated as an optional add-on. Where a client operates under a stricter obligation, such as Section 508 or a specific state procurement standard, we scope and test to that standard instead.

We do not offer legal advice or certify legal compliance. We engineer to the published technical standard and document what was tested.

Building something that has to be accessible?

Tell us the standard you are held to and we will scope the build against it from day one.