This statement covers daivietweb.com and the standard we hold client work to. It is written to be checkable rather than reassuring, for the same reason our editorial policy exists.
Our commitment and the target
We work to WCAG 2.2 Level AA on this site and on every site we build. That level is the one most often referenced in US procurement and in accessibility complaints, and it is specific enough to test against.
We are not claiming this site fully conforms today. Conformance is all or nothing at a given level — one keyboard trap or one unlabelled control breaks it for that page — and we have known issues, listed below. The site is built and tested against the standard, and the gaps we know about are being worked through. No third party has audited it.
What is built in
- Semantic HTML. Headings run in order without skipped levels, lists are lists, and landmarks mark out header, main content and footer so a screen reader user can jump between them.
- Keyboard operability. Every link, button and control can be reached and used with a keyboard alone, in an order that matches what you see on screen.
- Visible focus states. Added sitewide during a recent review: the stylesheet previously had none, so keyboard users could tab through the site with no indication of where they were. There is now a high-contrast focus ring with a light halo that stays visible on white pages, tinted sections and coloured buttons.
- Colour contrast checked against AA. Body text, headings, links and button labels are measured against the 4.5:1 and 3:1 thresholds rather than eyeballed.
- Alt text. These pages are almost entirely text, and the only image in the site templates is the logo, which carries a text alternative. In client work the rule is the same one we hold ourselves to: images that carry meaning describe what they show, and decorative images get an empty alt attribute so a screen reader skips them instead of reading out a file name.
- Form labelling. There are no forms here — email is the only way to reach us — so this applies to client work: every input has a visible label properly associated with it, and errors are given in text rather than by colour alone.
- Reduced motion. When your operating system asks for reduced motion, animations and transitions are cut to effectively nothing and smooth scrolling is off.
Known limitations
This is the section worth reading, so it is specific.
- There is no skip link. Every page puts the full navigation ahead of the content, and nothing lets you jump past it. If you browse by keyboard or with a screen reader you tab through the same set of navigation links before reaching the part of the page you came for, on every page. This is a Level A failure, not a rough edge, and it is the first thing on the list to fix.
- The mobile menu does not manage focus. Opening the menu shows it, but focus stays behind on the toggle button rather than moving into the menu; closing it does not put focus back where you were; and the Escape key does not close it. On a narrow screen that means a keyboard user has to tab blindly to get into the menu they just opened.
- Dismissing the cookie banner drops focus. The accept and reject buttons remove the banner, which destroys the element you were focused on. Focus is supposed to land on the main content afterwards, but the handler looks for an element the page templates do not actually carry, so focus falls back to the top of the document and you start tabbing from the beginning again.
How we test
- Automated checks. We run a checker over pages as we change them. Tools like these reliably catch missing alt attributes, missing form labels, contrast failures, broken heading order and invalid ARIA.
- Manual passes. A keyboard pass on every template: tab through everything, confirming the order is sensible and focus always visible and never trapped. Then a screen-reader pass — headings must make sense read in sequence, link text must mean something out of context, images must announce something useful.
Plainly: automated tools catch only a fraction of the barriers that actually stop someone. A checker will tell you an image has no alt attribute; it cannot tell you the alt text is wrong, or that the tab order jumps around the page. A clean automated report is not a result.
Reporting a barrier
If something here stops you doing what you came to do, email [email protected]. That is our only channel — no phone line, no form — and the contact page has the details. What helps us reproduce it:
- The URL of the page.
- What you were trying to do when it went wrong.
- Any assistive technology, with the version if you know it.
- Your browser and operating system.
You get a reply within one business day. If the fix is quick, we do it and tell you. If it will take longer, we say how long and describe a workaround in the meantime.
Accessibility in client work
Accessibility is part of pre-launch QA on every build we ship. It is not a paid add-on or an optional phase — the keyboard and screen-reader passes above happen before a site goes live. You can see where that sits in our process, and it carries into ongoing maintenance, since new content is where accessibility usually regresses.
The commercial argument matters as much as the legal one. Web accessibility claims against US businesses are a real exposure, and enterprise and public-sector buyers ask about conformance during procurement. The simpler case: the same work that makes a site usable with a keyboard — proper labels, readable contrast, predictable structure — makes it clearer for everyone. Retrofitting after launch costs more than doing it during design, because the fixes land in the layout rather than in the markup.
Where a client decision conflicts with the standard, we say so in writing and record the decision rather than quietly shipping it. What is and is not included in an engagement is set out in our terms.