The Standards

Section 508 Standard:

• Standard 1194.24, c “All training and informational video and multimedia productions which support the agency’s mission, regardless of format, that contain speech or other audio information necessary for the comprehension of the content, shall be open or closed captioned.” (Section508.gov)

WCAG 2.0 Guideline:

• Guideline 1.2.2 “Captions (Prerecorded): Captions are provided for all prerecorded audio content in synchronized media, except when the media is a media alternative for text and is clearly labeled as such. (Level A)” (W3C)
• Guideline 1.2.4 “Captions (Live): Captions are provided for all live audio content in synchronized media. (Level AA)” (W3C)

What do the standards mean?

The ultimate goal is to maximize the number of people who can fully acquire and appreciate the information conveyed in the resource. This is done by presenting information to more than one of the senses; for example, design a resource so that users have the option to get the information via sound, sight or both. If the only way to get the information is to hear the audio then the resource is not accessible. If the only way to get the information is to see the illustrations, text and other visuals then the resource is not accessible. Any information presented visually should also be audible and vice versa.

Best Practices for Captions

When captioning a video, it is recommended the following guidelines.

Synchronized

Captions must be as closely synchronized with the audio as possible. This means the caption should appear on the screen at the exact same time as the equivalent audio is playing. There should not be any notable delay.

Error-free

Make sure the captions are free of non-purposeful spelling and grammar errors and have proper punctuation. Automatic, machine-generated captions are usually not 100% accurate. Be aware of this when using websites like YouTube. The only exception to this guideline is when the error in the captions is how it is presented in the audio and the error is important to the meaning that is being conveyed in the video.

On this same note, the captions should not phonetically adhere to a person’s accent because that could make it difficult for people to understand the captions. If it is necessary to note the accent of the speaker then add that information in brackets or parenthesis. Whether to include ‘ums’ and ‘ahs’ and other disfluencies depends on the type of video. Legal videos might require a strict transcription but then other types of educational videos might not. Research this prior to captioning.

Important non-speech audio

Include non-speech audio in brackets or parenthesis when that information is needed to fully understand the video. For example, it may be neccessary to include sound effects such as, “fire alarm”, “baby crying”, “music” or “car horn honking.” Some captioning tools provide icons that symbolize certain non-speech audio; for example, there may be the option to add music note icons before and after music lyrics in captions.

Names and titles of the speakers

When a new person begins speaking in a video, add the name of the speaker and that speaker’s title (if available) in the caption of their first line of dialogue. There are a couple different formats.

• >> Name of Speaker
• Name of Speaker:
• [Name of speaker]

As long as it is the same person speaking, it is unnecessary to put their name and title on every line. Also, it is best practice to avoid having dialogue from multiple speakers on the screen at the same time unless they are speaking simultaneously.

Consistent style and format

Try to be consistent with the format and style of the captions throughout the video. Some examples of consistency are:

• Use the same typeface, color, and font size for every line of captioning.
• Have the captions in the same location on the screen throughout the video.
• Use the same symbols for non-speech audio throughout the video.
• Use the same format for indicating a new speaker throughout the video.

Location and appearance

Most websites and software place the captions at the bottom center of the video screen. The only time to put them elsewhere is if the captions conceal important visual information. In that case, adjust the location. Only include one to three lines on the screen at a time. Make sure the captions are on the screen long enough that people of varying reading speeds can read them.

Make sure the text is as readable as possible by putting the text in a common sans serif typeface and in a color that does not blend into the background of the video.The text color and the background color should have a high contrast.

Real-time Captioning

For most web content the captioning process is done post-production. In other words, the media is transcribed and captioned after it is recorded and published. However, it is becoming more and more common to caption during a live video web event; for example, this is done with web conferencing and video streaming. This allows individuals who need captions to participate in live events. Usually, paid services are used for real-time captioning.

The Standards

WCAG 2.0 Guidelines:

• Guideline 1.4.5 a “If the technologies being used can achieve the visual presentation, text is used to convey information rather than images of text except for the following: (Level AA)
  • Customizable: The image of text can be visually customized to the user’s requirements;
  • Essential: A particular presentation of text is essential to the information being conveyed.” (W3C)

