Michael Gaigg: Über UI/UX Design


Highlights of Week 48/2010

Posted by Michael Gaigg


Question: How can Internet Mapping Applications be made accessible?

Posted by Michael Gaigg

Following I will identify areas that make web-based maps inaccessible as per WCAG 1.0 (please see section: 'Questions and Possible Research Areas').

Shout for Help

Question: How can Internet Mapping Applications be made accessible for users with disabilities?

If you are currently working on resolving any (or all) of these issues, know of somebody that is working on them or even know existing solutions, I would greatly appreciate if you pointed them out to me.

It is absolutely impossible to continue with our current approach to seek exceptions as a 'work-around'!


It is important to note that I'm not talking about simple Google maps like driving directions or locate services that could be described through alternative, textual output.
Many times a map is the means to select, query, mix and eventually analyze data across multiple layers from multiple services. The input requires good vision and motor skills (mouse) and same applies to the output that is highly visual as well.
A simple example that illustrates this fact pretty well is shown in Figure 1, Drive Times from a specific location based on traffic grid.

ESRI Map, Drive Times

Figure 1: ESRI Map: Drive Times; produced using ArcGIS JavaScript API, http://mapapps.esri.com/serverdemos/siteselection/index.html

The Law

Section 508 as explained by Authority 29 U.S.C. 794d: “Section 508 requires that when Federal agencies develop, procure, maintain, or use electronic and information technology, Federal employees with disabilities have access to and use of information and data that is comparable to the access and use by Federal employees who are not individuals with disabilities, unless an undue burden would be imposed on the agency. Section 508 also requires that individuals with disabilities, who are members of the public seeking information or services from a Federal agency, have access to and use of information and data that is comparable to that provided to the public who are not individuals with disabilities, unless an undue burden would be imposed on the agency.”
This law is extended and applicable to companies that develop applications for the agency, i.e. ESRI has to adhere to the Section 508 Standards.
The Section 508 Checkpoints were translated into Web Content Accessibility Guidelines which cover most of Section 508 and describe its implementation in terms of HTML & CSS.

Current ‘Solution’

So far, exceptions to this law have been granted for the specific case of online maps. It is believed to impose an ‘undue burden’ to the agency/contractor to make maps accessible. In many cases a 1-800 number was provided that would help the user to get the same information.

Questions and Possible Research Areas

Currently the following WCAG checkpoints are Level 1 (A) show-stoppers and need to be solved/researched/implemented:

Checkpoint 1: Provide equivalent alternatives to auditory and visual content

How to read a map when blind? E.g. redundant text for active regions/content.

Checkpoint 2: Don’t rely on color alone

Map application could provide different color schemes/black&white/shades of gray?!

Checkpoint 6: Ensure that pages featuring new technologies transform gracefully

How to provide a map (or alternative) that can be used when scripts are turned off?

Checkpoint 8: Ensure direct accessibility of embedded user interfaces

Do not write event-handlers that rely on mouse-coordinates (device-independence; see also Checkpoint 9)

Checkpoint 9: Design for device-independence

How to navigate a map without a mouse?

Checkpoint 12: Provide context and orientation information

How to describe the content of a map (especially after a change, e.g. query)?

You know of a solution?

Please get in touch with me if you know of solutions to these problems!

I hope that solutions for these problems can be found and maps become available to everyone. As always, not only users with disabilities will benefit from these efforts but also the applications themselves, e.g. better SEO (search engine optimization), alternative support for mobile user agents, assistance for elderly people, etc.


Best Practices for accessible Tables

Posted by Michael Gaigg

The purpose of a table is to layout data. Unlike regular text, tables are generally difficult to comprehend. It takes time and effort to understand the structure, capture the data and interpret its meaning. This is even more difficult when the table is viewed and read out by a screenreader. Additional attributes are needed to relate headers with column and rows.

Tables might be used to layout content. The current recommendation for content tables is to explicitely state this purpose upfront so that users with screenreaders can avoid investigating the table's structure. Convey this meaning using the summary attribute:

<table border="0" summary="Layout table with two columns: menu and content">

Basic Rules


  • Use proper HTML
  • Use tables for displaying tabular data
  • Use block elements (e.g. DIV) and CSS for layout purposes
  • Use proportional sizing rather than absolute sizing

Data Tables:

  • Describe tables with a name or title (caption tag)
  • Provide a summary (summary attribute)
  • Designate Row and Column Headers (TH tag)
  • Associate the data cells with the appropriate headers (scope & id attributes)
  • Avoid spanned rows or columns (workaround: normalize table)
  • Avoid tables with more than two levels of row and/or column headers

Layout Tables:

  • Linearize content (literal order in the code equals the linearized reading order)
  • Use the simplest table configuration possible

Best Practices

Level 1

Level 1 Checkpoints - Section 508 Compliancy Standards
Description W3C 508 Example
For data tables, identify row and column headers 5.1 (g) <TR>
<TH abbr="Type">Type of Coffee</TH>
For data tables that have two or more logical levels of row or column headers, use markup to associate data cells and header cells 5.2 (h) <TABLE border="1">
  <CAPTION>Travel Expense Report</CAPTION>
    <TH id="header2" axis="expenses">Meals
    <TH id="header3" axis="expenses">Hotels
    <TH id="header4" axis="expenses">Transport
    <TH id="header6" axis="location">San Jose
    <TH> <TH> <TH> <TD>
    <TD id="header7" axis="date">25-Aug-97
    <TD headers="header6 header7 header2">37.74
    <TD headers="header6 header7 header3">112.00
    <TD headers="header6 header7 header4">45.00
    <TD id="header8" axis="date">26-Aug-97
    <TD headers="header6 header8 header2">27.28
    <TD headers="header6 header8 header3">112.00
    <TD headers="header6 header8 header4">45.00

