14 / Accessibility
We build to WCAG 2.2 AA and list where we miss.
A domain name check report is useless if you cannot read it, and a mail setup guide is useless if the record samples are unreachable by keyboard. This statement says what we aim for, what we checked and which parts still fall short.
What we aim for
Every page on qelzavo.com is built against the Web Content Accessibility Guidelines 2.2 at level AA. We call it partial conformance because a few pieces, listed below, do not fully meet it yet. We would rather say that than claim a badge.
The site is static HTML with a small amount of JavaScript. No framework renders the text, so the page reads in a screen reader even if a script fails. The consent banner never blocks the page; you can read everything before you choose.
What is already in place
- A skip link as the first focusable element, jumping past the masthead to the content.
- One
h1per page, headings in order, landmarks for header, navigation, main and footer. - A 2px clay focus outline on every link, button, chip and form field. It is never removed.
- Body text in Public Sans at 16 to 18px with a line height of 1.6. Graphite
#4A4440on warm white#F7F3EEclears 4.5:1 comfortably. - Buttons, chips and tabs at least 44px tall, sized by padding so long labels wrap instead of clipping.
- Layouts that reflow down to a 320px screen without horizontal scrolling, and text that survives 200% zoom.
- Form errors written in words next to the field, tied with
aria-describedby, not shown by colour alone. - Motion that switches off under the reduced-motion setting. The step rail on the home page becomes a plain vertical list.
Where it falls short
These are the parts we know about. They are on our list, not hidden.
- The horizontal step rail. It works with arrow keys and the buttons beside it, but a screen reader announces all seven steps at once, and the "03 / 07" counter is not yet a live region.
- The SPF calculator. The total updates as you tick senders. The headline number is announced, the draft record string is not. If you are fixing SPF too many DNS lookups by ear, use the remaining-budget figure, which is announced.
- Sample DNS records. Long TXT values sit in dark mono blocks that scroll sideways on a phone. They are readable and copyable, but a screen reader reads them character by character in some browsers.
- The support chat. New replies arrive by polling every five seconds. They are added to a log region, but older screen readers may not announce them until you move focus.
- Photographs. Each one has alt text. Screens and paperwork in the photos are deliberately out of focus, so the alt text describes the scene, not the words.
Your domain card and reports
The domain card and any status report we write for you are sent as documents, not web pages. If you need one in a different form (plain text email, larger type, a version without tables) say so when you send the inquiry and we produce it that way at no extra charge. Plain text is often the better format for record values anyway: v=spf1 include:_spf.google.com ~all reads the same in any tool.
How we tested
Keyboard only, from the skip link to the footer, on every page. Screen widths of 320, 360, 414, 768, 1024, 1440 and 1920 pixels. Browser zoom at 200% and 400%. VoiceOver on a phone and NVDA on a desktop for the forms and the calculator. Automated contrast checks on every colour pair in the palette. Two people did this, not an outside auditor, and we say so plainly.
How to report a barrier
Tell us the page, what you were trying to do, and the device or assistive tool you use. Email [email protected] with "Accessibility" in the subject, or call +1 (861) 555-8670. Post works too: Qelzavo, 138 River Road, Suite 4, Austin, Texas 48482, United States.
We reply within 5 days. If the barrier stopped you sending an inquiry, we take the inquiry by email or phone in the meantime, so the fault on our side never delays your domain work.