What do the Standards Mean?

OCR is a process of converting scanned images to recognizable printed text by a computer or other electronic devices.

What is scanning?

Most offices personal or professional are commonly using All-in-one printers. These printers can print, scan, and fax documents. The process of converting a printed document to electronic can be achieved by scanning. This scanned product, however, may or may not be accessible. Inaccessible scanned documents are images that do not have the ability to be recognized as text. So, what visually appears on the screen after the scan is “readable”, but if used in combination with assistive technology is only “seen” as an image with no text.

What is OCR?

The process of converting the scanned image to text that is readable by the computer or other assistive software is called OCR.

When an image is scanned it has the option to be saved as a PDF (Adobe reader compatible file). PDFs formats are commonly used to provide and disseminate documents in a learning environment. Saving a scanned image as a PDF does not necessarily mean that it is accessible.

There are several ways to check if your scanned PDF is an accessible file.

• Using the mouse, click in the document. If the entire text gets selected and it looks like one big image, it probably is. This format is inaccessible.
• Using your keyboard, execute the find command (i.e. Control + F for PC and Command + F for Mac). If you are unable to find text within the document the format is inaccessible.
• Within Adobe Reader (free software), go to the “view” menu, and “Read Out Loud”, “Activate Read Out Loud” or press Control + Shift + Y to activate read out loud. Now “Read this page only” with Control + Shift + V. If the reader starts to read the text the document is accessible. If not, it may say blank page.

Scanned, inaccessible PDF images can be converted to accessible PDF by executing the process of OCR. There are many off-the-shelf software available to complete this process. Operating systems are also providing built-in OCRs to help with the process. The All-in-One printer may also have software that performs OCR.

The Standards

Section 508 Standard:

• Standard 1194.2 “When software is designed to run on a system that has a keyboard, product functions shall be executable from a keyboard where the function itself or the result of performing a function can be discerned textually.” (Section508.gov)
  

WCAG 2.0 Guideline:

• Guideline 2.1 Keyboard Accessible: “Make all functionality available from a keyboard.” (W3C)

What do the Standards Mean?

Keyboard accessibility means:

• When assembling and/or creating websites, software, and multimedia, make sure users can navigate to and execute all the links, buttons and other interactive content using just keyboard commands. If a user has to use the mouse to fully interact with the resource then this standard is not met.
• When using keyboard commands to navigate the resource, check for a logical and instinctual order of navigation.
• For seeing individuals, it is clear when a link, button or another interactive element is selected because it has a border around it, a different background color or some other visual indicator.
• If the resource has a large amount of content then it should have a “skip to main content” link.

It is important to make content accessible with the keyboard alone because not everyone can use a traditional mouse. The reasons are unique to the individual. If a user can fully interact with a resource using the keyboard alone then that gives access to the largest possible audience (W3C, “Keyboard Accessible:Understanding Guideline 2.1”).

Examples of resources that are frequently not fully keyboard accessible are:

• Video players (especially Flash-based players)
• Drag-and-drop activities and videos with quizzes or interactive games built into them
• Some software and web applications

How do you Check for Keyboard Accessibility?

For most websites and software, users do not need a special software to check for keyboard accessibility. There is a simple way to test using just keyboard commands. Put away the mouse and use the following keyboard commands to navigate and to execute hyperlinks, buttons and other interactive elements in the resource.

Try to navigate through two popular websites using the following keyboard keys (without using the mouse) (WebAIM, “Keyboard Accessibility”).

• Clicking TAB repeatedly allows you to navigate from button to button and from link to link.
• Clicking SHIFT+TAB allows you to go back to the previous button or link.
• Clicking the SPACEBAR, the return or the enter keys when a link or button is selected activates that link or button.

Note which features are accessible and which are not accessible. If not all content is accessible without using a mouse then that resource does not meet the standards and guidelines listed.

The Standards

WCAG 2.0 Guidelines:

• Guideline 2.4.4 “Link Purpose (In Context): The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general. (Level A)” (W3C)
• Guideline 3.2 “Make Web pages appear and operate in predictable ways.” (W3C)