Level 2

No Level 2 requirements.

Level 3

Level 3 Checkpoints - Section 508 Compliancy Standards
Description W3C 508 Example
Provide summaries for tables 5.5 n/a <TABLE summary="This table charts the number of cups of coffee ...">
Provide abbreviations for header labels 5.6 n/a <TABLE ...>
<TH scope="col">Name</TH>
<TH scope="col">Cups</TH>
<TH scope="col" abbr="Type">Type of Coffee</TH>
<TH scope="col">Sugar?</TH>
Provide a linear text alternative (on the current page or some other) for all tables that lay out text in parallel, word-wrapped columns 10.3 n/a n/a



Best Practices for accessible Links

Posted by Michael Gaigg

It is essential that users can find, identify, and comprehend hypertext links quickly. Even though there are no Level 1 (A) checkpoints associated with links it is pretty easy to fulfill Level 2 and even Level 3. It's definitely worthwhile the little effort with the added benefit that e.g. most browsers render the title attribute as a tooltip.

Basic Rules

See also my Design Guidelines for Links.

  • Contrast link text color and regular text color
  • Underline link text
  • Ensure link text is descriptive of its destination
  • Make visited links change color
  • Limit link text to a maximum of four words
  • Place important words at the front of link text
  • Minimize amount of links to seven (excluding the menu) unless they are presented in a clear structure
  • Use meaningful pathnames when creating directory structure

Best Practices

Level 1

No Level 1 requirements.

Level 2

Level 2 Checkpoints - Section 508 Compliancy Standards
Checkpoint Description W3C 508 Example
Links Clearly identify the target of each link 13.1 n/a <A href="my-doc.html">My document is available in HTML</A>,<A href="my-doc.pdf" title="My document in PDF">PDF</A>,

<A href="my-doc.txt" title="My document in text">plain text</A>

Level 3

Level 3 Checkpoints - Section 508 Compliancy Standards
Checkpoint Description W3C 508 Example
Links Create a logical tab order 9.4 n/a <A tabindex="2" href="link2.txt"">Link 2</A><A tabindex="1" href="link1.txt">Link 1</A>

<A tabindex="3" href="link3.txt">Link 3</A>

Links Provide keyboard shortcuts to important links 9.5 n/a <A accesskey="2" href="link2.txt"">Link 2</A><A accesskey="1" href="link1.txt">Link 1</A>

<A accesskey="3" href="link3.txt">Link 3</A>

Links Include non-link, printable characters (surrounded by spaces) between adjacent links 10.5 n/a [<A href="a.htm">Link A</A>] [<A href="b.html">Link B</A>] or<A href="a.htm">Link A</A> | <A href="b.html">Link B</A>


Find out more about <a title="Michael Gaigg IT Solutions Webpage" href="http://www.michaelgaigg.com/">IT Solutions</a>



Best Practices for accessible Content

Posted by Michael Gaigg

People rarely read Web pages, they scan the page! As a result, Web pages have to follow Design Guidelines for Content that enable them to quickly identify headings, titles, links and other important elements to orient themselves. What else has to be done to be Section 508 compliant?

Basic Rules

  • Don’t rely on color alone
  • Identify the language used throughout the document and identify changes
  • Use correct markup to emphasize important content
  • Be clear and precise in the choice of wording and language

Best Practices

Level 1

Level 1 Checkpoints - Section 508 Compliancy Standards
Checkpoint Description W3C 508 Example
Color Ensure that all information conveyed with color is also available without color 2.1 (c) Ensure that information is available through other style effects (e.g., a font effect), through context (e.g,. comprehensive text links) or through mark-up (e.g., the title attribute).
Language Clearly identify changes in the natural language of a document's text and any text equivalents 4.1 n/a And with a certain <SPAN lang="fr">je ne sais quoi</SPAN>,
she entered both the room, and his life, forever. <Q>My name
is Natasha,</Q> she said. <Q lang="it">Piacere,</Q>
he replied in impeccable Italian, locking the door.
Language Use the clearest and simplest language appropriate for a site's content 14.1 n/a n/a

Level 2

Level 2 Checkpoints - Section 508 Compliancy Standards
Checkpoint Description W3C 508 Example
Blinking Avoid causing content to blink 7.2 n/a n/a
Movement Avoid movement in pages 7.3 n/a i.e., hide/show content or change presentation (movement and colors).

Level 3

Level 3 Checkpoints - Section 508 Compliancy Standards
Checkpoint Description W3C 508 Example
Text Ensure that foreground and background color combinations provide sufficient contrast when viewed by someone having color deficits or when viewed on a black and white screen 2.2 (c) For more information check the online paper about "Effective Color Contrast" at lighthouse.org (http://www.lighthouse.org/accessibility/effective-color-contrast/).
Abbreviations Specify the expansion of each abbreviation in a document where it first occurs 4.2 n/a <ABBR title="social security number">SS#</ABBR>

or ASCII art:<ABBR title="smiley in ASCII art">:-)</ABBR>
Acronyms Specify the expansion of each acronym in a document where it first occurs 4.2 n/a Welcome to the <ACRONYM title="World Wide Web">WWW</ACRONYM>
Language Identify the primary natural language of a document 4.3 n/a <HTML lang="en">


<HTML xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">

<ABBR title="social security number">SS#</ABBR>

<ACRONYM title="Geographical Information System">GIS</ACRONYM>