Skip to main content

Website Accessibility Guide

Accessibility is one of the most important aspects of modern web development. Accessibility means the greatest number of users can view our content. Also, we are required by law to make our sites accessible.

Section 1

Resources

We follow WCAG 2.0 AA as our standard for accessibility. WCAG (Web Content Accessibility Guidelines) has long been the gold standard for accessibility on the web.

What is know as Section 508, which is the law that determines what is required for accessibility has decided to adopt the WCAG guidelines. So now WCAG has become the standard to follow.

Resources

Tools

Sites and Tutorials

Section 2

Checklist

This checklist helps developers identify potential accessibility issues affecting their websites or applications. It's broken down into three sections of decreasing importance: A, B and C. Please check and address these issues in the order in which they appear.

It is important to note, while B and C are noted as less critical, they are still required to be truly 508 compliant. This checklist should be used as a reference for development and is not a substitute for compliance checks by a section 508 coordinator.

A - Critical

B - Less Critical

C - Minor

Section 3

Tools

Color Tools

Color Impairment

Accessibility Review Tools

These tools can be used to test sites for Section 508 and WCAG compliance in browser:

Autocomplete Widgets

These JavaScript widgets produce HTML with ARIA autocomplete attributes:

Automated Testing

These tools can be used in automated tests and with continuous integration tools to help you ensure that your sites remain accessible throughout the development process:

There are many other npm packages tagged wcag and a11y.

Section 4

Keyboard Access

