ADA compliance and monitoring for websites

ADA compliance and monitoring for websites

Purpose of this document

Compliance with ADA standards

It is proposed that all web properties use a continuous integration (CI) workflow to move code changes from a development, to a staging, to a production environment. Among the necessary steps, the user interface elements are passed through the open-source pa11y tool (pa11y.org) using Circle CI (circleci.com) combined with GitHub (github.com), which stops deployments automatically if changes introduce new issues with ADA compliance.

Workflow showing how changes are automatically tested for accessibility before being published to a public website

Please find this chart on Google Drawings

  • First, a change request is made affecitng the user interface design (and thus potentially breaking accessibility)
  • Developers build code changing user interface design
  • Code is pushed to a dev branch on GitHub
  • CircleCI runs automated accessibility (pa11y) tests on new code
    • If tests pass, the change is published to production
    • If tests do not pass, then change goes back to development team for tweaking

Auditable compliance

Every time new code is introduced into production-ready codebase, CircleCI runs the test suite, including accessibility (pa11y) tests. All tests results (artifacts) are kept for at least a year for auditing purposes.

Limiting non-compliant content added by site editors

On database-powered CMSs like Wordpress or Drupal, content is defined as editor-supplied data which typically resides in the database. For static site generators such as Hugo or Jekyll, the content resides in the code and is treated like code when it comes to testing for accessibility The following approaches are used to limit non-compliant content from being added to sites:

Training and oversight

All site editors are supervised by a content administrator who has a checklist of common accessibility issues such as:

Simplified WYSIWYG data entry

Text formatting is limited to semantically-relevant formats. The following formatting elements are allowed for site editors:

In contrast, formatting elements which do not convey intrinsic semantic meaning are not possible on the system:

In addition to ensuring a consistent design experience, this prevents common accessibility issues, for example, too-small text, or text with insufficient formatting.

Accessibility guidelines directly on the WYSIWYG in the form

As part of site editor training, have “accessibility guidelines” directly below the wysiwyg form.

Client-facing widgets

The Accessibe ADA or other client-facing widgets can be embedded directly on a website in order to provide non-technical clients with visibility on how accessibility issues are managed. The accessibe widget has the following features:

Steps in the accessibility pipeline