Skip to Main Menu Skip to Page Content Skip to Footer
Design System 1.6.1
  • Resources
  • Accessibility Guide

Accessibility Guide

Updated: 09/02/2020

Table of contents

What is accessibility?

Ensuring that all of Dell’s global sites and pages can be used by the widest possible audience, including people with disabilities, in a way that is comparable to that provided to individuals without disabilities.

Types of short-term and long-term impairment:

  • Vision – Ability to see or process visual information.
  • Hearing – Ability to hear or process acoustic information.
  • Motor, physical – Ability to interact with a device accurately and quickly.
  • Cognitive – Ability in mentally demanding areas such as reading, memory, attention, complex concepts or language.

References:

W3C Accessibility introduction

Web Accessibility initiative introduction

Developing a Web Accessibility Business Case

FCC CVAA accessibility requirements in the United States Federal Register

Web Accessibility in Mind

Web Accessibility Tutorials – Guidance on how to create websites that meet WCAG

Jim Thatcher Web Course 1

Level Access Accessibility Training Resources

Principles of accessibility

Perceivable – Web content is made available to the senses – sight, hearing and touch.

Operable – Interface forms, controls and navigation are operable.

Understandable – Content and interfaces are understandable.

Robust – Content can be used reliably by a wide variety of user agents, including assistive technologies.

References:

Understanding the Four Principles of Accessibility

How People with Disabilities Use the Web

WCAG 2 at a Glance

Web Content Accessibility Guidelines (WCAG) Overview

The four principles in detail

Perceivable

  • Provide text alternatives for any non-text content.
  • Provide alternatives for time-based media.
  • Create content that can be presented in different ways without losing information or structure.
  • Make it easier for users to see and hear content.

Success Criteria

1.1 For all non-text content, text alternatives can be created and changed into other equivalent forms that users may need, such as large print, braille, speech, symbols or simpler language.

For example: Create text alternatives and detailed long descriptions for images to communicate their meaning to users. Provide appropriate alternate text that can serve as a functional replacement for the image or describe the meaning and content of the image in the correct language for that region. This includes banners, buttons, and any other image except those that do not used purely for decoration or does not convey a meaning such as a spacer or vertical divider line image.

A few short text alternative and long description examples:

@alt
the <img> is located within a <figure> that has a non-empty <legend>
@role="presentation"
@aria-describedby

For more information, see W3C ARIA Usage.

1.2 Time-based media, audio and or video content, is provided in various alternate formats.

For example: For video only content, provide an audio and text description. For audio only content or audio with video, provide text captions.

1.3 Create content that can be presented in different ways without losing information or structure.

For example: Design for clear hierarchy and page purpose without relying on sensory characteristics (shape, size, visual location, orientation or sound). Use semantic markup appropriately, with the reading and navigation order determined by code order being logical and intuitive.

Example of semantic markup:

<header> <h4>Header text</h4> <p>Subhead text</p> </header>

For more information, see WebAIM.

