We build accessibility in from the first component.
We believe a website for a public place should welcome everyone who wants to visit, whatever device they use and however they take in a page. So we settle contrast, focus and page structure in the design system before anyone designs a page, and every page built from it starts accessible. Below, you can see this site through ten simulated views and run a check on this page yourself.
We tested this site on October 7, 2026.
Automated tests with axe Deque Systems publishes axe as an open-source testing engine. It checks a page’s code against WCAG rules and powers the accessibility audit in Lighthouse. found no violations on any of the 15 pages we checked at desktop and phone widths.
Lighthouse Lighthouse is an audit tool that Google builds into Chrome. It scores a page for accessibility and speed, and by default it simulates a mid-range phone. gave every page an accessibility score of 100 on a simulated phone.
Every page fit a screen 320 pixels wide without scrolling sideways.
At 200 percent browser zoom, text on every page stayed readable and none of it overlapped or got cut off.
The W3C’s Nu HTML Checker found no errors in any page’s markup. Our accessibility statement lists every test.
Every text colour in this site’s palette clears the 4.5:1 line.
Each chip shows a pair in its real colours on a scale that runs logarithmically from 1:1 to 21:1. Your browser measures every pair from this page’s own colours, so the numbers follow the theme you’re using.
These colours sit on the paper.
- Ink16.75 to 1
- Grey text6.78 to 1
- Accessibility blue7.34 to 1
- Work red7.28 to 1
- Capture green5.89 to 1
- Studio purple7.96 to 1
- Contact amber6.05 to 1
White text sits on each floor colour.
- Accessibility blue7.96 to 1
- Work red7.90 to 1
- Capture green6.39 to 1
- Studio purple8.63 to 1
- Contact amber6.56 to 1
WCAG 2.2 Level AA The Web Content Accessibility Guidelines come from the W3C, and version 2.2 became a W3C Recommendation in October 2023. A page meets Level AA when it passes every Level A and Level AA success criterion. asks for text contrast of at least 4.5:1, targets of at least 24 by 24 pixels, text that can grow to 200 percent and pages that Reflow A page reflows when its content fits a window 320 pixels wide without scrolling sideways. That matches a small phone, or a desktop browser zoomed to 400 percent. at 320 pixels wide.
Use this page the way other people do.
Choose a view, and the sample changes to show how someone with that kind of sight or setup meets it. We built the sample from this site’s own components and colours. Every view is a simulation that runs in your browser.
Wildcoast Adventures

Guests walk a boat-access camp before they book it.
The Still · 50°29′ N 126°30′ W
Each floor has a colour and a name.
- Work
- Accessibility
- Capture
- Studio
- Contact
A screen reader announces the sample in this order.
- link The Still, home
- button, collapsed Accessibility settings
- button, collapsed Menu
- text 02
- text Work
- text 4 of 5 case studies
- heading level 3, link Wildcoast Adventures
- image Sea kayakers return to Orca Camp at sunset on Johnstone Strait.
- text Guests walk a boat-access camp before they book it.
- text The Still · 50°29′ N 126°30′ W
- link See all our work
- text Each floor has a colour and a name.
- list, 5 items
- text Work
- text Accessibility
- text Capture
- text Studio
- text Contact
- end of list
This view shows the sample in this site’s own type and colours as most visitors see it.
With protanopia, the red of the Work floor darkens to an olive grey, and the Accessibility blue and the Studio purple become almost the same blue. Each floor still carries its name beside its colour, so visitors can find it without telling the colours apart.
With deuteranopia, three of the five floors turn a similar olive brown. Each floor’s name sits next to its colour, so nobody has to tell those three apart.
With tritanopia, the Accessibility blue and the Capture green turn into the same teal. The underlined links and the bordered button still stand out without any help from colour.
Without colour, all five floors turn into greys of nearly the same lightness. The text keeps its contrast, because contrast measures the difference in lightness between text and its background.
Blurred sight wipes out fine detail first. We keep body text at 18 pixels or more and set headings far larger, so the page’s structure still shows through the blur.
Here the text is twice its usual size in a column as narrow as a phone. We set the sample’s breakpoints in ems, so its layout rearranges around the bigger text and every word stays on screen.
High-contrast settings replace a site’s colours with a set the visitor picks, and this view uses black and yellow. Our buttons carry borders that show up in these modes, and the heading link keeps its underline.
Keyboard users move with the Tab key, and the numbers show the order focus takes through the sample. On a computer, press Tab now and a thick ring follows you from stop to stop.
A screen reader turns the sample into speech, and the list shows what it announces in order. We build that list from the sample’s code as you watch, and each screen reader words some of those lines in its own way.
Klue’s teams built more with Nectar once it became simpler to use.
Klue’s design team simplified Nectar until the right component was the obvious one, and it held office hours for the teams building with it. Designers and engineers used the system more and shipped faster. For Klue’s customers, the product grew more consistent and took less effort to move through.
- Company
- Klue
- Place
- Vancouver
- Sector
- Competitive-intelligence software
- The work
- A simplified component library, design tokens, accessible patterns, documentation, a guild with office hours and a process for extending the system
- Design direction
- Adam Bognar
- Role
- Director of Design at Klue from 2022 to 2025
- Design and engineering
- Klue’s design and engineering teams

