Tag: Web Accessibility

Teaching Web Searching To People With Cognitive Disabilities

~ John Rochford

I have often seen people with intellectual disabilities struggle with how to perform Web searches during my interviews with them. The same problem was described by Henny Swan in her article, “‘Where’s my Googlebox?!’ – adventures in search for silver surfers“. It and its subsequent discussion inspired me to write this post.

I think there are two principles that could be used to teach Web searching to people with cognitive disabilities. For the purposes of this post, I am defining “searching” solely as the mechanics of submitting text via a search box.

That search boxes have the same- or similar characteristics, whether they are part of a Web browser, a Web site, or a search engine, means that learning to use them may not be difficult.  People could be taught to recognize search boxes and to submit simple searches with them.

First Principle

Search boxes can easily be recognized / located.

  • Appearance
    • All search boxes are rectangular and have white backgrounds. Many contain the word “Google” or have it and/or the Google logo nearby.
      • There are exceptions, but usually due to poor design.
  • Location
    • Search boxes within the latest versions of popular Web browsers (Internet Explorer 8.07, Firefox 3.6.3, Opera 10.53 and Safari 5.0) are located in the top, right corner of the browser window.
      • An exception is Chrome 5.0. In my opinion, this is one of Chrome’s accessibility problems.
    • Fortunately for people who use browsers such as Chrome, search boxes can still be found at the top, right corner of the screen because that is the common placement convention of many Web sites.
      • Search engines are the significant exception.

Second Principle

Search boxes can be used in the same, 3-step way.

  1. Prepare the search box for text entry by tabbing to it with the keyboard.
  2. Enter text.
  3. Invoke the search with the Enter / Return key.

Unneeded Training

  • To use a search box, people need not learn to discriminate between a browser, a site, and a search engine. Recognizing a search box is enough.
  • A mouse could be used to click inside a search box to prepare it for text entry, but I think the related instruction would be an unnecessary complication. Likewise, people could be trained to invoke searches with a mouse, but such instruction would be confusing for users when encountering a search box without an activation button.

Advantages

Teaching the mechanics of search-box use may have advantages.

  • The resultant skills acquisition could generalize to encompass the search boxes of search engines.
  • Using a browser’s search box would provide consistent interface interaction across Web sites.

Assumptions

  • Such training would likely require revisiting over a multi-month period of consistent Web activity.
  • People being trained would need, at the least, basic literacy- and keyboard skills.

Notes

  • Constructing effective search terms and interpreting search results are beyond the scope of the proposed principles.
  • I am interested in how to teach people with cognitive disabilities to use the Web because that is my intention for the future Clear Helper site.

The ArcLink: Features of a Cognitively Accessible Web Site

~ John Rochford ~ 6 Comments

Today, I attended the presentation, “Making Your Information Available to People with ID by Building Accessible Websites” by Lynne Tamor, Ph.D., of The ArcLink Incorporated.

Dr. Tamor’s work mirrors that of my own and of others who specialize in cognitive Web accessibility. The principles she described and/or demonstrated included:

  • Create uncluttered pages with consistent layout
  • Use Plain language/People First language/Low readability score
  • Make the site accessible to screen readers, operating system narrators, and text-to-speech software
  • Use graphics, audio, and video to support text
  • Avoid jargon, including Internet-related jargon
  • Use large print and simple fonts
  • Try to limit scrolling
  • Make sure pages will print as seen on the screen
  • Use a consistent and straightforward navigation system
  • Include a “how to use this site” section
  • Make the homepage informative for people who come to the site via search engines

Taylor, Lynne. “Features of a Cognitively Accessible Website” handout distributed at “Making Your Information Available to People with ID by Building Accessible Websites.” Annual Conference of The American Association on Intellectual and Developmental Disabilities. Providence, Rhode Island. 9 June 2010.

Notes: The presentation was also credited to Nancy Ward, Oklahoma Disability Law Center. No endorsement of The ArcLink Incorporated is intended or implied.

Cognitive Web Accessibility Assessments: Detailed Results By Site

~ John Rochford

I published an index of detailed results, by site, of my cognitive Web accessibility assessments.

For each Web site, the detailed-results page displays:

  • the applicable guidelines the site met or did not meet;
  • the numbers of points scored by sections (Content, Design and Design-Related); and
  • the site’s assessment score and conclusion (accessible or inaccessible).

Notes: This post is part of a continuing series on Cognitive Web Accessibility Assessments. I have also published an index of aggregate results.

Good, Basic Internet Skills Foiled By Confusing Content

~ John Rochford

Anne uses her computer almost solely for e-mail and finding information. This is typical of many people, even those without intellectual disabilities. Perhaps unlike them, Anne has significant difficulty with content she receives and finds.

E-mail

Anne understands e-mail messages from people who know her. She has been using basic functions of e-mail for years, but still gets confused with them because she is distracted by spam. It is especially difficult for her to differentiate it from legitimate messages and to determine its intent.

Finding Info

Anne has been using Google to learn about medications, and to look up definitions of words within their descriptions.  This indicates finding such information is simple enough for her, but the content she finds is not.