1.4 Make it easy for users to see and hear content.

  • Do not use color or other visual cues as the only means of conveying information or distinguishing elements.

    • Color alone is not used to distinguish links from surrounding text, unless the luminance contrast between the link and the surrounding text is at least 3:1 and an additional differentiation (e.g., it becomes underlined) is provided when the link is hovered over or receives focus.
    • The use of visual cues (e.g. color, text formatting, etc.) to convey meaning is strongly discouraged. For indicators, always repeat the name of the color in the description, such as “the blue start button”.
  • If any audio automatically plays for more than 3 seconds, controls are available to pause, stop or reduce the audio volume independently from the overall system volume.
  • Use color combinations with text and backgrounds that offer minimum contrast for legibility. See the detailed guidelines for Font Color and Contrast for more info.
  • Text can be resized without assistive technology.
  • Text is used to convey information instead of images of text (exception: logos). Do not place text, characters or numbers inside of images or other non-text executions.
  • Use adequate font sizes and line heights for all content while staying under 15 words per line.

  • Reduce or eliminate the use of alphanumeric characters as decorative elements.

    • Screen or JAWS (Job Access with Speech) readers will read aloud non-alphanumeric characters.
    • Use of these characters (examples: | : – >
    • For example: “Click Start, then click Programs, then click Command Prompt” instead of “Click Start > Programs > Command Prompt.”
    • For more information, visit http://www.standards-schmandards.com/?s=characters.

References:

Perceivable – Information and user interface components must be presentable to users in ways they can perceive

Web Accessibility for Designers

Color contrast analyzer

Color accessibility article

Colour blind Awareness

Operable

  • Make all functionality available from a keyboard.
  • Provide users enough time to read and use content.
  • Do not design content in a way that is known to cause seizures.
  • Provide ways to help users navigate, find content and determine where they are.

Success Criteria

2.1 All functionality of content is operable through keyboard interface without time limitations, in addition to other input devices.

Example of keyboard handling:

<input type="image" src="stuff.gif" alt="Do stuff" class="do_stuff" />
  • Focus is never locked and the user is able to tab or navigate to and from all content using only a keyboard.
  • Enable voice input for site chat and other feedback tools.

  • Whenever possible, document keyboard shortcuts in reference and procedural documentation:

    • Type out the name of all keys (e.g., “Control” and not “Ctrl”).
    • Use a plus sign to signify simultaneous keystrokes (e.g. Control+Alt+G, not Control-Alt-G).

2.2 Provide users enough time to read and use content.

  • Make timed elements time adjustable.
  • Allow users to pause, stop or hide moving, blinking, scrolling or auto updating information.
  • Interruptions can be postponed or suppressed by the user, except interruptions involving an emergency.
  • Re-authentication is possible without loss of data if a session expires.
  • Keep in mind that it can take ten times as long for an individual with disabilities to complete a task such as filling out a form in an application.

2.3 Do not design content in a way that is known to cause seizures.

  • For example: Do not show anything that flashes more than three times in any one second period.
  • Solution: Do not overuse animated images or moving text.

2.4 Provide ways to help users navigate, find content and determine where they are.

  • Allow users to bypass or skip blocks of content that are repeated on multiple pages, such as the masthead.

    Example of skip navigation:
    <div id="skip_menu">
    <a href="#main_content" class="skip_navigation">Skip Navigation</a>
    <a name="top"></a>
    </div> <!-- end skip_menu -->
    <style>
    div#skip_menu {
    position:relative;
    }
    div#skip_menu a.skip_navigation {
    position:absolute;
    top: -1000px;
    left:-1000px;
    height: 1px;
    width: 1px;
    overflow:hidden;
    }
    div#skip_menu a.skip_navigation:active, div#skip_menu a.skip_navigation:focus div#skip_menu a.skip_navigation:hover {
    position: absolute;
    top:auto;
    left:auto;
    width:100%;
    height: 1em;
    width: auto;
    font-size:1em;
    font-weight:bold;
    width:100%;
    padding-bottom:15px;
    color: black;
    z-index:100;
    text-align:right;
    margin-bottom:25px;
    }
    </style>
    <nav&g
    …
    </nav>
    <section id=”main_content”>
    …
    </section>

  • Ensure pages have titles that describe the topic or purpose.

    Example of page title:
    <head>
    <title>Lorem Ipsum Dolor</title>
    </head>
    <body>

  • The focus order in pages preserves meaning and operability.

    Example of logical tab order:
    <a href="" tabindex="1">one</a>
    <a href="" tabindex="2">two</a>
    <a href="" tabindex=“3">three</a>
    <a href="" tabindex="4">four</a>

  • The purpose of each link can be determined from the link text alone. “Click Here” is not a meaningful text link that describes the purpose or destination of that hyperlink.

    • When creating hyperlinks, use meaningful text. For example: “For more information, see RAID Type.” is preferred over “Click Here for more information about RAID types.”
    • Be brief.
    • Remember that it is more difficult for a visually-impaired user working with a screen reader to go back and re-read something than it is for a sighted user. Write in such a way to avoid causing confusion in this context, and avoid excessive use of parenthetical asides.
    • A good rule of thumb is to think about how the sentence would sound if you read it aloud to yourself. If it is difficult to follow when being read aloud, it is difficult to follow using a screen reader.
  • Provide users with an opportunity to navigate the site in more than one manner.

  • Headings and labels describe the topic or purpose of content in order.

    Example of descriptive headings:
    <h4>Install The Latest Widget</h4>
    <p>Downloading instructions</p>
    <p>How to install</p>

    * Note the importance of having only one h4 tag.

  • Keyboard focus is made visible.
  • Provide ways for users to orient themselves within the site.

References:

Operable – User interface components and navigation must be operable

