Autism Gap Analysis (W3C Task Force)

Neil Milliken and I have written an autism gap analysis as part of the effort to create gap analyses by the W3C‘s Cognitive and Learning Disabilities Accessibility Task Force. Our intent is to identify the gap between where the state of accessibility for people with autism is now when using the web, and where we want it to be. The following is information about the autism gap analysis.

We included some personas with use cases that address key challenges. The personas and use cases are based upon aggregated results of interviews of people with autism-spectrum disorder (ASD), and upon anecdotal observations of their use of the web.

To our knowledge, there is no significant, empirical (user-based) testing on the use of the web by people with autism or other cognitive disabilities. In part because of that, we quoted results of directly-related research performed by WebAIM (N=8) in the section “Characteristics of content optimized for this group.”

We also quoted, from authoritative sources, much of the background information about autism. We did that, in large part, to help avoid adding to ASD-related controversies. The prime example is the reported increasing prevalence of ASD, and arguments that the increase is not actual, but due to the nature of the diagnoses.

Notes:

  • I will soon conduct a literature review for user-testing-based research related to web accessibility and people with cognitive disabilities. If you know of any, please post a comment with a reference to it.
  • Neil Milliken was assisted by Jessie Grainger, an intern who helped write most of the use-case scenarios.
  • No endorsement of any of the information contained in the autism gap analysis is intended or implied.

Definitions of “Cognitive Disability”

Goal

Find a recent, functional definition of “cognitive disability” written by an appropriate U.S. federal government agency, and adopted by government agencies and education institutions throughout the country.

Goal = Wishful Thinking

It appears no authoritative source has published a widely-used and accepted functional definition, nor a clinical one. Because I intend the Clear Helper Web site to be accessible to people with cognitive disabilities, it would have been helpful to find an authoritative, functional definition.

Definitions from Federal-Government Sources

The closest I came to my goal, at least for an authoritative source, is a clinical definition on the Web site of the U.S. Department of Health and Human Services, Administration for Children & Families.  The definition is part of an explanation of why the term “cognitive disabilities” was not used instead of “intellectual disabilities” on the Web site of the President’s Committee for People with Intellectual Disabilities.

“Cognitive disabilities” is often used by physicians, neurologists, psychologists and other professionals to include adults sustaining head injuries with brain trauma after the age 18, adults with infectious diseases or affected by toxic substances leading to organic brain syndromes and cognitive deficits after the age 18, and with older adults with Alzheimer diseases or other forms of dementias as well as other populations that do not meet the strict definition of mental retardation.

Retrieved from: http://faq.acf.hhs.gov/cgi-bin/acfrightnow.cfg/php/enduser/std_adp.php?p_faqid=934&p_created=1068052784 (Published December 4, 2009)

The next-closest to my goal, in terms of a functional definition from a federal-government agency, is on the Web site of the U.S. Environmental Protection Agency.

Cognitive disabilities cover a wide range of needs and abilities that vary for each specific person. Conditions range from person having a serious mental impairment caused by Alzheimer’s disease, Bipolar Disorder or medications to non-organic disorders such as dyslexia, attention deficit disorder, poor literacy or problems understanding information. At a basic level, these disabilities affect the mental process of knowledge, including aspects such as awareness, perception, reasoning, and judgment. Simply put, the Center on Human Policy at Syracuse University defines cognitive disability as: “a disability that impacts an individual’s ability to access, process, or remember information.”

Retrieved from: http://www.epa.gov/accessibility/technology/disabilities.htm (Published December 29, 2008).  Syracuse University definition retrieved from: http://thechp.syr.edu/definitions_support_terms.html

I also found an older, brief, functional definition on a Web site of the U.S. Department of Transportation.

Cognitive disability – Limitation of the ability to perceive, recognize, understand, interpret, and/or respond to information.

Retrieved from: http://www.fhwa.dot.gov/environment/sidewalks/appb.htm (Published January 20, 2004)

I could not find any evidence that the above definitions have been adopted by anyone, let alone widely-adopted.

Definitions From Other Sources

I found the following definition on the Web site of the Coleman Institute for Cognitive Disabilities, at The University of Colorado.

When we refer to “cognitive disabilities” on this website we are primarily referring to mental retardation and developmental disabilities, acquired brain injury, Alzheimer’s disease, and severe and persistent mental illness. …

