Accessibility
Accessibility statement
We target Web Content Accessibility Guidelines (WCAG) 2.2 Level AA on vcweb.net and on every site we build. This page sets out what that means in practice, where we currently fall short, how we test, and how to report a barrier.
Our commitment
VCweb Digital Agency treats accessibility as part of building a website correctly — the same category as making it load quickly or making the forms deliver. Our target for this site and for client work is WCAG 2.2 Level AA, the level most commonly referenced in US procurement and litigation.
That is a target, not a completed state, and we do not claim full conformance. Every new page, image and embed is another chance to break something. What we commit to is a defined standard, testing before anything ships, and a route for you to tell us when we have missed.
In practice
What we build in
Checklist items in pre-launch QA, not aspirations.
Semantic structure
Headings in order, landmark regions, real lists, and buttons that are buttons rather
than styled div elements. Screen reader users navigate by structure.
Keyboard operability
Every control reachable and operable without a mouse, in a logical order, with no keyboard traps.
Visible focus
Focus indicators stay in place and stay visible against every background they sit on. Removing focus outlines for a cleaner look is one of the most damaging things done to a site.
Colour contrast
Colours verified against the AA thresholds: 4.5:1 for body text, 3:1 for large text and the non-text parts of controls. Colour never carries meaning on its own.
Forms and errors
Every field has a programmatically associated label, not a placeholder pretending to be one. Errors are described in text and tied to the field, not signalled only by colour.
Images and motion
Meaningful images carry alternative text describing their purpose; decorative ones are
hidden from assistive technology. Animation respects
prefers-reduced-motion.
Known limitations
We would rather list the gaps than imply there are none.
- Older blog images. Some images inherited from earlier posts carry generic alternative text, or text that duplicates the article title instead of describing the image. We are working through the archive as each post comes up for editorial review.
- Third-party embeds. Content we do not control — video players, mapping widgets and similar — may not meet AA in full, and can change when the vendor updates it. Where an embed causes a problem we find a better alternative or provide the same information in plain HTML alongside it.
- Documents. PDFs supplied by a client may not be tagged for assistive technology. We flag this during a build and offer an HTML equivalent.
- New content. Anything published between reviews is checked by whoever published it, but has not necessarily had a full manual pass.
If you find something not listed here, we want to know. One specific report from someone using the site is worth more than another automated scan.
How we test
Testing runs in two layers, because neither is sufficient alone.
Automated checks run against templates during development and again before launch. They catch missing alternative attributes, unlabelled inputs, contrast failures on static text, duplicate IDs and broken heading order, and they run on every change.
Manual passes cover what automation cannot judge. Every template gets a keyboard-only run and a screen reader pass, checking that headings, labels, link text and error messages make sense read aloud. Whether alternative text is useful, or a link called "read more" tells you anything, is a human judgement.
Automated tooling detects only a minority of WCAG failures; most of what matters — whether a label reads sensibly, whether an error message tells you what to do next — cannot be judged by a machine. Treating a clean scan as proof of accessibility is the most common mistake here, which is why our build and QA stage includes manual work.
Feedback
Tell us about a barrier
If any part of this site, or a site we built, stops you doing what you came to do, tell us. We treat it as a defect to fix, not a complaint to manage.
What helps us fix it faster
- The page address, and what you were trying to do
- What happened instead, in your own words
- Your browser and operating system, if you know them
- Any assistive technology you were using, and its version
None of it is required. "The booking form is unusable with a keyboard" is enough to start on.
What we commit to
We acknowledge every accessibility report within one business day, then confirm what we found and give you a fix date. Barriers blocking a core task — contacting us, submitting a form, reading a service page — go to the front of the queue ahead of feature work. Anything needing a third-party vendor may take longer; we tell you the interim workaround.
This statement is reviewed at least annually and whenever the site changes significantly. Nothing here limits any rights you have under applicable law; our terms of service cover the commercial relationship.
How to reach us
Post
214 Commerce St, Suite 300
Dallas, TX 75201, United States
Prefer a form? Use the contact page and put "accessibility" in the message so it reaches the right person.
Accessibility in client work
Accessibility is part of QA on every build we deliver — not a line item, an upsell or a premium tier. Contrast, keyboard operability, focus states, semantic landmarks, form labelling and screen-reader behaviour are checked against WCAG 2.2 AA before a site goes live, on the smallest project as much as the largest.
That is partly a legal calculation: accessibility claims against US small businesses are routine, and retrofitting an inaccessible site costs far more than building it correctly, because the problems are structural rather than cosmetic.
It is also commercial. A meaningful share of your customers use the web with a keyboard, a screen reader, magnification, captions, or an older phone in bright sunlight. Each one who cannot complete your contact form is a lead you paid for and lost silently.
What we do not do is install an overlay widget claiming to make a site compliant automatically. Those products do not fix the underlying markup, are widely criticised by disabled users, and have not prevented litigation. We fix the code instead.
How we build websites → · Our five-stage process → · Common questions →
Not sure whether your site is accessible?
Book a free 30-minute call. We will go through your site and send you a written summary of the highest-impact fixes — including the barriers that stop people using it — so you hear it from us rather than from a demand letter.
- A written audit of your site, SEO and ad account
- A prioritised list of fixes, ranked by impact
- Transparent pricing before any commitment
- No obligation and no sales pressure
Replies within one business day, Monday to Friday, 9:00 AM – 6:00 PM Central Time.