Understandable

  • Make text content readable and understandable.
  • Make web pages appear and operate in predictable ways.
  • Help users avoid and correct mistakes.

Success Criteria

3.1 Make text content readable and understandable.

  • The default human language of the page can be programmatically determined.

    Example of showing the language of a page:

    <html lang="en">

  • Limit acronym use.

    • Screen readers try to pronounce acronyms as words if there is a phonetic similarity to a real word. If not, the screen reader will spell out the acronym. For example, the “ME” in ASM/ME would be pronounced as the word “me,” not as the acronym “M.E.”
    • Before using any acronyms in your documentation, consider how the screen reader will process the text.
    • For more information, visit: http://www.webaim.org/techniques/screenreader

  • Limit the use of text styling as the only way to convey information.

    • In their default configurations, Screen readers do not add emphasis when they read text to the user. JAWS can be configured to use a different voicing for text marked for emphasis in HTML but it is not the default configuration for the software and may not be used for pdf or Word formats.
    • There is no distinction made between italicized text, bolded text, strikethrough text, etc. There is just the “regular” voice and the “default” voice.
    • Putting important text in italicized, strikeout or boldface text for emphasis will not be of any use to the visually-impaired user.

3.2 Make the web page appear and operate in predictable ways.

  • When components receive focus, it does not initiate a change of context.
  • Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component, i.e. ensure users have control over opening windows or tabs.
  • Navigational mechanisms that are repeated on multiple web pages occur in the same relative order.
  • Components that have the same functionality are identified consistently.
  • Data tables should have properly defined column headers associated with their table cells.
  • Do not build slow loading pages.
  • Do not create static sites that are not responsive to devices, screens and browsers.

3.3 Help users avoid and correct mistakes.

  • If an input error is automatically detected, the item is identified and the error is described in text and not only in color.

    Example of error messaging:

    "Error – this is a required field and cannot be left blank."
  • Labels or instructions are provided when content requires user input. Ensure all form fields are explicitly associated with labels that are located near the form fields. Error messages should appear with the field they are referencing and not after the form.
  • Prevent errors by allowing users to reverse submissions, provide opportunity to correct errors and provide a mechanism for reviewing, confirming and correcting information before submission.
  • Group related form fields together by utilizing proper markup to help comprehension.
  • Ensure form fields are contained in a logical tab order.

References:

Understandable – Information and the operation of user interface must be understandable

Web Usability creating accessible forms

Robust

  • Maximize compatibility with current and future user agents, including assistive technologies.

Success Criteria

4.1 Maximize compatibility with current and future user agents, including assistive technologies.

  • Ensure code is complete, clean and understandable so that assistive technologies can accurately interpret and parse content.

    • Stay up to date on evolving standards and regulations.
    • Perform continuous user testing to ensure the site is always improving.
    • Test your site with screen readers (JAWS for example) and other devices and methods such as using keyboard input only.
    • Implement and continuously improve on existing executions.
    • Do not implement third party site solutions, media, content or services without verifying that they are accessible.

References:

Robust – Content must be robust enough that it can be interpreted reliably by a wide variety of user agents

WAVE evaluation tool, WCAG 2.0 checklist

WebAIM Section 508 checklist

WAI evaluation resources

JAWS screenreader software

Using WAI-ARIA in HTML

Semantic structure

Summary: Semantic structure refers to the way we use language to convey meaning. In the context of web design, it refers the way the content is laid out on the page through the proper use of heading elements.

What is meant by semantic page structure?

Proper semantic structure allows users to understand the organization of the content of the page. Standard HTML enables hierarchical structure by use of the heading elements (h1, h2 and so on). When used correctly, headings set up a parent/child relationship that orders content in an outline format which helps to organize material into relevant sections.

Sometimes headings are used differently than the way they were intended by the originators of HTML, who didn’t anticipate the graphic potential of the web. When headings are used solely for visual effect, either in isolation or outside of the outline structure, it can interrupt page hierarchy in a way that can cause confusion to non-sighted users who use keyboard navigation to tab through page sections by moving from header to header, effectively skimming the document to understand the overall subject of the page as well as the points covered section by section.

Example of proper heading structure:

  • H1
    • H2
      • H3
      • H3
    • H2
      • H3
      • H3
        • H4

Example of improper structure:

    • H3
  • H1
    • H3
    • H3
  • H1
    • H4
    • H4
    • H3
    • H2

Design Process

