Our accessibility statement
Accessibility is the core of what we sell, so we're not going to hand you a boilerplate legal disclaimer and call it done. This is a genuine, working statement about this website specifically: what we've built, what we've actually checked, and what we haven't got to yet. We'll keep it updated as that changes.
What we commit to
We build to the Web Content Accessibility Guidelines (WCAG) 2.1, Level AA, as our baseline — not a stretch goal. On this site, and every site we build, that means:
Semantic HTML
Real headings, lists, buttons, links and form elements used for what they're actually for, in an order that makes sense read top to bottom — not visual layout faked with generic divs.
Keyboard operability
Everything you can do with a mouse — open the menu, expand an FAQ answer, submit the contact form — you can also do with a keyboard alone, in a sensible tab order.
Visible focus states
When you're tabbing through the site, you can always see where you are. Focus outlines are never removed without a clearly visible replacement.
Sufficient colour contrast
Text and interactive elements are designed to meet WCAG AA contrast ratios against their backgrounds, including our purple accent colour and the dark footer and call-to-action bands.
Skip links
A "skip to main content" link sits at the very top of every page, so keyboard and screen-reader users don't have to tab through the header on every single page load.
Reduced-motion support
If your device is set to reduce motion, we respect that preference rather than forcing animation on everyone regardless of what they've asked for.
Alt text discipline
Images that carry meaning get clear, useful alternative text. Decorative images and icons are marked so screen readers skip over them instead of reading out noise.
Plain language
Accessibility isn't only technical. We write in plain English, explain jargon where it's unavoidable, and avoid burying important information in dense paragraphs.
What we've actually tested — and what we haven't
We'd rather tell you exactly where things stand than let you assume more testing has happened than actually has.
What's genuinely true today: the colour contrast of our core palette — the purple accent colour against white and light backgrounds, and the text colours used in the dark footer and call-to-action bands — has been checked by hand against the WCAG contrast formula. It has not yet been run through an automated contrast checker across every single text-and-background combination on every page, so there may still be a combination we've missed.
Updated 24 July 2026: an automated HTML validator (html-validate, using its recommended ruleset) has now been run across all 21 pages of this site — zero errors, after we fixed the handful it found. An automated structural accessibility scan (axe-core) has also been run across all 21 pages: it initially surfaced three genuine problems — unlabelled links on our portfolio cards, a skipped heading level on two pages, and content sitting outside any landmark on our concept pages — all three of which we fixed the same day, and the re-scan now reports zero violations. We've also programmatically verified that the skip link is the first focusable element on every page.
Two important honesty notes about that scan: our working environment can't run a full rendered browser, so the axe scan was structural only — it could not check colour contrast or anything that depends on visual layout, and it is not a substitute for a full Lighthouse-style audit in a real browser. And while every interactive element has been built with keyboard use in mind, a complete manual keyboard-only walkthrough of every page and every interactive element — the mobile navigation toggle, the FAQ accordion, the contact form — has still not been fully completed and signed off.
What you can verify yourself, right now, by viewing the page source: the only JavaScript on this site is a small mobile-navigation toggle and a "copy my answers" helper on our forms — under a hundred lines in total, with no trackers and no third-party scripts. The FAQ uses native <details> and <summary> elements rather than a custom-built widget. Buttons, links and forms are real <button>, <a> and <form> elements, not clickable divs. Focus states use :focus-visible outlines. A skip link is present on every page. None of that is a claim you have to take on faith — it's checkable.
Known limitations
WebQuest is a new studio, not an established one with years of audits behind it. Here's what's still outstanding, plainly:
- No full, automated contrast audit has been run across every page and colour combination yet — only manual checks of the core palette. (Our automated scan, above, couldn't cover contrast.)
- No rendered-browser audit (Lighthouse, pa11y, or similar) has been possible in our current working environment — the HTML validation and axe scan we have run are structural checks, not a full visual audit.
- No testing with real assistive-technology users — screen reader users, switch users, voice-control users — has been done yet.
- The manual keyboard-only walkthrough of every page and interactive element is still in progress, not signed off as complete.
These are gaps we're actively closing, not settled facts we're comfortable leaving as they are. We'd rather list them here than let this page read as more finished than the site actually is.
Found an accessibility problem?
If something on this site is hard to use, hard to read, or doesn't work properly with a keyboard or assistive technology, we want to know about it. Use the contact form or email us directly at hello@webquest.com.au, and we'll respond and look into it.
Worth knowing: that email address is a placeholder until we set up a proper mailbox for the business, so for now the fastest way to reach us is the contact form.
Want a website built to this same standard?
This is the accessibility standard we apply to every site we build for NDIS providers — not just our own.