Accessibility: Rights & Responsibilities


Empowering teams to create the new industry standard

V 1.0

 

 

Table of Contents

Introduction

Assumptions:

A Common Vocabulary5

Checklists

Technology (Design/Dev) Team’s Responsibilities

Content Team (Authors / Manager's) Checklist

Implications

Just What We Do

Appendix

Glossary of Accessibility Terms

Caveats

Sources

Resources

Testing

Statistics

Legal Examples

Code Libraries

Drupal Modules

Credits

 

Introduction

Accessibility means your website can reach more people, be compliant with laws, and overall meet the new industry standards, but for some teams that can seem overwhelming. It does not have to be. Your groups likely already have the resources you need, it’s a matter of organization and understanding who is responsible for which parts of the process. In this guide we will breakdown the roles and responsibilities of both the design/development team and that of the content authors/managers. By outlining how each sub-group can make a positive impact in accessibility, and listing out some of the tools to aid them on their way, this once overwhelming initiative can become your standard operating procedure.  

It’s about simplifying, understanding and practice.

Assumptions:

The first, and most obvious assumption is that you are, at least in part, responsible for a website and it’s overall usability. Yes, accessibility is just another aspect of the user experience (UX) - adapting to assistive technologies much as our industry has adapted to the use of mobile devices over the years. If you’re even tangentially responsible for your website you should be familiar with this document. This may help you know what you are responsible for, or simply give you a lead as to whom on your team you should ask your questions.

You have decided your site must meet the USA’s 508 Compliance standard. In this document we will often go back and forth between the USA’s 508 Compliance and the international WCAG A, AA, and AAA ratings. Though in many instances a AA rating is more accessible than the 508 Compliance rating, we will default to a AA rating as the goal with the understanding that this will also ensure the site is 508 Compliant.

You have separate parties responsible for design and development than you do for content authoring and management. We understand that in many cases we are grouping many sub-teams into larger groups, but for the purpose of this document’s goals, we are defining what is the role of a web development group/department/company/agency as the more technical and the content authoring/management as the more ‘in the thick of it’ role. In future versions of this document these sub-groups shall be broken down further.

A Common Vocabulary

A more complete glossary [put in link] has been included at the end of this document but to start we need the meanings of a few common terms to be agreed upon.

508 Compliance: Section 508 of the Rehabilitation Act was enacted to eliminate barriers in information technology, to make available new opportunities for people with disabilities, and to encourage development of technologies that will help achieve these goals. Under Section 508 (29 U.S.C. § 794d), Federal Agencies must give disabled employees and members of the public access to information that is comparable to the access available to others.

Accessibility: The measure of a web page's usability by persons with one or more disabilities.

Assistive Technologies: Technologies (software or hardware) that increase, maintain, or improve the functional capabilities of individuals with disabilities when interacting with computers or computer-based systems.

Disability: A limitation in an ability

WCAG 2.0: The Web Content Accessibility Guidelines (WCAG) 2.0 is focused on providing an international technical standard for web content. It has 12 guidelines that are organized under four principles: perceivable, operable, understandable, and robust. The guidelines each have a testable success criteria, which are at three levels: A, AA, and AAA.

Checklists

To create checklists that would effectively cover each specialization while promoting the industry standard we have relied heavily on our Sources; please reference those for additional information.

Technology (Design/Dev) Team’s Responsibilities

General

Design Focused

Markup Specific

Content Team (Authors / Manager's) Checklist

Images

Links

Tables

Text

Semantic Structure

Multi Media

Overall

 

Shared Responsibilities

In most cases we have tried to break down which team is responsible for each aspect but in some cases the teams simply need to share the responsibilities. We recommend detailed worklogs and open communication between the teams to make the following easier for all parties to maneuver.

 

Implications

If your website team agrees upon the use of these checklists than you have assigned the rights of ownership and the responsibilities to make sure your team progresses in an accessibility-friendly manner both at the time of development and moving forward. This is not about assigning blame if there is a problem but rather knowing who to ask for help when questions arise. This document was written in the spirit of open-source and the authors promote it’s use as a team empowering, problem solving tool that will take this once overwhelming undertaking and breaking it down to it’s manageable parts.

 

Just What We Do

As one of this document’s authors cannot seem to stop saying, accessibility needs to become ‘just what we do.’ As parties responsible for the creation and maintenance of websites we understand that our teams could never create and launch a site without each member of the team understanding their role in the larger undertaking. This document provides that same service, the same roadmap for this aspect of the UX. We welcome community feedback, support and perspective as we, as a larger group, work together to make accessibility the new industry standard.

 


 

Appendix

Glossary of Accessibility Terms

Like most specific areas of expertise, the world of online Accessibility has terminology that you may not have come across before. In this section we will explain a common phrases.

#

A

D

E

H

I

J

K

L

  • Long Descriptions: Descriptions that are written for complex figures and tagged via the long desc attribute; though not currently supported by most Web browsers, the long desc attribute is a planned feature in the next iteration of Firefox.
  • Luminance Contrast Ratio: A measure of the difference between foreground and background; specific minimal values are recommended via WCAG 2.0.
  • M, N, O

    P

    Q, R

    S

    T

    U

    V

    W

    X, Y, Z

    Caveats

    The purpose of this document is to create a better understanding between different parties responsible for the accessible nature of your website. This is not intended to be a legal document; it has not been written by legal experts of any governing entity, but by Drupal community members who are passionate about accessibility, user experience (including the content managers user experience), and website excellence as a whole.

    Sources

    In many cases our check list criteria has been taken directly from these sources. We've done this to maintain the clarity that they had already produced and to help promote these industry standards.

    https://content-guide.18f.gov/

     

    http://webaim.org/techniques/alttext/

     

    http://a11yproject.com/checklist.html

     

    Captions, Transcripts, and Audio Descriptions

    http://webaim.org/techniques/captions/

     

     

    http://webaim.org/resources/designers/

     

    https://www.w3.org/WAI/WCAG20/quickref/

     

    https://www.wuhcag.com/wcag-checklist/

     

    http://webaim.org/

     

    http://webaim.org/standards/wcag/checklist

     

    https://www.w3.org/WAI/WCAG20/glance/WCAG2-at-a-Glance.pdf

     

    Resources

    Testing

    http://www.iamcal.com/toys/colors/index.php

    Vischeck

    Statistics

    Legal Examples

    Code Libraries

    Drupal Modules

    Credits

    If you contribute or even take this document to adapt it to your organization's needs please add your name. Let us know you’re working towards making this part of the communities outlook.

     

    Authors

    Donna Bungard, Digital Strategist @ Mediacurrent

    Jason Cortes, Full Stack Application Developer @ NYS Office of Information Technology Services

    Kristen Albright, Information Technology Specialist 3 @ NYS Office of Information Technology Services

     

    Adopters