Content

It is bad enough that Web content is not written in plain language. Worse is e-mail content designed to deceive. Content comprehension problems put Anne at a significant disadvantage despite her facility with e-mail and Google.

I do not know how anti-spam efforts could be particularly helpful for people with cognitive disabilities. I do know that designing simple Web content is a much easier proposition.

Notes

Cognitive Web Accessibility Assessments: Significant Scoring Revision

~ John Rochford

I have fundamentally revised the scoring of my cognitive Web accessibility assessments. The impetus was my troubling assessment of the Web site for Bipolar Scotland. It achieved a good score, but I judged it to be inaccessible to people with cognitive disabilities.

Scoring System

My 10-point assessments are based upon WebAIM’s Cognitive Web Accessibility Checklist. Three of its sections relate to site content and four to site design. Each section is an assessment criterion. I record one point for each of those that are met, plus a possible point for each of three simple design-related criteria I added to the assessments.

Scoring System Problems

Until now, I had not considered a couple aspects of my scoring system.

  • The design criteria outnumber the content criteria. This meant I was judging sites to be accessible that, like Bipolar Scotland’s, were strong in design but had content accessibility problems. This was not good practice.
  • Because meeting each criterion means one point, my simple design-related criteria had the same significance as the complex, detailed design criteria of WebAIM’s checklist. They should not have.

Scoring System Revision

Site content should have significantly-greater impact on my assessments; the simple design-related criteria should have less. To accomplish this, I now do not consider any site accessible unless, at a minimum, it meets all three content criteria and all four design criteria of WebAIM’s checklist. Any points recorded for the simple design-related criteria improve the total assessment score.

New Site Scoring System, By Points:

  • minimum for “accessible” = 3 content + 4 design
  • total score = those 7 + up to 3 simple design-related

Notes:

Web Site Designed For People With Cognitive Disabilities But Inaccessible To Them

~ John Rochford

I assessed the Web site of Bipolar Scotland. It was designed for people with cognitive disabilities. Summary assessment results show the site met all seven design-related criteria, but not the three content criteria. In my judgment, a site with significant content-accessibility problems can not be considered accessible to people with cognitive disabilities.

The bullets below list the sections of WebAIM’s Cognitive Web Accessibility Checklist. Each section is an assessment criterion. Each is considered met if at least 75% of its applicable guidelines are implemented on the Web site.

Site Design Strengths

  • Consistency (100%)
  • Transformability (75%)
  • Orientation and Error Prevention/Recovery (75%)
  • Assistive Technology Compatibility (86%)

The site also attempts to meet W3C accessibility guidelines, has an accessibility statement, and explains at least one accessibility feature (the font size changer).

Site Content Problems

  • Multi-modality (0%)
    • Text is not offered in video- or audio alternatives.
    • With few exceptions, contextually-relevant images are not used, and icons/graphics are not paired with text.
  • Focus and Structure (67%)
    • Design does not focus attention on page-body content.
    • On every page there is a large, distracting element (a constantly-changing image inside an Amazon widget).
  • Readability and Language (50%)

Statement Site Was Designed For People With Cognitive Disabilities

Bipolar Scotland’s accessibility statement, in part, says:

In web accessibility terms, bipolar disorder falls under the category of cognitive/intellectual disabilities, one of the five needs that web accessibility aims to address. We tend to think of web accessibility as ways to help blind or deaf users view the web, but people with cognitive disabilities have particular needs involving memory, comprehension, attention span, and logic skills. Creating a site for people with bipolar disorder, who may or may not be experiencing those issues on any given day, poses a particular challenge: we are designing to accomodate the restrictions within the brain, not the body.

Retrieved from: http://www.bipolarscotland.org.uk/accessibility

Conclusion

I agree with that statement. The one exception I take is with its last line. I think the reverse is true: the site’s design is good for physical disabilities (“the body”) but its content is not for cognitive disabilities (“restrictions within the brain”).

Notes

Cognitive Web Accessibility Assessments: Musings About Validity

~ John Rochford

Results of my cognitive Web accessibility assessments, for the 12 sites I have evaluated to date, show an average score of 5 out of 10 points.  That datum is the launch point for this post, in which I consider the assessments’ consistency, accuracy, and related implications.

I hope the average score improves as I increase the sample size of assessed sites, but it will be unlikely if I encounter more like that of The International Dyslexia Association.  It is the first Web site for which no points were scored.

I think the zero-point score is an accurate portrayal of the site’s accessibility.  Comparing it to the two sites that scored all points and to the other assessed sites indicates to me my assessment system is internally consistent.  It is obvious, for example, that the top scorers are much more accessible to people with cognitive disabilities than those sites with five points or fewer.

I suspect the top scores were achieved because the two sites were designed for people with intellectual disabilities and because my assessments are for the broader, perhaps-more-capable group of people with cognitive disabilities.

Given my experiences observing people with intellectual disabilities navigate Web sites, I am concerned even the efforts of the top-scoring sites may not mean they are truly relatively-accessible.  I don’t know how my assessments could better judge such sites, but that is my main interest.

