Last updated August 5, 2026
Accessibility Statement
A website that some people cannot use is a website that is not finished. This statement describes what has been built into elementwebco.com to keep it usable with a keyboard, with a screen reader, at high zoom, and for people who find motion uncomfortable — along with the places it still falls short, and how to tell us when something blocks you.
The standard we build toward
We design and build against WCAG 2.1 Level AA. That is the target we work toward, not a certification we hold.
This site has not been through a formal third-party accessibility audit, and we are not going to claim conformance that has not been independently verified. What we can tell you is exactly what has been implemented and exactly what we know is still weak, which is the section below and the one after it.
What has been implemented
Pages are built from semantic HTML — real headings in order, real lists, real buttons and links — so assistive technology gets the structure of a page rather than a wall of undifferentiated boxes.
Every page starts with a skip link that jumps straight to the main content, so keyboard users are not forced through the navigation on each page.
Interactive elements are reachable and operable by keyboard, and focus is visible: links, buttons, and form fields draw a clear outline with space around it when focused, with the outline colour adjusted on dark sections so it stays visible against the background.
Images that carry meaning have alternative text describing what matters about them, and decorative images are marked so screen readers pass over them instead of reading filenames aloud.
Animation respects the reduced-motion setting in your operating system. Where the site would float, ripple, scroll, or animate, that motion is switched off when you have asked your device for reduced motion.
Colour combinations across text, buttons, and interface elements were checked for contrast during the build, and adjusted where they came up short. Colour is never the only way information is conveyed.
Layouts are responsive and reflow rather than break when text is enlarged or the browser is zoomed, and form fields have visible labels with error messages written in words rather than colour alone.
Known limitations
Parts of this site use WebGL and substantial animation. Reduced-motion alternatives exist, but a complex visual scene is difficult to convey fully to a screen reader. Where those sections carry real information, that information is also written out in text nearby — and where it is purely decorative, we would rather it be skipped than narrated.
The site uses a custom cursor treatment on pointer devices. It does not replace normal keyboard or touch interaction, but if it interferes with how you navigate, we want to hear about it.
Embedded third-party content — video players, maps, and platform widgets — is not fully under our control. Captions and keyboard behaviour there depend on the provider.
Older case study images may have shorter alternative text than we would write today. We improve these as pages are revised.
Testing has been done with keyboard-only navigation, browser zoom, automated checks in browser developer tools, and manual review. That is not the same as testing against every screen reader, browser, and operating system combination, and we have not done that.
Reporting a barrier
If something on this site blocks you, email elementwebco@gmail.com and describe what happened. The page address, what you were trying to do, and the browser or assistive technology you were using are the three things that make a fix fastest, but send whatever you have — a one-line description is enough to start.
We typically reply within a few business days, and we will tell you plainly whether we can fix it, roughly when, and what to do in the meantime if there is a workaround.
If you need information from a page that is not reaching you, ask for it directly and we will send it in a format that works for you.
Accessibility in the work we build for clients
When accessibility is in scope for a client project, we build to the same WCAG 2.1 AA target: semantic structure, keyboard operability, visible focus, alternative text, contrast checks, and reduced-motion handling as part of the build rather than as a retrofit.
For public-facing organizations around Kalamazoo — a township site, a venue calendar, a restaurant’s ordering page — this matters more than usual, because residents have no alternative route to the information.
We do not sell accessibility overlays or automated widgets that claim to make a site compliant. They do not do what they claim, and they frequently make things worse for the people they are sold as helping.
Ongoing work
Accessibility is not a task that gets checked off. Every time a page is added or revised, the same checks run again, and this statement is updated when what is true about the site changes.
If you find something we missed, telling us is genuinely useful. It is the fastest way this gets better.
This page is provided for general information and does not constitute legal advice. For questions about this document, contact us through the contact page.