Good page structure can and should be planned for and reinforced at every step of the design process.

UX architects can create wireframes that are organized hierarchically.

Copywriters/editors can ensure that the content is written so that it’s presented in logical page sections and that it has a clear progression.

Designers can make decisions about the presentation that include the appropriate HTML and CSS attributes, or make recommendations for updating the CSS when and if the need for a new style arises.

Keeping semantic structure in mind throughout the design process will make it easier for front-end developers to code to accessibility standards. The more thought given to page structure up front, the less the dev teams will need to come up with workarounds to implement accessible code (or even worse, be forced to ignore the guidelines altogether).

Key Points:

  • Only one h1 per page.
  • Lay the page out in a hierarchical manner.
  • Design with requirements in mind.
  • Do not use headings for visual effect only.
  • Likewise, do not use text formatting such as font size or bolding to give the appearance of a heading.
  • If an existing heading style does not work for your design, update the CSS to include new styling that does, do not substitute a different heading tag if it breaks page hierarchy.

References:

Web AIM Semantic Structure

W3C Headings

Video of non-sighted user navigating by headings

Font color and contrast

Summary: Color contrast is the ratio between the color of the text in the foreground vs. the color of the background. It is important to have enough visual separation to make the text readable for those who are color blind, people with vision impairments such as the farsighted or those with cataracts or other age related vision degradation. It can also benefit people reading in less than ideal conditions, such as glare on their monitor screen.

Minimum Contrast Ratio: Dell adheres to the W3C Web Content Accessibility Guidelines (WCAG) 2.0, Level AA standard, which is:

  • 4.5:1 contrast ratio for normal and small fonts
  • 3:1 contrast ratio for large fonts

Exceptions:

  • 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.

Color contrast may be measured using the Web AIM Contrast Checker tool.

Common color combinations using the Dell palette

  • Text Combinations

  • Black or Carbon on White = always good

  • Dell Blue on white = pass

  • Carbon on Quartz = pass

  • Dell Blue on Quartz = fail at normal, pass at large

Do not place information in font sizes or color combinations that do not provide sufficient contrast.

Use the Dell Technologies colors.

Normal text size to pass Level AA WCAG 2.0 standards:

  • Regular: 11px-24px
  • Bold: 11px-19px

Large text size to pass Level AA WCAG 2.0 standards:

  • Regular: 24px & up
  • Bold: 19px & up

Use white text on these background colors, or use these as text colors on a white background, at any text size.

Dell Blue
Carbon
Red
Berry
Purple
Midnight

Use white text on these background colors, or use these as text colors on a white background, only at large text sizes (shown here).

Gray
Gray
Green
Green
Orange
Orange

Use black text on these background colors.

White
Quartz
Sky
Alert Yellow
Yellow

DO NOT USE these colors combined with white.

Granite
Quartz
White
Yellow

All other color combinations need to be checked using a tool such as the WebAIM contrast checker to ensure they can be used.

References:

WebAIM contrast

W3C Visual Color Contrast

Images

Summary: Images by their very nature convey visual information. If you use images on your site that contain crucial information then you must include a text alternative.

Alt vs. title attribute: Use the alt attribute of the image tag for alternative text (“alt” in this case literally means “alternative”). The intended purpose of this attribute is to provide text that can be read by screen readers or for when images are turned off in the user’s browser settings. Do not use the title attribute to convey crucial information, as it is not universally recognized by screen readers and will not always be read.

Images used for decoration: If you are using images solely for decoration/enhancement (slice of life imagery, visual separators, flourishes) then you most likely do not need a text alternative. There is no hard and fast rule. One must determine whether the image extends the comprehension of the content on the page or whether the text alone provides enough understanding.

Images that are specifically used to present information to the user, such as graphs, maps, diagrams, among other examples, will likely require alternative text, if the relevant information is not also included in the page copy.

Embedded text: Numbers & alpha characters should be true text (html) and not embedded within images.

Color: Do not use color alone to convey meaning or context as a person with color blindness or low vision will have difficulty discerning distinctions when color is the sole means of differentiation.

Icons: Icons should be treated as other images. If the icon is not accompanied by a true text equivalent, then use alternative text to convey the meaning.

Logos: Logos are exempted from the WCAG requirement for alternative text.

References:

Web Accessibility in Mind – Images

W3C Image examples

Keyboard navigation

