Website accessibility
How this website meets the Web Content Accessibility Guidelines, what we’re still working on, and how to tell us about a problem.
Concept note. This statement describes the redesigned website as built. Before launch, the City should confirm the contact details below and complete the testing listed under How we check.
The City of Cranbrook wants everyone to be able to use this website, including people who use a screen reader, a keyboard instead of a mouse, voice control, captions, magnification or other assistive technology.
We aim to meet the Web Content Accessibility Guidelines (WCAG) 2.2 at Level AA. This page explains what the guidelines are, how the website meets them, what we’re still working on, and how to tell us about a problem.
About WCAG
WCAG is the international standard for accessible websites, published by the World Wide Web Consortium (W3C). It’s the standard most governments in Canada use, and meeting it supports the goals of the Accessible British Columbia Act.
The guidelines are grouped under four principles. Content must be:
- Perceivable: you can see, hear or otherwise take in everything on the page.
- Operable: you can use every part of the page, however you navigate.
- Understandable: the content, and how the page works, are clear.
- Robust: the page works with browsers and assistive technology, now and as they change.
Each guideline has success criteria at three levels: A (the minimum), AA (the level most organizations aim for, and our target) and AAA (the highest, which isn’t possible for all content). The tables below list the Level A and AA criteria and how this website meets them. Criteria that don’t apply, such as those for audio-only recordings the site doesn’t have, are left out.
Perceivable
| Guideline | What it asks for | How this website meets it |
|---|---|---|
| 1.1.1 Non-text content | A text alternative for images and other non-text content. | Photos and logos have descriptions. Decorative icons are hidden from screen readers so they aren’t read out. Maps always come with the same information as text: the park finder lists every park, and garbage and recycling zones are found by typing an address. |
| 1.2.2, 1.2.4 Captions | Captions for recorded and live video. | Council meeting recordings play through YouTube, which offers captions. Live streams are on Vimeo; see known issues. |
| 1.3.1 Info and relationships | Structure shown on screen is also in the code. | Pages use real headings in order, lists, and landmarks (header, navigation, main content, footer). Tables have header cells. Every form field has a label tied to it, and related choices are grouped with a legend. |
| 1.3.2, 1.3.3 Meaningful sequence, sensory characteristics | Content reads in a sensible order, and instructions don’t rely on shape, position or sound. | The reading order matches the visual order at every screen size. Instructions name things by their label, not by where they are on the screen. |
| 1.3.4, 1.3.5 Orientation, input purpose | Works in portrait and landscape; common fields can be filled in automatically. | No page is locked to one orientation. Name, email, phone and address fields tell your browser what they are, so it can fill them in for you. |
| 1.4.1 Use of colour | Colour is never the only way information is shown. | Status is always written out as well as coloured: “Open”, “Closed”, “Cancelled”, “Stage 1”. Links in text are underlined. |
| 1.4.3, 1.4.11 Contrast | Text has a contrast ratio of at least 4.5 to 1 (3 to 1 for large text, icons and the edges of controls). | Colours were chosen and checked to meet these ratios in both light and dark mode. Focus outlines and form field borders meet the 3 to 1 ratio. |
| 1.4.4 Resize text | Text can be enlarged to 200% without losing content. | Use the text size buttons at the top of every page, or your browser’s zoom. The layout adjusts instead of cutting text off. |
| 1.4.10 Reflow | No sideways scrolling at a width of 320 pixels (about 400% zoom). | Every page has a single-column layout on narrow screens. Only wide data tables, such as fee schedules and the pool schedule, scroll sideways inside their own box, which WCAG allows. |
| 1.4.12 Text spacing | Content still works when people increase line, letter, word and paragraph spacing. | Text containers grow with their content instead of using fixed heights, so extra spacing from a browser extension or style sheet doesn’t hide text. |
| 1.4.13 Content on hover or focus | Pop-ups that appear on hover or focus can be dismissed and don’t vanish while you read them. | Menus and search suggestions open on click or typing, stay open while you use them, and close with the Escape key. |
Operable
| Guideline | What it asks for | How this website meets it |
|---|---|---|
| 2.1.1, 2.1.2 Keyboard, no keyboard trap | Everything works with a keyboard, and you can always move away. | Menus, forms, the park finder list, video panels, the payment menu and the document reader all work with Tab, Shift+Tab, Enter, Space, the arrow keys and Escape. Nothing traps keyboard focus. |
| 2.1.4 Character key shortcuts | Single-key shortcuts can be turned off or only work when focused. | The site has no single-letter shortcuts. The document reader’s arrow keys only work while the reader is in use. |
| 2.2.1, 2.2.2 Timing; pause, stop, hide | No time limits, and moving content can be paused. | No page or form has a time limit. Nothing scrolls or rotates on its own. Information that updates in the background (weather, City Hall hours, meetings) changes quietly without moving the page. |
| 2.3.1 Three flashes | Nothing flashes more than three times a second. | The site has no flashing content. If your device is set to reduce motion, animations and smooth scrolling are turned off. |
| 2.4.1 Bypass blocks | A way to skip repeated content. | “Skip to main content” and “Skip to search” links are the first things on every page when you press Tab. |
| 2.4.2 Page titled | Every page has a title that says what it is. | Each page title names the page and the City, for example “Garbage and recycling | City of Cranbrook”, so you can tell tabs and bookmarks apart. |
| 2.4.3 Focus order | Focus moves in a logical order. | Tab order follows the reading order. When a form step changes or an error appears, focus moves to the new heading or the list of problems. |
| 2.4.4 Link purpose | The purpose of each link is clear. | Link text says where it goes. Short links such as “Email” have a fuller name for screen readers. Links to PDFs say “PDF” in the link, and links that leave the site show an arrow. |
| 2.4.5 Multiple ways | More than one way to find a page. | Use the main menu, the search on every page, Services A to Z, or the links on each section page. |
| 2.4.6, 2.4.7 Headings and labels, focus visible | Clear headings and labels; you can always see where keyboard focus is. | Headings describe their section. A thick, high-contrast outline shows where keyboard focus is on every link, button and field. |
| 2.4.11 Focus not obscured | The item with focus is not hidden by other content. | The header doesn’t stick to the top of the screen and banners don’t cover the page, so the item with focus stays in view. |
| 2.5.1, 2.5.2 Pointer gestures, pointer cancellation | No multi-finger or path-based gestures are required; actions happen on release. | Everything works with a single tap or click. Maps can be zoomed with the + and − buttons as well as by pinching. |
| 2.5.3 Label in name | The name a screen reader announces includes the visible label. | Buttons and links are named with their visible text, so voice control users can say what they see. |
| 2.5.7 Dragging movements | Anything done by dragging can also be done another way. | Maps can be moved with the keyboard or their buttons, and every map has a list that gives the same information. No form needs dragging. |
| 2.5.8 Target size | Buttons and links are at least 24 by 24 pixels, or have enough space around them. | Buttons and form fields are at least 44 pixels tall. Small links outside of sentences are at least 24 pixels tall. |
Understandable
| Guideline | What it asks for | How this website meets it |
|---|---|---|
| 3.1.1 Language of page | The page’s language is set in the code. | Every page is marked as English, so screen readers use the right pronunciation. |
| 3.2.1, 3.2.2 On focus, on input | Nothing changes unexpectedly when you move to or fill in a field. | Choosing an option never sends a form or opens a new page. You decide when to continue or submit. |
| 3.2.3, 3.2.4 Consistent navigation and identification | Menus and repeated parts work the same way on every page. | The header, menu, search and footer are the same on every page, and the same features have the same names everywhere. |
| 3.2.6 Consistent help | Help is in the same place on every page. | Contact information, 311 and “Was this page helpful?” are in the same place at the bottom of every page. |
| 3.3.1, 3.3.3 Error identification and suggestion | Errors are described in text, with how to fix them. | Forms check your answers before sending. A list of problems appears at the top with a link to each one, and each field explains what’s needed, for example “Enter an email address like [email protected]”. |
| 3.3.2 Labels or instructions | Fields have labels and instructions. | Every field has a visible label. Hints explain formats before you type, and optional questions are marked “optional”. |
| 3.3.4 Error prevention | Check, change and confirm before submitting legal or financial information. | Applications and payments end with a review step where you can check and change your answers before sending. |
| 3.3.7 Redundant entry | You aren’t asked for the same information twice. | Each form asks for a piece of information only once, and the review step shows your earlier answers rather than asking again. If you allow it, your address is remembered for other pages. |
| 3.3.8 Accessible authentication | No memory tests or puzzles to sign in or to prove you’re human. | The site has no CAPTCHA or puzzles. Forms are protected against spam in ways you don’t see. |
Robust
| Guideline | What it asks for | How this website meets it |
|---|---|---|
| 4.1.2 Name, role, value | Assistive technology can tell what each control is and what state it’s in. | The site uses standard HTML controls. Custom parts such as menus, tabs and expandable sections tell screen readers whether they’re open or selected. |
| 4.1.3 Status messages | Updates are announced without moving focus. | Search result counts, saved settings, form progress and loading messages are announced by screen readers as they happen. |
Beyond the guidelines
- Plain language. Pages are written in short, clear sentences, with the most-needed tasks first.
- Text size and dark mode. Choose larger text or dark mode at the top of any page. The site also follows your device’s dark mode and reduced motion settings.
- Text view for City documents. Plans and reports open in a reader with a text view, so they can be read with a screen reader or enlarged without zooming the whole page.
- Works without scripts. Page content is plain HTML, so it still loads if JavaScript is blocked or a feature doesn’t load.
- Other languages. The Translate button at the top of every page translates the site with Google Translate. Automatic translations may not be accurate; the English version is the official one.
- Videos only play when you ask. Nothing plays sound on its own, and live streams start muted.
- Print-friendly. Pages print without menus and footers.
How we check
Accessibility is part of how every page is built and changed, not a final check. We use:
- Automated checks of each type of page (home, services, forms, maps, tables, news, careers, Council meetings and policies) in both light and dark mode. They test text alternatives, names for every field and control, duplicate IDs, heading order, colour contrast, target size, reflow at 320 pixels and visible keyboard focus. Problems are fixed before pages are published.
- Keyboard testing of menus, forms, the park finder, the document reader and payments.
- Design checks of every page at phone, tablet and desktop widths, in both colour modes.
Automated tools find only some problems. Before launch, the website should also be tested with screen readers (NVDA and JAWS on Windows, VoiceOver on Mac and iPhone, TalkBack on Android) and voice control, ideally by people who use them every day, and reviewed by an independent accessibility auditor. This page will be updated with the results.
Last reviewed: October 14, 2026.
Known issues
We know about these gaps and are working on them:
- Services run by other companies. Some tasks finish on another website: job applications (UKG), recreation registration (Amilia), Council agendas and minutes (CivicWeb), online payments, live video (Vimeo) and recordings (YouTube). We choose these services with accessibility in mind, but we can’t fix problems on their sites. If one stops you, contact us and we’ll help another way.
- Older PDF documents. Some older reports and bylaws are scanned or untagged PDFs that screen readers can’t read well. The text view in the document reader helps with many of them. We’re replacing the most-used ones with web pages or accessible PDFs, and can provide any document in another format.
- Live captions. Council meetings streamed live may not have captions. Recordings are posted afterwards on YouTube, which offers captions.
- Maps. Interactive maps are visual. The information on every map is also available as text: a list, a table or an address search.
Report a problem or ask for another format
If you have trouble using any part of this website, or need information in another format such as large print, plain text or a phone call, please tell us. Let us know the page and what happened, and we’ll work with you to get you what you need.
- Call 311 or 250-426-4211 (toll-free 1-800-728-2726), Monday to Friday, 8:30 am to 4:30 pm
- Email [email protected]
- Use “Was this page helpful?” at the bottom of any page
- Visit City Hall, 40 10th Avenue South
Feedback about barriers also goes to the City’s diversity, equity and inclusion program, which helps set priorities for improvements.
Page updated .