Skip to content
Talk to an engineer

Legal

Accessibility

We hold client work to WCAG 2.2 AA. It would be strange to hold our own site to less.

Effective

Our target

This site is built to WCAG 2.2 Level AA. That is the same standard we build client interfaces to, and at least what Section 508 procurement requires of the public-sector systems we deliver. All four sections of the site, computingamerica.com, computingamerica.com/hardware, computingamerica.com/it and computingamerica.com/cyber, are built from the same components and templates, so what holds on one holds on the others by construction; the manual audit described below was run on the primary section.

What that sentence claims, precisely: AA is the target we design and build against, and it is checked: automated contrast checks run before changes are pushed (every text role measured against every surface it sits on, in both themes), target size is checked by hand, and the site was audited by hand across 55 routes on July 30, 2026. It is not a certified conformance claim, and we would rather say so than publish an accessibility statement that is itself inaccurate. The site changes; the last full manual audit necessarily predates the most recent changes to it. If you hit something that does not work, the address below reaches an engineer.

What that means here

Specifically, on this site:

  • Every interactive element is reachable and operable by keyboard, with a visible focus indicator that clears 3:1 against whichever background it lands on, light or dark.
  • Body and secondary text meet or exceed a 4.5:1 contrast ratio against the surface it sits on, not merely against white. The border of a form field or an outlined button clears 3:1, because it is the only thing identifying the control.
  • Opening the mobile menu makes the page behind it inert, so keyboard focus cannot walk into content the overlay is covering.
  • Headings, lists and landmarks are semantic, so the structure is navigable by screen reader.
  • Motion is decorative only and is disabled entirely under prefers-reduced-motion. The one band that scrolls by itself also carries a pause control, because a preference someone has not set is not a mechanism they have.
  • Any panel that scrolls horizontally, such as a code listing, is itself a tab stop, so its overflow is reachable without a pointer.
  • The layout reflows without horizontal scrolling from 320px, and remains usable at 200% zoom.
  • Form fields have persistent labels, errors are announced and described in text rather than by color alone, and a successful submission is built to move focus to the confirmation so it is not silent; that last path is verified in the code and has not yet been exercised in a recorded audit.

Known limitations

We test with keyboard navigation and automated axe-core checks. We have not yet run a screen-reader pass, so how these pages behave with NVDA, JAWS, VoiceOver or Orca is not something we are willing to vouch for here. Testing is not exhaustive, and assistive technology combinations we have not tried may behave differently.

Tell us if something doesn’t work

If any part of this site is difficult or impossible for you to use, email info@computingamerica.com with the page and what happened. We treat accessibility reports as defects with a real priority, not as feedback. We will acknowledge within two business days and tell you when it will be fixed.