Our core philosophy is “Digital Hospitality” – The idea that websites are spaces people inhabit, not billboards to be viewed at a distance. Central to implementing that philosophy is making our websites accessible to the broadest number of visitors, and building them such that visitors with disabilities can use them successfully.

Digital Accessibility and the Law

There is no clear letter of the law about what private websites must do regarding accessibility. The Americans with Disabilities Act (ADA) is silent about websites - because it was made law before the World Wide Web existed! However, courts have seen websites as “places for public accommodation”, and it’s through that interpretation that the ADA becomes involved.

For determining accessibility of a site, the most common standards applied are the Web Content Accessibility Guidelines (WCAG). The WCAG has three levels of accessibility conformance:

  • A: Urgent problems, both in number of users affected, and how severe the barrier is.
  • AA: Common issues that are significant barriers
  • AAA: The most stringent accommodations one can make.

WCAG Level AA has been treated as the standard by American courts: case law shows that if your website conforms to WCAG 2.1 Level AA, you are almost certainly within the requirements of the law. Indeed, Section 508, the US Government’s standard for digital accessibility, is heavily based on WCAG 2.0 Level AA.

Our Goals

Cantilever sites aim to conform to WCAG 2.1 Level AA, with select Level AAA criteria as well when possible. In addition, as of May 2022, we seek to conform to the known new criteria of the upcoming WCAG 2.2 guidelines. By setting our sights higher than the "legal minimum" of Level AA, we ensure we not only provide hospitality to disabled users, but also protect our clients from legal challenges.

Our ultimate goal is the ability to confidently tell current and prospective clients that our sites will not only stand up to legal scrutiny, but that users of any physical and visual ability will have a great experience. This goal requires perpetual effort: we must continually self-improve in education, training, and awareness to stay up-to-date with our practices.

Intentions Beyond WCAG 2.1 Level AA

As of this writing (Q2 2022), WCAG 2.2 is expected to launch within the year. We want to try and “forward-port” the known criteria so that the transition to a new set of standards is not a shock to us or our clients. Only one new criteria in WCAG 2.2, Focus Appearance (Enhanced), is Level AAA, meaning all other criteria are essential and non-negotiable.

WCAG 2.2 Criteria
  • 2.4.11 Focus Appearance (Minimum)
  • 2.4.12 Focus Appearance (Enhanced)
  • 2.4.13 Page Break Navigation
  • 2.5.7 Dragging Movements
  • 2.5.8 Target Size (Minimum)
  • 3.2.6 Consistent Help
  • 3.2.7 Visible Controls
  • 3.3.7 Accessible Authentication
  • 3.3.8 Redundant entry

We have identified and selected multiple WCAG 2.1 Level AAA criteria that we believe are essential to a good user experience on the web. These criteria are treated as non-essential, but should be aimed for when possible. If a website can achieve a Level AAA criteria with minimal trouble, we should do it.

WCAG 2.1 Level AAA Criteria Goals
  • 1.3.6: Identify Purpose
  • 1.4.9: Images of Text (No Exception)
  • 2.1.3: Keyboard (No Exceptions)
  • 2.2.3: No Timing
  • 2.2.6: Timeouts
  • 2.3.2: Three Flashes
  • 2.3.3: Animation from Interactions
  • 2.4.8: Location
  • 2.4.9: Link Purpose (Link Only)
  • 3.2.5: Change on Request
  • 3.3.6: Error Prevention (All)

Our Approach

To achieve this, Cantilever has begun considering accessibility at every step of a project. By "shifting left" and prioritizing accessibility earlier in a project's timeline, we identify and fix problems before they ever truly become problems in the first place. In addition to early project planning considerations, we perform two phases of accessibility checking during a project's life: design and near the end of development.

Accessibility is everybody's responsibility. Accessibility tests are mainly performed by QA, but all team members are to be aware of accessibility principles. Designers are expected to know accessible UX, color contrast rules, etc. Developers are expected to know accessible markup, how interactive elements should behave, etc.

Most accessibility issues start at design. Our grid-driven, minimalist aesthetic lends itself well to accessible designs. Design issues are much easier to fix before development, when things are not yet finalized. It is better to find and fix a design problem early before there is too much momentum to change.

In development, our default development methodology makes some a11y concerns simpler for us to handle compared to the “let's use React for everything“ crowd. Accessible development practices, we believe, are also fundamentally good development practices: clean, semantic HTML and standards-conforming interactive controls produce well-written, elegant code and consistent, pleasant-to-use pages.

Further External Reading


Accessibility & Design
Client Accessibility Guide
Sample Client Emails re: Accessibility