What they needed
Klue makes competitive-intelligence software in Vancouver, and its designers and engineers build the product side by side. The product had grown quickly, and Nectar had grown along with it. Duplicate components and legacy patterns made the right piece slow to find, and a gap kept widening between what designers drew and what engineering shipped. Klue needed a system both teams would reach for first, and it had to keep improving after release with accessibility in every component.
What Klue’s design team did
The work followed a principle of reduce, then refine.
The team simplified the library until the right component was the obvious one.
Duplicate components came out first. The team then rebuilt the core components that remained so each one did a single job, and the button family below shows how far the cuts went.
This drawing shows each of Klue’s button variants as a plain block.
Accessibility came built into every component.
Each one followed an accessible pattern and took its values from Nectar’s Design tokens Design tokens store design decisions like colours and spacing as named values. Designers and engineers read the same values, so a change in one place reaches every screen. .
The team documented every component and stayed on hand to help.
Each component came with written guidance on when and how to use it, so nobody had to guess. The team formed a guild to look after Nectar and held office hours where the teams using it could bring a question or a problem.

A formal process let the system grow with the product.
A new component, or a change to an existing one, followed a set path into Nectar, and parts of that path ran automatically. Customers rarely saw the system itself. It sat under the screens they used and let Klue’s teams change those screens faster.
What changed
The button family shrank from 63 variants to 12.
Variants across Klue’s wider component library fell by more than half.

Designers and engineers used Nectar more, and delivery on the work Klue tracked sped up by about 30 percent.
Klue built its brand refresh and its vision for the product on Nectar.

Run a quick check on this page.
The button below reads this page’s code in your browser and reports what a script can measure on its own.
A person checks by hand whether each description suits its image and whether the headings make sense together.
- Landmarks
Looks for the page’s Landmarks Landmarks mark out the main regions of a page, and screen reader users can jump straight from one region to the next. and checks that each navigation region has its own label.
Not run yet - Headings
Checks for a single h1 and for heading levels that never skip a step.
Not run yet - Images
Makes sure every image has alternative text or is marked as decoration.
Not run yet - Names
Confirms that every control has a name a screen reader can announce.
Not run yet - Contrast
Measures each text pairing in the palette against 4.5:1.
Not run yet - Language
Reads the language the page declares.
Not run yet - Title
Reads the page title.
Not run yet - Target size
Measures every button and standalone link against 24 by 24 pixels.
Not run yet - IDs
Looks for any id that appears twice.
Not run yet - Motion
Reads your reduced motion setting.
Not run yet
Accessibility runs through every stage of our work.
The same small team carries that work from the first workshop to the monthly update.
1 Discovery
We learn how people use your current site.
We read your analytics and walk through the site with the staff who update it. Then we talk with the people who visit it.
2 Design system
We design the system before we design the pages.
We check each colour pairing for contrast before it reaches a page. Each component’s specification includes its focus state and a touch target big enough for a thumb, and body text stays readable on a phone at default zoom.
3 Build
We build the theme from the design system’s tokens.
The code reads the same values as the designs, so visitors get the contrast we checked.
4 Testing
We test every template with a keyboard and a screen reader.
Automated checks run on every template. We also go through each one using only a keyboard, and again with VoiceOver VoiceOver is the screen reader Apple builds into macOS and iOS. It reads a page aloud, and people can jump through it by heading or by link. on a Mac and an iPhone.
5 Training
Your editors learn to keep the site accessible.
The editing tools we set up keep headings in order and ask for alternative text on every image. We train your editors on a copy of your site, so they can practise freely.
6 Support
We keep checking the site after launch.
On a support plan, we test each new page for accessibility and try every monthly update on a staging copy before it reaches the live site.
Tell us if anything on this site gets in your way.
If any part of this site is hard to use, email info@wearethestill.ca. Tell us the page and what got in your way, and we’ll write back.