Testing

  1. Identify all interactions on the page.
  2. Using the tab, enter, and space bar, navigate the page and ensure each input and interaction can be triggered.
    • Ensure rollover and hover interactions (help text, etc) can be triggered as well.
    • If the user cannot interact with something, or get the information another way, this is a failure.
  3. Make sure the tab order of the page is logical and follows the visual order of elements on the page.
    • If the tab order is confusing, this is a failure.
  4. Check that the focus is always visible when moving through the page with the tab key.
    • If you lose focus, on a hidden link or other object when simply tabbing through the page, this is a failure
  5. Make sure you can tab through the page and get back the address bar.
    • If you ever need your mouse to get back to an element, this is a failure.
  6. Keyboard users must be able to easily use and dismiss modal dialog boxes, lightboxes, or other pop-ups.
    • Modal dialog boxes need to trap the keyboard. When a modal dialog box is triggered, the keyboard focus needs to immediately move to the first actionable element in the modal.
    • The keyboard cannot use the modal dialog box until it is dismissed. When a user moves the keyboard focus past the last element in the modal dialog box, it needs to loop to the beginning of the dialog box.
    • The keyboard user needs to be able to access all controls in the dialog box, especially the controls to dismiss the dialog.
    • If the keyboard user cannot do all of these things, this is a failure.
    • Ideally, the keyboard user should also be able to dismiss the modal dialog box with the Escape key.
  7. If an interaction reveals hidden content.
    • Ensure the focus is moved to the revealed content.
    • If this does not happen, check for a programatic description of the change.
  8. Check for title tags providing information not on the screen.
    • Title attributes which can only be exposed by hovering the mouse over the element are a failure of keyboard access.
  9. Check that the focus never goes to elements that won't be available to somebody using a mouse.
    • If the keyboard focus goes to an offscreen element that has been temporarily hidden (items in a non-expanded drop-down menu, offscreen modals which haven't been triggered, etc.), this is a failure.

Avoid using tabindex of >= 1 as this will disrupt the normal tab order of the page. tabindex of -1 is only appropriate when autofocusing an element not normally interactive.

Section 5

Images

When using images on a page, you must provide an alternate method for that content. This can be provided in multiple ways. You can provide this information with a caption, alt tag or aria label. If an image has text, all the text in the image must be provided in the alternate content.

Each alt tag should contain the following:

Correct use of alt tag

Sign that reads Warning do not read this sign
<img src="/accessibility/images/sign.jpg" alt="Sign that reads Warning do not read this sign">
	  	

Avoid using "Image of" or "Picture of" as the screen reader will notify the user that it's an image. Also avoid using all caps as some screen readers will read each letter. ie. W-A-R-N-I-N-G

Section 6

Color and Contrast

Color Contrast

There are two aspects we need to address when it comes to color, contrast and color dependence. Color contrast is the ratio of the foreground color(text) and the background color. Color dependence is the need to see color to understand the information. Color contrast should meet the WCAG 2.0 AA minimum color contrast ratio of 4.5:1.

All states of the text (hover, visited, focused) should meet this requirement. This also applies to images of text unless the image is a logo, which are exempt.

Contrast Chart

Color Dependence

Section 7

Forms

Making forms accessible is a simple process. Each form element should be associated with its instructions and errors, and everything should be accessible via the keyboard.

Testing

  1. Identify each form element.
  2. Find all instructions associated with each element.
    • If a form element isn't programmatically associated with ALL instructions, this is a failure.
  3. Ensure all field elements are accessible via the keyboard.
    • If the form cannot be filled out with just a keyboard, this is a failure.

Each form element must have a label, and is associated with the for tag. The for tag refers to the id of the input. All elements should be wrapped in a fieldset. There can only be one legend tag per fieldset. Anything in the legend tag will be associated.

Fieldset and legend is often used for radio buttons as its the easiest way to associate the radio buttons with the question. Notice there is no label for the radio buttons, but each button has a title tag for assistive technology to read.

How ARIA affects form inputs

Screen readers vary on what they read and the additional information they provide by default.

You can test these with your own screen reader. If you have a OSX you can turn voice over on by hitting command+f5.

Section 8

Flashing

Flashing is generally a bad idea. It can cause all sorts of issues, from seizures to motion sickness. If you absolutely must have a flashing element there are a few things to consider.

Testing

Section 9

Page Titles

Page titles are important because they help a user navigate their browser. Most users have multiple tabs open at once. It's easier to jump between pages if each page title is unique. It's also helpful to have the unique portion first, usually the name of the page.

Testing

  1. Check that the title shown in the tab for the page is unique and describes the page accurately.
    • The title should be in plain English.
    • The title should describe the web site as well as the specific page being displayed by the site. By including Denver Public Schools in your title you will increase your page rank in search engines
<title>Page Name - Denver Public Schools</title>
	  	
Section 10

Headings

When laying out a page, headings provide a semantic way to lay out sections of content. A heading element briefly describes the topic of the section it introduces. Heading elements are used by users of AT to navigate a page quickly and to understand the structure of a page.

When using heading elements. reserve the <h1> element for the page title. On the home page, this is usually the title of the site and on other pages, this may be the page title. Use the <h1> element once per pageā€”some assistive technology may be unable to read multiple <h1> tags on a single page correctly. Other heading levels may be used more than once following document outline order and you may reset headings up to <h2> with the <section> element.

For sub sections, use <h2> to <h6> in document outline order. <h1> is the most important and <h6> is the least. Avoid skipping headings. Avoid breaking document outline order (you may go from <h1> to <h3>, but never <h3> to <h1>).

Section 11

Hidden Content

Hiding content is very useful for accessibility. We can hide things visually and only display it to screen reader users, we can hide content from screen reader users and only show it visually, or we can hide content from both.

Aria Hidden

aria-hidden should be used in combination with these techniques. If we want to hide something from just the screen reader, you can mark it as aria-hidden='true'.

Items with aria-hidden='true' are always ignored by the screen reader. This is useful for: - Collapsing Menus - Repetitive information - Off screen content

If an element has multiple states, it's visibility should be tracked with aria-hidden true/false. An element with aria-hidden='false' is treated by the screen reader as if it didn't have the aria-hidden attribute and is read or not read based on other factors, such as CSS.

Using CSS display:none; will visually hide but also hides content from Screen readers.

Section 12

Landmarks

All elements on a page should be contained in a landmark element. This helps users of AT quickly navigate a page. An example of a landmark element would be a navigation menu. In HTML 4 this would be assigned an ARIA tag of role="navigation". However, in HTML 5 you just wrap your navigation in <nav> and do not need to add the "navigation" role. HTML5 provides built in landmark elements such as main, nav, aside, header, footer. When using HTML5 elements, there is no need define role.

Section 13

Multimedia

When using multimedia, we must provide means for everyone to consume the media. Multimedia is anything that uses audio and video.

Closed captioning

Videos with audio require synchronized closed captioning. Anything said in the video must be included in the closed captioning, and anything in the closed captioning must be said in the video.

Audio description

Audio description ensures any information displayed visually is conveyed via audio. The most basic example of this is text on screen. All the text on screen should be available by audio. This can be done a couple of ways. The script for the video can be written in a way that all visual information is read by the narrator. The other way is to add a separate audio track that describes the visual content. This can be done with a special player or a separate version of the video with the audio baked in.

Keyboard Access

Just a note about keyboard access. All video controls should be accessible via the keyboard, but it's also worth noting that time stamp information should be available to screen readers as well.

Section 14

Tables

When tables are used to show data, the header cells that relate to the data cells need to be programmatically linked. This makes table navigation for screen readers less painful.

Simple tables can have two levels of headers. Each header cell should have scope='col' or scope='row'.

Complex tables are tables with more than two levels of headers. Each header should be given a unique id and each data cell should have a header attribute with each related header cells id listed.

Section 15

CSS Dependence

CSS dependence just means site shouldn't rely on CSS to be functional or understandable. Often sites will use CSS to load important images for example. This is bad for several reasons. Background images can't be tagged for accessibility and with CSS turned off they aren't shown.

The other issue that pops up with CSS dependence is content order. Sometimes, content will be arranged on screen with CSS instead of the natural code flow.

Testing

  1. Disable CSS.
  2. Check for missing information (images, text, etc).
  3. Check for code or other items the developer doesn't want you to see.
  4. Check for overlapping text.
Section 16

Links and Repetitive Content

Links are commonly used to quickly navigate a site when someone is using AT. Often, screen reader users won't read through an entire page to find what they are looking for. They simply move from link to link.

Things become problematic when links only make sense with context. Links such as 'Click Here' or 'Read more' don't make sense without that visual context. It's important that we inspect our sites for these types of links. These links can be made accessible using title or ARIA attributes, but this isn't ideal. The ideal method for making these links accessible is just to write better link text.

The other issue screen reader and keyboard users come across is lengthy nav bars. These are usually made up of a list of links and with compound menus. They can be quite lengthy to tab through. To alleviate these pains, a skip navigation link should be provided. This is the first link on the page and jumps to an anchor with a tabindex='-1'.

Testing

  1. Identify links with the same text.
    • If they point at the different location, check for ARIA attributes to distinguish them.
  2. Identify links with generic text ('Click here', 'Read more').
    • Check for ARIA attributes to provide context or additional off-screen text.
  3. Identify links that open in new windows.
    • Verify that some indication is given programmatically - aria-label='Opens in new window'

DPS Technology Architecture and Strategy