Summary: The ability to navigate by keyboard is one of the most important mechanisms for achieving accessible web presentation. It factors in to the use of screen readers, and is also instrumental for people with limited motor skills, poor manual dexterity, those with paralysis and anyone else who may not want to or be able to use a mouse to interact with screen elements.

Use of Tab key: Keyboard only users can use the Tab key to jump through to links/CTAs, skipping over the content to set cursor focus on the actionable areas of the page. For sighted users, it is crucial to include a visual indicator (such as a border or outline) to illustrate where the cursor is positioned, thus allowing them to understand their location within the page.

Keys commonly used in keyboard navigation:

  • Tab (forward)
  • Shift + Tab (backward)
  • Up/down arrows (to scroll up and down – see screen reader shortcut keys for different uses)
  • Enter (to activate interactive element)

Keyboard navigation and screen readers: Screen readers can also use the tab key (and in most cases number keys 1-6) to “skim” the page by setting focus on the heading elements, which allows them to get a sense of the page topic and the general subject of each section. Refer to the documentation on semantic structure for information on proper page formatting.

Screen reader shortcut keys:

Enabling successful keyboard navigation

Skip to Content: Keyboard/screen reader users may not have a need to tab through or listen to every element in the masthead or global navigation, especially if they have previously encountered a page with those same options. Including a “skip to content” link allows users to bypass this repetitive content. There are several approaches to incorporating this type of link:

  • Make link visible to all users: This satisfies accessibility concerns but could be confusing and/or distracting to sighted users.
  • Hide the link so that it is only perceivable by screen readers. Preserves the aesthetic of the design but does not support the sighted keyboard only user.
  • Hide the link by default, but make it appear when it receives focus. In this case the link should not be evident to the mouse user, but will be perceivable to both screen reader users and sighted keyboard users.

Differentiating Links: Since keyboard navigation lets users move from CTA to CTA it is important, particularly for screen reader users, to make each link/CTA distinct and their purpose self-evident. A series of “Learn More” or “Shop Now” links on your page does not tell the user what to expect without the context of surrounding content. There are a couple of methods of addressing this issue:

  • Use specific link/button labels: The simplest method is to use distinct labels or descriptions as space and/or your naming convention allows. Examples: “Learn More about Tablets” or “Shop for Accessories Now.”
  • Use “hidden text”: An alternative to distinctive labeling is to employ text that is not a visible part of the link or button label but which can be perceived by a screen reader. Many people mistakenly believe that the use of the “title” attribute takes care of this, however it is not actually read by most screen readers and use of the title attribute is discouraged by the W3C (though there are situations where the title tag is useful).
  • Instead, try setting up your CSS to allow for hidden text, which positions text off-screen so that it’s not visible to a sighted user but still able to be perceived by a screen reader.

Example of hidden text styling:

.hidden
{position:absolute;
left:-10000px;
top:auto;
width:1px;
height:1px;
overflow:hidden;}

Design Approach: Creating a keyboard accessible page isn’t just a coding exercise. Good accessibility practices start with good page design.

  • UX architects and designers should keep tab order (the sequence in which the user navigates from one element to the next) in mind with good semantic structure.
  • Copywriters/editors should ensure that elements that receive focus are comprehensible in isolation and can be understood without relying on surrounding copy for context.

Key Takeaways: A sizable percentage of your audience will interact with your site without using a mouse for navigation. Keep their perspective in mind while deciding how the page will be laid out, how to demonstrate when elements are “in focus” and how they will be interpreted by screen readers.

References:

WebAIM keyboard techniques

W3C keyboard techniques

Video with examples of using keyboard to navigate

Forms

Summary: Accessible forms are laid out logically, are easy to perceive and understand, and require a minimum of trial and error to complete. Though accessibility concerns mainly focus on solutions for keyboard only access and screen reader usage, well-designed forms will benefit everyone.

Simplicity: Make sure that your form is laid out intuitively and that the instructions are clear. Ensure that required fields are obvious (we recommend actually spelling out the word “required” if space allows, as asterisks can be difficult to discern at times for users with poor vision). Avoid using tables for layout (forms do not qualify as tabular data) and keep in mind the order that screen readers will encounter the information. A simple, linear form will be of particular benefit to users with certain types of cognitive disabilities, who might otherwise struggle with complex instructions.

