Accessibility: Rights & Responsibilities
Empowering teams to create the new industry standard
Table of Contents
A Common Vocabulary5
Technology (Design/Dev) Team’s Responsibilities
Content Team (Authors / Manager's) Checklist
Just What We Do
Glossary of Accessibility Terms
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.
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.
- Design and Development Team: The technical group responsible for the theme, coding, and overall environment in which the website content resides. This includes your UX Designer, and Front and Back-End developers.
- The Content Authors/Managers: The individual(s) responsible for posting content: textual content, imagery, audio and/or video, onto a website. This group will be expected to work from the Drupal Administration and Third-Party Sources (ie YouTube, Wistia etc) to create meaningful content and post it on the website.
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.
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
- Understand how screen readers work, and the accessibility tree model
- Your developer and designer team should have a firm understanding of how assistive technology parses the structure of HTML pages, the necessity of tag attributes, and how they can influence the structure.
- The objective of this technique is to mark up the structure of the Web content using the appropriate semantic elements. In other words, the elements are used according to their meaning, not because of the way they appear visually.
- Dom Order
- The objective of this technique is to ensure that the order of content in the source code is the same as the visual presentation of the content. The order of content in the source code can be changed by the author to any number of visual presentations with CSS. Each order may be meaningful in itself but may cause confusion for assistive technology users.
- Offscreen Content
- Allow for adequate spacing between links to allow for easier usage
- Color and Contrast
- Be aware that the site/colors proposed meet the contrast requirements
- Links are underlined
- Using Heading Tags
- The objective of this technique is to use HTML5 heading markup to provide semantic code for headings in the content. Heading markup will allow assistive technologies to present the heading status of text to a user. A screen reader can recognize the code and announce the text as a heading with its level, beep or provide some other auditory indicator. Screen readers are also able to navigate heading markup which can be an effective way for screen reader users to more quickly find the content of interest.
- Role Name and Values
- Keyboard Actions
- Keyboard Traps
- Text Alternatives/Image Alt
- Make sure that the fields for this are there and required
- Skip Link
- Provide internal page links to aid navigation inside of the current page, instead of new pages; allowing users to 'skip' over repetitive content.
- Aria Relationships
- Keep in mind that no Aria is better than bad Aria!
- Modal Elements
- High Contrast Support
- never use inline scripting
- No-JS Alternatives
- Maximize compatibility with browsers and user tools
- User testing to include screen readers and other assistive technologies available
Content Team (Authors / Manager's) Checklist
- Use appropriate alt text.
- Good Example: Middle aged man sitting in metal chair in waiting room.
- Poor Example: Man in chair.
- Failing Example:
- Provide text alternatives for non-text content.
- Think inclusively about your media. Do more than only provide captions and other alternatives for multimedia; effectively communicate non-text content in such a way that gives it context and meaning. It's not only about sight, it's about educating the user as to what value the media provides.
- Image message aligns with content on the page
- Complex images have a separate text area to provide context
- Automatically moving, blinking, or scrolling content that lasts longer than 5 seconds can be paused, stopped, or hidden by the user. Moving, blinking, or scrolling can be used to draw
- If the same visual presentation can be made using text alone, an image is not used to present that text.
- Use descriptive links. Avoid using web addresses as the link text
- Good Example: Visit our sister site for more information on getting started.
- Poor Example: Get started today!
- Failing Example: Click here.
- Avoid using web addresses as the link text and other uninformative phrases
- Keep your web addresses or URLs short
- Create a summary of the content within your table
- Identify row and column headers
- Only use tables for tabular data
- Standard alignment of text and use of white space, allowing for higher readability
- Use plain language
- Use San serif fonts
- Be concise with your writing
- Use active voice when writing
- Be weary of using placement words like above or below.
- Define all acronyms
- Avoid using ALL CAPS
- Avoid underlining unless you are linking to content
- Use bold and italics sparingly and only for emphasis
- Color is not used as the sole method of conveying content or distinguishing visual elements.
- Symbols (***) are needed for emphasis when font color is changed
- Instructions do not rely upon shape, size, or visual location
- Create headings and heading levels to show order of importance within your page
- should be used to show a hierarchy in your content structure
- Provide descriptive text transcript
- Audio no or very low background noise so the speech is easily distinguished.
- Provide synchronized captions for all pre-recorded audio
- Audio descriptions are provided for all video content when the information is not conveyed in the audio
Audit the site periodically, using software, built-in-reports, or by an accessibility consultant (provide recommendations).
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.
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.
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.
- 508: 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.
- A11Y: Accessibility (a11y) is a measure of a computer system's accessibility is to all people, including those with disabilities or impairments. It concerns both software and hardware and how they are configured in order to enable a disabled or impaired person to use that computer system successfully.
- Accelerator keys / Keyboard shortcuts: Usually combinations of characters that allow users to make software commands instead of interacting with menu options or different levels of a user interface, also known as keyboard shortcuts.
- Accessibility: The measure of a web page's usability by persons with one or more disabilities.
- Alternative Text: Short text used described images---usually 125 characters or less.
- 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.
- Audio browsers: Web browsers that provides a text-to-speech capability for the blind and visually impaired.
- Braille terminal: Machines that convert text on a screen to braille by raising bumps through holes on a flat surface.
- Captioning:The art of adding captions to a television program or movie.
trong>Captions: A textual representation of sounds--usually associated with television programming or movies; captions are meant to display in real time and to capture speech sounds and sounds beyond speech in some cases.
- Clickability cues: A visual indication that a given word or item on a Web page is clickable. Cues that can be used to indicate the clickability of an item include color, underlining, bullets, and arrows.
- Disability: A limitation in an ability. Types of disabilities include but not limited too:
- Auditory, Cognitive Disorders,Seizure Disorders, Visual Impairments, and Motor Disabilities.
- Early adopters: A user who has a tendency to embrace new technology before the majority.
- Graceful Degradation: When a site utilizes new technology, if disabled, the content maintains effectiveness for the users.
- H-Tags: The <h1> to <h6> tags are used to define HTML headings. <h1> defines the most important heading. <h6> defines the least important heading. There should be only one <h1> tag (the page title) and they should be used in a hierarchy.
- Heat maps: Color-based representations of areas of interest/focus points; generally associated with eye-tracking software.
- Internationalization: A system whose primary design has been developed to work in multiple languages and in the cultural contexts of different locales.
- JAWS: ("Job Access With Speech") is a computer screen reader program for Microsoft Windows that allows blind and visually impaired users to read the screen either with a text-to-speech output or by a refreshable Braille display.
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.
- Late adopters: Individuals who are hesitant to adopt new technology.
- Localization: Customizing or personalizing a national or international product for a local market.
M, N, O
- Programmatic Focus: Where the computer's focus is on a Web page.
- Screen reader: A software program used to allow reading of content and navigation of the screen using speech or Braille output. Used primarily by people who have difficulty seeing. JAWS and NVDA are examples.
- Section 508 [see also 508]: 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. The law applies to all Federal agencies when they develop, procure, maintain, or use electronic and information technology. To learn more go to 508.gov.
- Transcript: A text only version of what's said in a movie or television program; they are not real time and they generally are limited to speech only; they are not a recommended substitute for captions.
- Visual Focus: Where the user's focus is on a Web page; generally represented by a dashed box that appears around items on the page and associated with tabbing.
- 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.
X, Y, Z
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.
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.
Captions, Transcripts, and Audio Descriptions
- WebAIM’s Web accessibility for Designers
- WebAIM's WCAG 2.0 Checklist
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.
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