What do the Standards Mean?

A URL (a.k.a hyperlink) can be a long string consisting of letters, numbers, dashes, underscores, and other characters that connect the user to a web link. These combinations are not “words” and are often not meaningful or descriptive. This can be problematic for all users not only users of assistive technologies.  Adding display text to URLs makes them easier to read and understand for all users. There are a number of factors to consider when creating display text.

Readability and Length

Readability and length are two factors to consider when creating display text to replace a URL. When a screen reader reads a URL it may sound non-sensical since the long string of characters used in the URL are not “words”. Providing readable display text with meaning in the content allows a user to understand the relevance of that link.

While there no minimum or maximum limits or restrictions on the length of display text, there are some recommended best practices.

1. Display text should be concise yet long enough to convey the meaning of the link.
2. Avoid using entire sentences or paragraphs as display text. Display text of this length is often unnecessary and creates frustration for screen reader users since they must listen to the all of the display text . Short, concise links are less likely to frustrate screen reader users than long, imprecise links.
3. A descriptive short URL (e.g., a site’s homepage) can be used as the link text and does not require display text to meet compliance.
4. Creating display text of only one character can provide difficulty for some users.  If it is necessary to create display text of only one character, the recommendation is to increase the font size of the display text and add additional whitespace around the small display text. This will help to limit the issues encountered by users.
5. Avoid empty links. The display text provided should always link to a location where content is presented. Empty links are still navigable and can be frustrating for users.

Description and Meaning

A well designed link should be meaningful and descriptive.  The display text should provide the reader with the purpose of the link even when out of context.  Assistive technologies, such a screen readers,  have the ability to present a list of links on a web page to the user.  Using descriptive and meaningful links assists users in deciding which links to follow.

Opening a New Window

Display text should only open a link in a new window or tab when necessary.  Opening links in a window or tab can be confusing and disorienting for some users, particularly those user who have difficulty perceiving visual content.  Here are a few examples of when content should open in a new window:

• Context-sensitive information (e.g., help instructions)
• An alternate means of completing a form (e.g. a calendar-based date picker)
• In cases where the following a link will cause the user to be logged out of a secure area of a site

When it is deemed necessary to open a link in a new window, user should be provided advanced warning.  This can be accomplished through a visual warning or a warning spoken through the use of assistive technology.  Each of these warnings should state that this link opens in a new window.

Avoid using uninformative link descriptions

Links such as click here, read more, here, etc. do not offer a meaning and are unnecessary.  Typically, these uninformative links precede a more meaningful phrase so it makes sense to eliminate the uninformative link and use the more meaningful phrase as the display text.  In some cases it may be appropriate to include words like more in the display text; however it is usually best practice to avoid them especially if the same meaning is being conveyed in the context.

Following these guidelines and recommendations, when creating display text for URLs (a.k.a. hyperlinks) will result in descriptive and meaningful links that are functional and user-friendly; thus, providing a better experience for all users.

The Standards

Section 508 Standards:

• Standard 1194.21, h “When animation is displayed, the information shall be displayable in at least one non-animated presentation mode at the option of the user.” (Section508.gov)
• Standard 1194.22, j “Pages shall be designed to avoid causing the screen to flicker with a frequency greater than 2 Hz and lower than 55 Hz.” (Section508.gov)
• Standard 1194.21, k “Software shall not use flashing or blinking text, objects, or other elements having a flash or blink frequency greater than 2 Hz and lower than 55 Hz.” (Section508.gov)

WCAG 2.0 Guidelines:

• Guideline 2.2.2 “Pause, Stop, Hide: For moving, blinking, scrolling, or auto-updating information, all of the following are true: (Level A)” (W3C)
  • Moving, blinking, scrolling: For any moving, blinking or scrolling information that (1) starts automatically, (2) lasts more than five seconds, and (3) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it unless the movement, blinking, or scrolling is part of an activity where it is essential; and
  • Auto-updating: For any auto-updating information that (1) starts automatically and (2) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it or to control the frequency of the update unless the auto-updating is part of an activity where it is essential.
