ConcreteInfo

Accessibility Statement

Last updated: 2026.

ConcreteInfo Media LLC is committed to making concreteinfo.shop usable by everyone, including people who navigate by keyboard, use a screen reader, need high contrast, or turn off animation. This statement describes what we target, what we actually built, what still falls short, and how to tell us when we get it wrong.

Conformance target

We target WCAG 2.2 Level AA. We describe the site as partially conformant: most of the site meets Level AA, and the exceptions are listed in the known gaps section below rather than buried.

We measure conformance during the build, not only by hand — contrast ratios are validated programmatically before a page ships, so a color change that breaks contrast fails the build instead of reaching you.

What we implemented

These are specific, verifiable measures already in the site, not intentions.

Structure and navigation

  • Semantic landmarks on every page — header, navigation, main, complementary and footer regions are real landmarks a screen reader can jump between.
  • One H1 per page, matching the page title, with no heading-level skips. Headings describe the section they open, so navigating by heading actually tells you where you are.
  • A skip-to-content link as the first focusable element on every page.
  • Consistent navigation order. The header, footer and section order do not shuffle between pages.
  • Help links in a consistent footer position on every page — contact, accessibility and editorial policy sit in the same place site-wide, satisfying WCAG 2.2 criterion 3.2.6 Consistent Help.

Keyboard operation

  • Everything works from the keyboard, including the command bar (site search) and every calculator. Nothing on this site requires a mouse.
  • Focus is always visible. Focus indicators are 2 px, high contrast against both themes, and never removed. We do not set outline: none anywhere without an equally visible replacement.
  • Focused elements are never hidden by the sticky header. We set scroll-margin on focusable targets so a keyboard user tabbing down the page never lands on something the header is covering, satisfying 2.4.11 Focus Not Obscured.
  • No keyboard traps. You can always tab out of the command bar, a calculator, or an expanded section.

Pointer and target size

  • Interactive targets are at least 24 by 24 CSS pixels, meeting 2.5.8 Target Size (Minimum). Primary controls such as buttons and form fields are 44 px tall.
  • No drag-only interactions, meeting 2.5.7 Dragging Movements. There is no slider, no drag-to-reorder and no swipe-only control anywhere; every value can be typed or stepped with buttons and arrow keys.

Forms and calculators

  • Every input has a real, programmatically associated label. Placeholder text is never the only label.
  • Errors are announced, described in text, and never signaled by color alone.
  • Calculators remember what you already entered within a session, so moving from the slab calculator to the bag calculator does not make you re-type the same dimensions, satisfying 3.3.7 Redundant Entry. Those values stay on your device.
  • Calculators show their formula and assumptions in text, so the result is verifiable without interpreting a graphic.

Color, contrast and motion

  • Contrast is validated at build time against WCAG AA thresholds for text and interface components, in both light and dark themes.
  • Color is never the only carrier of meaning. Status, emphasis and comparison are conveyed with text or shape as well.
  • prefers-reduced-motion is honored — transitions and smooth scrolling are disabled when you ask for less motion.
  • prefers-reduced-transparency is honored — translucent surfaces become solid.
  • prefers-contrast: more drops all glass effects and raises every border, producing a flat high-contrast interface.
  • Light and dark themes are both AA-validated, and your choice is remembered.

Charts, tables and content

  • Every chart carries role="img" with a descriptive label, and is accompanied by a real data table containing the same values. If a chart fails to render, is unreadable to you, or you simply prefer numbers, the table has everything.
  • Data tables use proper header cells and scope, so a screen reader can announce the row and column context of any value.
  • Wide tables scroll inside their own container and are keyboard-scrollable, so they never force horizontal scrolling of the whole page.
  • Text reflows to 320 CSS pixels without loss of content or horizontal scrolling, and remains usable at 200% zoom.
  • Link text describes its destination. We avoid bare “click here” and “read more.”
  • Language is declared per page, and the language switcher marks the alternate language correctly so a screen reader pronounces Spanish pages in Spanish.

Known gaps

We would rather list these than let you find them.

Third-party advertising iframes are outside our control. Ads are served by third-party partners inside iframes, and we cannot guarantee their keyboard operability, contrast, focus handling or motion behavior. We do not control their markup and cannot repair it. If an ad unit creates a barrier for you, report it with the page address and we will raise it with the partner and, where the problem is persistent, remove the placement.

Externally hosted PDFs may not be accessible. We link to standards bodies, manufacturers and government agencies, including PDF documents such as the NRMCA Concrete in Practice series and manufacturer technical data sheets. Those files are published by other organizations, and many are not tagged for screen readers. We cannot remediate documents we do not host. Where a PDF carries information central to an answer, we summarize the substance in accessible HTML on our own page so you are not forced into the PDF.

Third-party embeds generally. Any embedded content we did not author carries the same caveat as advertising.

Ongoing verification. Automated checks run on every build, and manual keyboard and screen reader testing is periodic rather than continuous. New pages can ship with issues that our automated checks do not catch. Reader reports are how we find those, and we treat them as high priority.

Assistive technologies we test with

We test with current versions of major browsers on desktop and mobile, using keyboard-only navigation, browser zoom to 200%, and screen reader verification of landmarks, headings, labels, tables and chart alternatives. We do not claim compatibility with every combination of assistive technology and browser, and we want to hear about failures in the ones we did not test.

Report an accessibility barrier

Email [email protected] with the subject line “Accessibility.” Tell us:

  • the page address,
  • what you were trying to do,
  • what happened instead, and
  • your browser and assistive technology, if you know them.

None of this is required — a one-line message describing the problem is enough. Report it in English or Spanish.

Our commitment: we acknowledge every accessibility report within 2 business days, and within 10 business days we give you either a fix or a written remediation plan with a target date. If a barrier comes from a third-party component we cannot repair, we will tell you that plainly, tell you what we are doing about it, and offer an alternative way to get the information.

Formal complaints

If our response does not resolve the issue, reply to the same address and ask for escalation to the publisher. ConcreteInfo Media LLC is the responsible entity. This statement is reviewed at least annually and whenever we make significant changes to the site.