Cognitive disability stems from a substantial limitation in one’s capacity to think, including conceptualizing, planning and sequencing thoughts and actions, remembering, and interpreting the meaning of social and emotional cues, and of numbers and symbols.

Retrieved from: https://www.cu.edu/ColemanInstitute/background.html (Published December 14, 2006)

The most useful information I found is on the WebAIM Web site.  It provides general clinical- and functional definitions in the context of accessibility for people with cognitive disabilities.  It has a list of categories of functional deficits, with a relevant synopsis of each.

Cognitive Disabilities: Introduction (Published May 3, 2009)

The WebAIM article’s discussion of clinical- versus functional- definitions closely matches that of another useful article, posted on the Disabled World Web Site.

Cognitive Disabilities (Published February 10, 2009)

Search Term

In all my searches, I used variations of the search term: “cognitive disability” definition

Sources Searched

Note: If you know of a definition or a source of a definition for “cognitive disability”, please contact me or post a comment.  Thank you.

Browser-Based Text/Font Size Switching

On the Clear Helper Web site, I have implemented a text-resizing approach suggested by Jared Smith, of WebAIM.  It relies upon visitors to follow instructions about using their Web browsers to change the Web site’s text size.

Background

In a previous post entitled “Web Site Font Sizes & Switching for People with Cognitive Disabilities“, I proposed adding to the Clear Helper Web site a font size switcher that looks like this image.

line of 5 letter 'A's in ascending order of size

In a response to that post, Jared Smith discussed several reasons why such a widget should not be used.  He said Web site visitors should use their Web browsers instead.  He suggested the approach of SSA.gov.  At the top of its pages, on the left, there is a link entitled “Need Larger Text?”  Clicking it produces a page with text-based instructions on using the keyboard to enlarge text.  On that page is also a link to a W3C page with related text- and picture based instructions for four Web browsers.

My Implementation of an Approach Similar to SSA.gov’s

At the top of the Clear Helper Web site pages, on the left, there is now a link entitled “Need big text?”.  Clicking it produces a page with text- and image- based instructions on how to use the keyboard to enlarge text.  From that page, another page can be reached that has screen shots to explain how to use Internet Explorer menus to enlarge text or how to use Firefox menus to enlarge text.

My next post will describe problems with this approach, and what I have done to solve them, or at least to ameliorate them.

No Accessibility Benefit To Google Analytics Asynchronous Tracking

For years, I have used the Google Analytics JavaScript snippet to track Web page usage.  The problem for Web sites is they do not track visits by assistive technology (AT) users who, for accessibility reasons, have JavaScript turned off in their Web browsers.  The problem for AT users, particularly screen-reader users, who keep JavaScript enabled, is they are warned a JavaScript element is present, but it serves no practical value for them.

On December 1 of this year, Google introduced asynchronous tracking for its Analytics program.   It’s purpose is to speed the loading of pages.  What interested me was that it required the JavaScript snippet to be moved from the body of the page to its header.  I speculated that if it were located in the header, screen-reader users would not receive a warning about it.  I implemented the move, and found I was wrong.

In this WAVE accessibility evaluation report of the Clear Helper home page, the little yellow icon at the top, center, clearly shows a JavaScript warning.  Ultimately, this is not a problem for experienced AT/screen-reader users because they encounter such JavaScript all the time and know to ignore it.  For people with cognitive disabilities and others who do not use AT, it poses no problem at all.

Screen Readers, Web Site TTS Plug-ins, Etc.

For people who are blind or who have difficulty reading, there are a variety of solutions for converting text to speech (TTS).  This post is a follow-up to my brief look at Accessible Rich Media Players and TTS for Web Sites.

Screen readers are software programs that read out loud in a voice the text that appears on the computer screen.

Screen Readers For All Purposes

JAWS (Job Access With Speech) is the most popular.  I have been using its professional version, since its inception many years ago, to test Web site accessibility. Windows Eyes, Zoom Text and System Access are its closest, commercial competitors.

Free alternatives include Thunder and NVDA, which is growing in popularity.  Others are built into Windows (see Microsoft assistive technologies) and OS X (see VoiceOver, the well regarded screen reader that is part of Apple assistive technologies).

Screen Readers For The Web