• Guideline 2.3.1 “Three Flashes or Below Threshold: Web pages do not contain anything that flashes more than three times in any one second period, or the flash is below the general flash and red flash thresholds. (Level A)” (W3C)

What do the Standards Mean?

For individuals with photosensitive seizure disorders, flashing or blinking lights can trigger seizures. Many animations (e.g. gif animation), visual effects (e.g. transitions in slides or videos) and objects that automatically update (e.g. RSS feeds) on web pages, videos, slide presentations, and games have rapid flashing or blinking components. Whether the resource is dangerous to individuals with photosensitivity depends on the speed and size of the animation; for instance, if the object is large and blinks more than three times in a second then it is dangerous. If the requirements are not met then that resource should not be used.

Whenever animations and visual effects are presented in a resource, ensure that any content conveyed by those animations and visual effects are also detailed in the accompanying text. In addition, provide a method for users to pause, stop or slow down the animation, visual effect or automatically updating objective. An example would be allowing users to control the play and speed of the automatic refresh of an RSS feed.

How to Test an Object?

One easy method for assessing whether or not an object meets the above standards is checking to see if the resource blinks or flashes more than three times in a single second. If it does then that animation, visual effect or object could potentially cause individuals with photosensitivity to have a seizure.

There are also tools available that can assess an object for issues related to photosensitivity. Review the page in week 6 for more information.

Tips for Using Animations and Visual Effects

While it is possible to make blinking objects safe, it is often easier and quicker to forgo using any blinking and flashing animations, visual effects or other related objects. Also, when creating slide presentations and videos, use simple, slow transitions and visual effects.

The Standards

Section 508 Standards:

• Standard 1194.21, g “Applications shall not override user selected contrast and color selections and other individual display attributes.” (Section508.gov)

WCAG 2.0 Guidelines:

• Guideline 1.4.4 “Resize text: Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality. (Level AA)” (W3C)
• Guideline 1.4.5 “Images of Text: If the technologies being used can achieve the visual presentation, text is used to convey information rather than images of text except for the following: (Level AA)” (W3C)

What do the Standards Mean?

There are a number of factors to consider when selecting which fonts to use when creating compliant content.  Some of these factors include but are not limited to, readability, font size, font variations, number of fonts used, etc.

When selecting a font for readability, choosing a font from the most commonly used font families which are universal to most devices is recommended.  The Serif and Sans-serif font families are two of the most common.  Known for its flared extensions and thick and thin lines, the Serif font family consists of Times News Roman, Georgia, and Antiqua.  The Sans-serif font family has more of a block appearance to its letter and consists of Arial, Tahoma, Trebuchet MS, and Verdana. Specific details on each of the fonts listed above can be found on WebAIM Font Techniques.

Although the number of fonts used in a text-based document is not directly tied to accessibility, it is often considered a best practice to limit the numbers of fonts used within a document.  This best practice also applies to the font variations.  Limiting the number of fonts and variations used can lead to better document readability and less confusion for readers.

Today’s browsers have made the selection of font size less important because users can magnify and shrink text based on their needs and preferences.  Content creators should select a font that maintains its readability and functionality when magnified or shrunk. Readability and functionality must be maintained at a magnification of 200% to be compliant.

How to Verify Text Formatting is Accessible?

1. Is the font selected from the Serif or Sans-serif font families?
2. Are there a limited number of fonts and font variations used in the text-based document?
3. When magnifying or shrinking the text is the readability maintained?

The Standards

Section 508 Standards:

• Standard 1194.22, c “Web pages shall be designed so that all information conveyed with color is also available without color, for example from context or markup.” (Section508.gov)
• Standard 1194.22, i “Color coding shall not be used as the only means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.” (Section508.gov)

WCAG 2.0 Guidelines:

• Guideline 1.4.1 Use of Color: “Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. (Level A)” (W3C)
• Guideline 1.4.3 Contrast (Minimum): “The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following:” (Level AA) (W3C)
  • “Large Text: Large-scale text and images of large-scale text have a contrast ratio of at least 3:1;
  • Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.
  • Logotypes: Text that is part of a logo or brand name has no minimum contrast requirement.”

What do the Standards Mean?

