Accessibility

Last updated 17 September 2026

We build sites that work for the people using them. That includes people using a screen reader, a keyboard, magnification, or a phone in bright sunlight. This page says what we have done and, just as importantly, what we have not yet verified.

What we are aiming at

WCAG 2.1 Level AA. That is the standard referenced by accessibility legislation across Canada, and it is the one we hold client work to as well.

What this site does

Structure

• Semantic HTML landmarks — header, nav, main, footer — so screen reader users can jump between regions.
• One h1 per page and headings that descend in order, with no skipped levels.
• A "skip to main content" link as the first thing a keyboard reaches.
• Tables that are genuinely tabular data use real table markup with proper header cells.

Keyboard

• Everything that can be clicked can be reached and operated with a keyboard.
• A clearly visible focus outline on every interactive element, three pixels thick and offset so it is never hidden against the element's own edge.
• The mobile menu closes on Escape and returns focus to the button that opened it.
• The FAQ accordion uses real buttons, so it behaves the way a screen reader user expects without any custom key handling.

Colour and contrast

• Body text meets or exceeds a 4.5:1 contrast ratio; large text meets 3:1.
• Colour is never the only way information is conveyed. The uptime chart, for example, has a written summary and per-day labels alongside the coloured bars.
• Form errors are announced in text, not signalled by a red border alone.

Motion and zoom

• We honour prefers-reduced-motion: if your system asks for less movement, transitions are switched off.
• The layout reflows to 320px and to 200% zoom without horizontal scrolling or lost content.
• Nothing flashes, auto-plays or moves on its own.

Forms

• Every field has a visible, permanently present label — never a placeholder standing in for one.
• Errors are announced to screen readers as they appear, and focus moves to the field that needs attention.
• Instructions sit next to the field they describe and are linked to it programmatically.

Without JavaScript

The site works. The FAQ answers are all visible, the navigation is usable, and the scorecard form submits normally and returns a full page. JavaScript improves the experience; it is not required to have one.

What we have not verified

Being straight about this, because a statement claiming perfection is a statement nobody trusts:

• Testing so far has been with automated tooling, keyboard-only navigation and browser zoom. A full manual audit with NVDA, JAWS and VoiceOver has not yet been completed.
• The hero click map is a decorative illustration. It is hidden from assistive technology and its meaning is given in the caption and the ranked list beneath it — but a diagram is still a diagram, and if that caption does not do the job for you, tell us and we will rewrite it.
• PDF reports are generated with tagged text, but have not been audited against PDF/UA. If you need a report in HTML or plain text instead, ask and you will have it the same day at no charge.

If something does not work

Tell us. hello@vanillaseo.ca, or (587) 893-8163.

You will get a reply within 24 hours from the person who wrote the code. Please say what you were trying to do and what assistive technology you were using — it makes the fix much faster. We treat accessibility bugs as bugs, not as feature requests, and they go to the front of the queue.

If we cannot fix something quickly, we will tell you honestly how long it will take and give you a way to get what you needed in the meantime.