Formatting: Unsighted users rely on clear labels and well defined structure in order to understand the purpose of a form and the information being collected. Use the following markup to increase the accessibility of your form code, especially as it is perceived by screen readers:

  • Fieldset: The <fieldset> tag is used to identify related elements in a group.</fieldset>
  • Legend: The <legend> tag serves as a caption for the fieldset, and announces its purpose.</legend>
  • Label: The <label> tag serves as a descriptive label for an <input> element and enables toggle control in association with the text for that element (e.g. the user can select a radio button by clicking on the associated text).</label>

Example of formatting:

<fieldset>
<legend>Select your taco fillings:</legend>
<input id="egg" type="checkbox" name="fillings" value=" egg "> <label for=" egg "> Egg </label>
<input id="potato" type="checkbox" name=" fillings " value=" potato "> <label for=" potato "> Potato </label>
<input id="cheese" type="checkbox" name=" fillings " value=" cheese "> <label for=" cheese "> Cheese </label>
</fieldset>

Default text within text fields: Pre-filling text fields with default values, whether used as sample responses, help tips or the field labels themselves can cause usability and accessibility issues.

  • Users are likely to skip over pre-filled fields. If a text field is pre-populated it becomes more likely that the user will think that the system has already supplied the expected response.
  • Sample responses, or examples, are often “grayed out” – which can in turn result in difficulty perceiving the text, especially if it doesn’t meet the minimum color contrast requirements.
  • If the pre-populated text disappears when focus is set on the field, it can be difficult for some users to recall what information they are being asked to supply. Examples include screen reader or keyboard only users that may have tabbed through too quickly to absorb the information, or people with certain types of cognitive disabilities (such as those that struggle with short term memory).

Errors – messaging and recovery: Error messages should be easy to understand and should state the issue in terms that make sense to the user (as opposed to using technical jargon that makes sense only to a developer). The error should be associated directly with the value that needs to be corrected, and the recovery instructions should be easy to both follow and execute. Again, this is not only beneficial to those with disabilities but is also good overall user experience.

Design Approach: Creating an accessible form starts with a simple, straightforward design.

  • UX architects and designers should make sure that the form is organized intuitively. Keep tab order in mind as well as the sequence in which your form fields will be read by a screen reader. Organize sub sections into logical groups.
  • Copywriters/editors can ensure that the information being requested is clearly defined with proper labels and help text (if required). Error messages and recovery paths should be easy to follow.

References:

Web Accessibility in Mind – Forms

W3C forms

Web Semantics accessible forms

Data tables

Summary: When it comes to data tables, the best practice is to keep it simple. A flat, simple data structure will help keep the content comprehensible when read by a screen reader.

Purpose: Do not use tables for layout. Use CSS to define page structure. Screen readers will read page content in the order that it is presented (e.g. top to bottom, left to right), so if this is not the order that the user is expected to consume the information, those relying on assistive technology will have difficulty comprehending.

Table formatting: Unsighted users rely on clear labels and well defined structure in order to understand the purpose of a data table and the information provided within.

  • Captions: Use the <caption> element to summarize the contents of the table. This serves the same purpose as a label or a header without the user having to set the focus outside the table in order to understand context. The <caption> element must be the first thing after the opening <table> tag.</table></caption></caption>
  • Scope: Using the “scope” attribute within the column and row header tags (<th>) will allow a screen reader to announce the associated column/row when reading the cell data, which removes the burden of remembering the order of presentation from the user.</th>

Example of table formatting:

<table class="data">
<caption>Contact information by day of the week.</caption>
<tr>
<td> & n b s p ; </td>
<th scope="col">Monday</th>
<th scope="col">Tuesday</th>
<th scope="col">Wednesday</th>
<th scope="col">Thursday</th>
<th scope="col">Friday</th>
<th scope="col">Saturday</th>
<th scope="col">Sunday</th>
</tr>
<tr>
<th scope="row">Hours</th>
<td>9 a.m. to 6 p.m.</td>
<td>9 a.m. to 6 p.m.</td>
<td>9 a.m. to 6 p.m.</td>
<td>9 a.m. to 6 p.m.</td>
<td>9 a.m. to 7 p.m.</td>
<td>10 a.m. to 4 p.m.</td>
<td>Closed</td>
</tr>
...

A screen reader will read the above as follows: “Contact information by day of the week. Hours: Monday 9 a.m. to 6 p.m., Tuesday. 9 a.m. to 6 p.m…”