Many individuals benefit when a resource is designed with high color contrast between the foreground( e.g. text) and background colors. For instance, high contrasting color combinations (e.g. black text on a white background) make text easier to read for users with a wide-variety of visual impairments, including but not limited to partial sight, low vision, color-blindness, etc. High color contrast requirements can vary depending on the text size and type of content.

Users with visual impairments may not able to distinguish important information when its importance is conveyed only through the use of color.  For example, color-blind users may not know a field is required if the only feature identifying that field as required is a red label.  Important information conveyed through the use of color must also be conveyed using text cues.  Screen readers and other assistive technologies are able to interpret these text cues for users with visual impairments.  For example, when the text color of a form field is red to indicate it is a required field, adding the word “Required” after the field name will provide the necessary cue.

How do you Verify the Use of Color is Accessible?

WebAIM (Web Accessibility in Mind) provides a free color contrast checker to assist with developing compliant content.  To verify color accessibility, enter the foreground/text color and background color into the Color Contrast Checker to verify the colors selected “Pass” the ratio required for WCAG 2.0 AA guidelines for normal and large text.

The Standards

Section 508 Standard:

WCAG 2.0 Guideline:

• Guideline 2.4.6  Headings and Labels: “Headings and labels describe topic or purpose. (Level AA)” (W3C)

What do the Standards Mean?

Using word processing software’s built-in headings and list structure (e.g. Styles block in Microsoft Word) when creating text-based content benefits users of many types of assistive technologies; for example, users of screen readers. Screen readers do not convey headings and lists created with direct formatting (bold, italics, underline, numbering) to users; thus, users cannot distinguish between regular text and headings and lists created with direct formatting. On the other hand, built-in headings and lists are created in a way screen readers are able to interpret and communicate to users. Another example of assistive technology users who benefit are those who use navigation functions in some word processing software; for example, navigation pane (aka document map) in Microsoft Word.

How to Create Accessible Headings and Lists?

Creating accessible headings and lists is straight-forward. When creating a document using word processing software, choose one of the pre-made, built-in styles or layouts. For example, when using Microsoft Word, navigate to the Styles block and choose one of the heading style options listed. Also, select the bulleted list or numbered list button in Microsoft Word to use the pre-made list styles. For detailed information on how to create text-based documents using built-in headings and list structures, review the lesson available in week 6.

How to Verify Headings and Lists are Accessible?

Most word processing software provides a way to verify that a built-in style and/or list structure was used when creating a text-based document; for example, newer versions of Microsoft Word provide an Accessibility Checker that will confirm the use of built-in headings and lists.  Selecting and highlighting the text and then reviewing the setting in the Styles block is another way to confirm headings and lists are accessible. An option in the Styles block will be selected if the highlighted text was formatted with a built-in style.

The Standards

WCAG 2.0 Guidelines:

Guideline 1.3.1  “Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A)” (W3C)

What do the Standards Mean?

The markup language HTML is what determines text formatting on the web. Unfortunately, html does not work for mathematical equations. For this reason, many equations on the web are simply images of text saved in formats such as JPEG, PNG, GIF, etc. Equations displayed as image files are not accessible to people who rely on screen readers because screen readers are designed to only read text formatted by markup language.

There are two primary methods to make equations on the web accessible to all users:

• Add alt text if the equations are saved as image files. The alt text should spell out the names of each of the symbols in the equation. For example, for the equation 2(4y+1) = 3y, the alt tag would state, “2 open paren 4 y plus 1 close paren equals 3 y.”
• Instead of using image files, it is recommended that you use a software or an online tool that allows you to produce equations in accessible formats using mathematical markup language (e.g MathML).

What is MathML?

MathML is a mathematical markup language. Merriam-Webster defines a markup language as, “a system (such as HTML or SGML) for marking or tagging a document that indicates its logical structure (as paragraphs) and gives instructions for its layout on the page especially for electronic transmission and display.” The markup language, MathML, is the accessible, W3C-approved way for displaying equations. Most web browsers support it either directly or with a plugin.

Example of Markup Language MathML