WebAnywhere and FireVox, which is a Firefox extension, work only for the Web.  Both are free.

  • WebAIM Screen Reader Simulation provides a way to experience what it is like to use a screen reader.
  • Fangs, a Firefox extension, is a screen reader emulator that recreates a Web page similar to how it would be read by screen reader.

Text-To-Speech Plug-ins for Web Sites

Many Web sites offer their visitors TTS capability.  Visitors are required to download and install a software plug-in.  Once that is done, visitors are able to listen to the text on any Web site that uses the same TTS technology.  One popular example is BrowseAloud.  Its costs, which are for the Web site owner, are not listed on its Web site.  It does have a free trial.  Another example is Speaks For Itself. It appears to be free, but it seems it has not been updated recently.

Miscellaneous, But Related

ClaroRead, PenFriend and EasyTutor have screen-reader functionality, but are intended more for helping people read and write.

There are also screen magnification programs such as Magic (commercial) and Virtual Magnifying Glass (free).

WebAIM WAVE Evaluation: Success For Now

I ran the WebAIM WAVE Web accessibility evaluation tool against the “Clear Helper” home page. It detected no accessibility errors.

View the WAVE report about the “Clear Helper” home page.

WAVE has many useful features.  Unlike any other such tool I have used, it provides a visual layout of a Web page with embedded icon indicators.  Red ones are for accessibility errors; yellow ones are alerts for possible issues, green ones are for accessibility features, and light blue ones are for elements that may aid accessibility.

Ordinarily, when using WAVE, I prefer its Toolbar version.  The following descriptions are for the Web-based version of WAVE, which people use for a quick check to determine if a site has made an attempt to be accessible.

Near the top, right of the WAVE report is a button to disable/enable styles.  This is useful to show how readable the page is should a user decide to disable page styling.

Across the top of the report, there are tabs for ancillary reports showing the Web page’s:

  • Structure/Order, which indicates the order in which the content will be read as a person tabs through it.
  • Text-only, which shows the page without images or styling.
  • Outline, which displays content headings and their order.

Use of WAVE is a good start for determining a Web site’s accessibility.  Other such tools, commercial and free, and many of which I have used on other sites, attempt to check against sets of standards such as 508, WCAG 1, and WCAG 2.  Ultimately though, true accessibility can be determined only with testing by people with disabilities.

Note: When the “Clear Helper” Web site is available for public use, I expect its design will be much different.  Yet, because this is my first foray into using HTML 5 and CSS 3, I wanted an indication I am using those technologies accessibly.  I will continue to perform accessibility checks as I experiment.

Experimenting with Landmark Roles on the Clear Helper Home Page

Today, I experimented with placing WAI-ARAI landmark roles into the “Clear Helper” home page.   For users of screen readers, landmarks provide a method to identify standard content sections of Web pages in a consistent way.

I followed the instructions on “Using WAI ARIA Landmark Roles” by Steve Faulkner of  The Paciello Group Blog.  I inserted the following landmark roles: banner, navigation (not currently in use), main, complementary and contentinfo.  Per Mr. Faulkner’s suggestion, I viewed the results using The Juicy Studio Accessibility Toolbar document landmarks feature.  All went well.  The Juicy Studio tool redisplayed the page, showing borders around each delineated landmark section.

Among other uses, landmarks are intended to replace “skip-to-content” links now found on many accessible Web sites.  Even so, I intend to use such links on the “Clear Helper” Web site, essentially for two reasons.  One is that people who access Web sites via a keyboard, and who are not screen reader users, find such links to be useful.  The other is that though JAWS (as of version 10), the most popular screen reader, supports landmarks, their adoption and use by the community has been slow.  Results from a recent survey of screen reader users indicated that “42% of respondents did not know that ARIA landmark functionality even exists”.

Smith, J. (2009-10-29). Screen Reader User Survey Results. WebAIM Blog. Retrieved from http://webaim.org/blog/screen-reader-user-survey-results/

Do landmarks assist people with cognitive disabilities?  I am sure they could for those who also have a visual disability.  An important point to keep in mind about the design of the future “Clear Helper” Web site is that, yes, I will be using best practices of accessibility for people with cognitive disabilities; but I also will be adhering to the latest general accessibility standards (WCAG 2.0).

A Beginning for the Clear Helper Web Site

The “Clear Helper” Web site has its first page!  The home page has a decent look for a first attempt, and it experiments with a few accessibility elements.  However, its design is definitely not the one I am imagining for the site when it is available for use by people with cognitive disabilities.