Complex tables: Tables with two or more levels of headings and/or spanned cells introduce even more complexity, and require even more definition to ensure that associations between headings and cell data are preserved. For this reason, they should be avoided unless absolutely necessary. If required, please refer to the W3C guidelines for Complex Tables.

Proportional sizing, not absolute sizing: A table with fixed dimensions can cause problems for people who larger fonts or magnified screen views. The best practice is to let the browser window determine the width of the table whenever possible, to reduce the horizontal scrolling required of those with low vision. If cell widths need to be defined, use relative values, such a percentages, rather than pixel values.

Design approach: The best way to design for accessible tables is to make sure that they are used for their primary purpose: tabular data. When a table layout is called for, keep in mind how the data will be perceived when heard and ensure that the context is always clear.

Key takeaways:

  • Keep your data tables simple and well organized.
  • Do not use a table structure for page layout.
  • Use proper html markup to support screen reader interpretation.

References:

Web Accessibility in Mind – Data tables

W3C

Video and audio

Summary: Video and audio files present significant obstacles for not only people with hearing disabilities but also for the visually impaired, people who are not native speakers of the language being used and others who may not be able or wish to access digital multimedia content.

Captioning: Captions are the text equivalent of audio content. Primarily used by people with hearing disabilities and impairments, captions are also useful for those who may not be fluent in the language used in the presentation. Captions can be open (present for all consumers) or closed (able to be turned on or off). Closed captioning is the preferred method for making audio/visual files accessible for the following reasons:

  • Synchronous: Captions are synched so that the text appears at the same time that the audio is delivered on screen. This allows the person reading the captions to follow along with the events as they transpire.
  • Equivalent: Captions are usually prepared based on what was recorded, as opposed to transcripts which are usually a record of the dialogue as written. Therefore captions are typically more representative of the actual content of the media file.

Transcripts: Transcripts are also an important component in providing accessible alternatives to the digital media content. Transcripts that provide descriptions of the visuals (what is happening on screen) and non-verbal audio cues (such as laughter or an explosion) can allow someone using a screen reader or braille translator to receive a close approximation of the experience.

Audio: If any audio automatically plays for more than 3 seconds, controls must be available to pause, stop or reduce the audio volume independently from the overall system volume.

Key takeaways:

  • Closed captioning is the standard for providing text equivalent for digital multimedia content.
  • Transcripts are also useful and should be used in addition to captions.

References:

WebAIM captions

W3C video

What about mobile?

Summary: Accessibility considerations for mobile displays are no different than from traditional desktop presentations. WCAG 2.0 guidelines should still be the guiding principles. However, there are some characteristics of interaction that are particular to the mobile experience.

Prevalence: Mobile adoption continues to grow among people with disabilities just as it has with the population at large. According to a WebAIM survey from January, 2014, 82 % of screen reader users browse the web via a mobile device (often in addition to a desktop or laptop), up 10 % from May 2012.

Native accessibility features: Manufacturers are increasingly building accessibility features directly into their products, including native screen readers, the ability to control font size and display color, the ability to add subtitles or captioning, and more. Though keep in mind that built-in features won’t correct inaccessible design.

Touch Navigation: Touch screen interfaces present some unique interaction considerations. Here are some things to consider for people with disabilities using touch controls.

  • Hit targets: People with motor control limitations will benefit from hit targets/hot spots that have enough space in between to avoid selecting an unintended value.
  • Pinch and stretch: These actions may be more difficult for people with dexterity issues.
  • Swipe navigation: Some accessibility controls (such as screen readers) employ gestures as shortcut commands. If your design relies heavily on swipe navigation you should experiment to determine if the interaction still behaves as intended with accessibility features turned on.
  • Multi-finger commands: Some screen controls require the use of two or more fingers when in accessibility mode (such as inputs from an on screen keyboard). As with swipe navigation, testing should take this behavior into account.

Tools:

  • The W3C provides a wiki on applying the UAAG success criteria to mobile devices, with specific information on how to solve for those criteria in the unique landscape of mobile.
  • WAI-ARIA defines ways to make web content more accessible, especially dynamic content and advanced user interface controls. It applies to web applications and to accessing websites with mobile devices.
  • WAI provides information on common barriers to mobile devicesand people with disabilities.
  • General Mobile Web Best Practices exist that help bring mobile experiences closer to accessibility.
  • IndieUI provides a way for user actions to be communicated to web applications, including mobile devices.

References:

W3C Mobile