Accessibility Policy [WIP]

General Overview

Websites, just like buildings, can be accessible or inaccessible. When you build a building and only put stairs allowing someone to get in, that removes entrance (or makes entry extremely complicated) for anyone who cannot step up those steps to enter. The same is true for websites. If we build a website that isn't readable by a screen reader, for example, those who try to enter will get stuck.

Our job is to ensure that the websites we build or maintain are as accessible as we can make them to remove as many barriers as we possible can for those who need an alternate entry. When we do our job right, the sites we care for are accessible for people with a diverse range of hearing, movement, sight, and cognitive ability.

Initial 2 Paragraphs Proposal

The internet is no different than any other space: people of all kinds use it. Also just like physical spaces, the internet is used by plenty of people with various disabilities. While the needs in physical building design are understood well enough, in the digital realm, the need to support users with disabilities is an, unfortunately, often-ignored aspect of websites and apps.

Given the Cantilever philosophy of Digital Hospitality, we must strive to design and create websites that provide an accommodating, accessible space. When our job is done right, we not only send our messages to the greatest amount of people, but we present as few barriers as possible to ensure people can reach it at all.

At Cantilever, we believe accessibility should start when the project itself starts. From initial designs, to code development, to finished product testing, we aim to incorporate accessibility checks throughout the entirety of our process. Many of the sites we currently run are just beginning to see and understand the large benefits of having an accessible website. Our goal is for accessibility to be front of mind for our clients when thinking about their websites.

One key piece of accessibility work is that there is no official standard that websites must meet in order for a site to be deemed accessible "enough" from a legal standpoint. The waters are muddy in this area. Because of this we have decided that our goal for our sites is to have a WCAG AA level accessibility.

What is WCAG?

The Web Content Accessibility Guidelines (WCAG) is the most-used, internationally-recognized, series of standards for creation of accessible digital content. The guidelines strive to be technology-neutral, testable, and accommodate a wide range of needs for people with disabilities. Although no standard can guarantee all user needs for all disabilities are met, the WCAG recommendations are among the most fundamental principles of an accessible web.

Cantilever works towards reaching WCAG AA conformance for the sites we support and create. We work closely with clients to discuss accessibility issues both reactively by fixing what's present, and proactively by reviewing proposed work for potential accessibility concerns. Should an accessibility problem arise that we can't address, either by client request or from using inaccessible third-party content, we strive to note awareness of the problem in any reports.

Types of Accessibility Work

There are different types of accessibility work that we do at cantilever.

Audits

Tests

Screen reader test

Manual test

Design Audit

Accessibility in Budget and Scope

Operational Definitions

Other

Here are all our accessibility procedures:

Questions we want to answer:

  1. What is accessibility? (General Overview) (Nikki)
    1. implied, always done with QA
    2. Textexpander (grab snippets for accessibility tasks, audit info etc).
    3. Explain WCAG AA Compliance goals/ how this works
  2. Why do we do accessibility? (Nikki)
  3. What are the different ways to do accessibility? (audits, tests, project / types) (Nikki)
  4. What does accessibility testing should look like during User Experience & Visual Design? (Raul)
  5. Accessibility in the budget and scope of work(Raul).
    1. Example. (Links to older WBSs)
    2. Link to historical documents
  6. Operational definitions. Audit versus testing? (Nikki)
    1. Audit is report?
    2. Testing is fixing? Confirm with team!

Other:

  1. Link all Accessibility procedures (Nikki)
  2. Add Florian's testing and Dev fixes(Raul).