Extensive testing by people with intellectual disabilities may be a good indicator of accessibility.  However, there is such a range of abilities within the population that I am unsure any Web site could be accessible to a significant portion of them. This may mean in practice I must produce criteria for minimum abilities needed and try to make the future Clear Helper site accessible to people who meet them.

Note: This post is part of a continuing series on Cognitive Web Accessibility Assessments.

Free Readability Tool for iPhone & Desktop Web Browsers

~ John Rochford

TidyRead, similar to the other such tools I have described, is a free bookmarklet that strips the clutter from Web pages and otherwise makes them easier to read.  Unlike them, it works on the iPhone and the iPod Touch.  It also works with Firefox, Chrome, Safari, Opera and Internet Explorer.

Configuration Options

While TidyRead does not have as many configuration options as those offered by Readability and Readable, it does offer them on demand.  With the latter two tools, users configure how they want the main content of Web pages to appear, and then they add the bookmarklet to their Web browsers.  TidyRead has no pre-configuration.  After its bookmarklet is installed, a click to it presents the toolbar, shown below, at the top of each page it displays.  It adjusts the presentation of content as options are selected.

toolbar with 4 buttons for changing page background color, 4 for text size and 3 for page width

The toolbar has buttons to change background color, font size and margin width.  Its “More” menu includes settings to change the font family and the text alignment.

Error Handling

TidyRead does not have the great feature Readable has, which enables users to select the content they want to display.  If TidyRead can not determine the main content of a page, it displays the error, “This page doesn’t look like an article, and TidyRead couldn’t extract”.

iPhone & iPod Touch

TidyRead can be installed on the iPhone and the iPod Touch by syncing Firefox- or Safari bookmarks with iTunes.  Alternatively, there are step-by-step installation instructions.

Relevancy To Clear Helper Project

The reason I am investigating these readability tools is that they could be quite useful to people with cognitive disabilities who are distracted by extraneous content on all Web sites.  Maybe, in addition to offering easy- and standard versions of the future Clear Helper Web site, I could offer on it one of these tools to install.

Notes

Cognitive Web Accessibility Assessments: Aggregate Results

~ John Rochford

I created a set of extensive pages that display aggregate results from my assessments of cognitive Web accessibility.  I also evaluated three more sites.

Results Pages

Seven of the results pages are based upon the sections of WebAIM’s Cognitive Web Accessibility Checklist.  Amongst the pages are aggregated results from assessments of the 44 guidelines that comprise the sections.  The guidelines are defined using WebAIM’s descriptions.

Dynamic Data

In-text results data are are always up-to-date. They are extracted dynamically from a draft database, as are those for the related charts created with Google Chart Tools.

Assessed Web Sites

These are the Web sites I just assessed, and their scores.

View a page of results for all Web sites assessed to date.

Text-To-Speech Services: Choosing ROKTalk over BrowseAloud

~ John Rochford

This post briefly describes ROKTalk and BrowseAloud, and discusses why ROKTalk was chosen over BrowseAloud for an upcoming Web Site for people with cognitive disabilities.

That Web site will be a report for The Massachusetts Department of Developmental Services.  It will be published by The Eunice Kennedy Shriver Center, for which I work.  The project staff and I received good Webinar-based demonstrations from company representatives.  We saw BrowseAloud and ROKTalk in action on production Web sites.  We also paid careful attention to their usage instructions provided for the benefit of site visitors.

Description

BrowseAloud and ROKTalk read Web pages aloud.  Web sites incorporate these text-to-speech (TTS) services for use by site visitors who find reading difficult.  Common reasons for this include intellectual disabilities, learning disabilities, mild visual impairment, and/or illiteracy.

Both services offer other features, such as increasing text-size, highlighting text as it is read, translation of text to other languages, and changing the background color.  These features can be activated from a floating toolbar, the appearance of which can be invoked by the site visitor.

An image of the BrowseAloud toolbar is displayed below.Browse Aloud toolbar has 7 multi-colored buttons in a horizontal strip.The ROKTalk Toolbar is pictured below.  The image is significantly smaller than the toolbar’s actual size.

ROK Talk toolbar has feature sections with icon-based buttons in each.

Choice

BrowseAloud requires Web site visitors to download and to install software.  For people who do so, an advantage is that BrowseAloud can be used for other purposes, such as word processing.  For Web developers, perhaps especially for inexperienced ones, an advantage is that no related scripting has to be incorporated into the Web site.

Neither of these advantages outweighed what the Shriver project staff and I believe to be the primary disadvantage.  Downloading and installing software would be too difficult for anticipated site visitors, some of whom are likely to have intellectual disabilities.  Likewise, we judged Browse Aloud’s usage instructions to be too complex.

For people who visit a Web site with ROKTalk, the TTS and other text-accessibility features can be used immediately.  No download and installation are required.  That said, it may be the toolbar itself is too complicated.  We may try a customized, less fully-featured version that presumably would be easier to use.

Notes