MathML Code	Text Display
<math xmlns=”http://www.w3.org/1998/Math/MathML”><mn>2</mn><mo>(</mo><mn>4</mn><mi>y</mi><mo>+</mo><mn>1</mn><mo>)</mo><mo> </mo><mo>=</mo><mo> </mo><mn>3</mn><mi>y</mi></math>	2(4y+1)=3y

While adding descriptive alt text to equations that are displayed as images, the preferred method for making equations accessible is to use a software or a tool that will produce an equation using markup language such as MathML. If you are interested in learning about the technical aspects of MathML, review this W3C page on MathML Fundamentals.

How do you use MathML?

The easiest way to produce MathML is to use an equation tool that supports it. An example is the MathType integration for Microsoft Word. When this product is installed, the user can click a button in the toolbar in Microsoft Word to insert an accessible equation into a document.

You can review this W3C wiki for a list of MathML supported tools for more information on this topic.

The Standards

Section 508 Standards:

• Standard 1194.22, g “Row and column headers shall be identified for data tables.” (Section508.gov)
• Standard 1194.22, h “Markup shall be used to associate data cells and header cells for data tables that have two or more logical levels of row or column headers.” (Section508.gov)

WCAG 2.0 Guidelines:

• Guideline 1.3.1 “Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A)” (W3C)

What do the Standards Mean?

These standards specifically refer to tables used to present data. Tables used for website layout purposes are not included because it is recommended that developers refrain from using them. Using layout tables may not make a website inaccessible; however, it takes an extensive amount of time and effort for the developer to ensure the tables are compliant. The same functionality can be achieved through easier website development methods.

Individuals without visual disabilities may use visual cues to determine the layout and structure of a data table. They can differentiate between header cells and data cells by looking at their location on the table and the text formatting. Headers are usually in the first row and/or first column and are formatted differently than the data cells. Using that information, they can deduce how to read the table. Alas, individuals with visual disabilities who rely on assistive technology cannot deduce how to read a table using these same methods. To read a table, these individuals rely on features added with markup language (e.g. html). The rationale is similar to that of headings and list structure in that users of assistive technology cannot tell the difference between header cells and data cells when differentiated only by direct formatting; therefore, developers should use markup language (e.g. code) to indicate:

• The row and column headers
• The association between data cells and header cells

For complex tables, it is also helpful to add the following features:

• Table Caption
• Summary Attribute
• Use a Simple Layout
• Avoid Blank and Merged Cells

Example Table

The following table has all of the stated accessibility features:

Superpowers of Super Heroes by Publisher

Publisher	Name	Superpower
DC	Superman	X-ray vision, flight, super strength, heat vision, super speed
Marvel	Hulk	Super strength

The Markup Language (Code)

Review the markup language or code for the Superpowers of Super Heroes by Publisher table:

<table summary=”Read from left to right.”>
<caption>Superpowers of Superheroes by Publisher</caption>
<tr>
<th scope=”col”>Publisher</th>
<th scope=”col”>Name</th>
<th scope=”col”>Superpower</th>
</tr>
<tr>
<th scope=”row”>DC</th>
<td>Superman</td>
<td>X-ray vision, flight, super strength, heat vision, super speed</td>
</tr>
<tr>
<th scope=”row”>Marvel</th>
<td>Hulk</td>
<td>Super strength</td>
</tr>
</table>

Table Caption

The caption is used to give the table a title or a label. The caption is indicated in the example with the code:

<caption>Superheros</caption>.

Row and Column Headers

The row and column headers create structure for the table to help users navigate the content. The headers are indicated in the example with the code: <th></th>.

Association Between Data Cells and Header Cells

In addition to the row and column header, information about how they are associated with the data must be provided. Associating data cells with header cells requires the code: scope=”row” and scope=”col”.

Summary Attribute

For accessibility purposes, the summary attribute is used to provide additional information about how a table should be read or notes about the formatting and layout. The summary attribute is not displayed on the table itself; it is only visible in the code. This is indicated in the example with the code: summary=”Read from left to right.”

How to Make a Table Accessible?

Most tools for creating tables have editing features that allow developers to add some or all of the above features. While not all tables need a caption or a summary, if your tool does not allow you to add row and column headers or  associate headers with data cells then developers should use a different tool.