HTML 5 & CSS 3

It took me eight hours to create the home page.  I spent much of the time learning enough HTML 5 and CSS 3.  I’m using those technologies primarily because they should work best with WAI ARIA, which defines a way for assistive-technology users to identify and to navigate visually-rich user interfaces.  Will I be using such interfaces or applets on the site?  I don’t know, but I want to be prepared for that possibility.

Voice Narration

One of the accessibility attributes the home page uses is a way for visitors to have its text read to them without needing to use a screen reader.  I created this feature with two tools.

I used Cognable’s speech demo to create a MP3 narration of the home page’s text.  I did this by:

  1. entering text for the MP3 title;
  2. copying and pasting the home page text;
  3. selecting the “Chilled US/Canadian Male” voice font;
  4. proving to the Captcha tool that I am human; and
  5. pressing the “Create MP3” button.

I then downloaded the created MP3 file for use on the home page.  Easy!

I embedded NCAM’s accessible MP3 player into the top, right of the home page.  I followed the simple instructions provided for the ccMP3Player.

The voice narration sounds okay, but it would be significantly improved by the use of a commercial voice font, I bet.  I did not set up closed captioning for the MP3 file because the entire text of it is right on the home page.

Immediate Next Steps

I will test the page using two tools:

  • WebAIM’s WAVE.  There are other Web accessibility evaluation tools, and I will use them.  Yet I am especially interested in WAVE because it will soon incorporate tests specifically for cognitive-disability accessibility attributes.  (More on this later.)
  • Juicy Studio’s Readability Test.  I plan to use this tool to analyze the home page text, then revise it until it reaches a reading level  likely to be understood by most people.  This experimentation, hopefully, will help train me to write explanatory text at an appropriate reading level.

I will be doing a lot more testing, experimentation and design revision.  All of it will be the subjects of future blog posts.

Proposed Back & Next Navigation Icons For Future Clear Helper Web Site

I plan to use a consistent set of navigation icons for the future Clear Helper Web site.  My first attempt is represented by the “BACK” and the “NEXT” icons below.  Others in the set will follow.

The development of them is not derived from research, which is beyond the scope of the project at this point.  However, they were created following WebAIM’s “Creating Accessible Images” guidelines.  In particular, they: are not animated; don’t use color alone to convey meaning; look okay even when enlarged to 500%; and use good color contrast between the text and the background.

Of these guidelines, the last can be objectively measured with the following tools.  Each is based upon the latest Web Content Accessibility Guidelines (WCAG 2.0).

Accessibility Color Wheel created by Giacomo Mazzocato.  This tool is used to choose a color pair, especially of foreground- and background colors, that is accessible to people with any of three color-blindness conditions. This tool rated the color contrast of the icons below as “13:1 ok”.

Luminosity Colour Contrast Ratio Analyser from Juicy Studio.  This tool also rates color contrast.  It reported the ratio as “12.96:1 … very good … ” and passing at WCAG 2.0 Level AAA, which is the highest standard.

I would appreciate any constructive feedback about these icons.  They are being shown at the size I plan to use on the Web site.

Back

Next

WebAIM: Insights into Cognitive Web Accessibility

My idea for the future Clear Helper Web site, and the reason I named it “Clear Helper”, is that it will offer tutorials intended for people with cognitive disabilities.  My current thinking is that each tutorial will be offered in three modes: text-only, text with pictures, and video.  Visitors to the site, presumably, would choose the mode easiest for them to follow.

So it was with interest that I reviewed the notes from a brief, related study conducted by WebAIM, and reported by Jared Smith, Associate Director of WebAIM.  The notes were from a presentation entitled “Insights into Cognitive Web Accessibility.”  It was of a user test that attempted to measure the efficiency, the effectiveness, and the satisfaction of participants (N = 8, grade 6 – 12 students with cognitive- or learning disabilities).

Among the findings, detailed in the presentation notes, were that participants did better with: larger text; images paired with text; short line lengths; and video-based instruction.  Insights included recommendations to “make your page LOOK easy” (“simple and intuitive”); “provide error recovery mechanisms”; and “keep visual aids clean, simple, and complementary to the content”.

I will keep these findings and recommendations in mind when designing the tutorials on the future Clear Helper Web site.