Category: About Project

Proposed Navigation Buttons For Future Clear Helper Web Site: Draft 2

~ John Rochford

Displayed below is my second attempt at a set of navigation buttons for the future Clear Helper Web site.  They were created using the guidelines and tests discussed in my post about the first draft of two sample buttons.  I am open to constructive criticism and/or suggestions for alternative versions.

Each button will appear on a page only if relevant. For instance, if the succeeding page is for a tutorial, the following three buttons will appear as content options.  They are intended to represent the content versions of text; pictures and text; and video.

VideoTextPictures and Text

The following two buttons, for back and next, will appear, for instance, only if tutorials have multiple pages.

NextBack

The home page button, below, will appear on every page.

Home

Upcoming buttons will include two for switching styles from “Standard” to “Easy”.  I have an idea for how to represent these concepts in a concrete way.  That will be the subject of a future post.

Writing “easy” text is not so easy

~ John Rochford ~ 2 Comments

Today, I tested the readability of the “easy” text for the home page of the Clear Helper Web site.  I decided to use Standard-Schmandard’s Readability Index Calculator because of the trouble I reported in my post, “Juicy Studio Readability Test: Contradictory Results“.

I entered the home page’s easy text and chose the Flesch-Kincaid (English) test. Results:

  • Grade level: 13
  • Reading Ease score: 44

The Grade Level score indicates a person would have to reach the 13th grade (in the U.S.) to understand the text. The Reading Ease score, for which higher means easier, fell in between comics (score = 90) and legalese (score = below 10) according to Standards Schmandards.  I was disappointed the text I wrote scored so poorly.

I then removed all three-syllable words.  Results:

  • Grade level: 11
  • Reading Ease score: 55

These were still not the scores for which I was hoping.  I’m having a difficult time finding information on which levels of scores would be good for people with intellectual disabilities, but I know even the last set are too high.

My next step is to attempt to simplify the text, then try another readability test.  Results will be posted.

Note: This is a follow-up to the post, “Switching Between Standard- & Plain Language Versions: 1st Attempt“.

Switching Between Standard- & Plain Language Versions: 1st Attempt

~ John Rochford

I created a plain-language version of the Clear Helper home page.  It displays “standard” text.  Clicking the link “Easy” at the top, right of the home page displays the plain-language version.  The image below shows the menu.

Home Page Menu with choices Easy, Skip to content, Need big text?

Technical Method

This is my first attempt at creating a plain-language version.  I focused on accomplishing it technically.  This is a follow-up to my previous post, “Using Plain Language for People with Cognitive Disabilities: Discussion, Example“.

The method I used to create two language versions of the same page is to include all of the text content in it, but hide from the user one version or the other depending upon which the user selects.  I used the CSS “display” property with a value of “none” for this purpose.

Alternative

It may be more efficient to use a database-driven system that stores and displays the content depending upon user selection.  There are content-management systems (CMS) specifically designed to create accessible pages and that have accessible content-management interfaces.  One such example is Webcredible’s Accessible CMS.

Improvements

I did make a few improvements to the page-version switcher I described in my post “2 Accessible Versions, 1 for People with CD: Rough Draft In Action“.  I:

  • changed two menu choice labels, one from “Simple” to “Easy” and the other from “Regular” to “Standard”;
  • set the menu so that, rather than displaying both of those menu choices, it shows “Easy” on the standard version and “Standard” on the easy / plain-language version;
  • placed the accessible text-to-speech (TTS) player for both versions in the same place, so people will always know where to look for it, and at the bottom of the page where it would not cause initial distraction; and
  • created a MP3 audio narration of the plain-language version.

Next Steps

In future posts, I will publish the results of:

  • checking if screen readers or search engines have trouble with a page containing two versions of content but displaying one; (I suspect not.)
  • running a readability checker on the “easy” text, and determining if it meets plain-language guidelines; and
  • investigating whether or not Webcredible’s Accessible CMS or one of its competitors has the capability to switch between two content versions of the same page.

Using Plain Language for People with Cognitive Disabilities: Discussion, Example

~ John Rochford ~ 2 Comments

Previous posts have discussed switching between two accessible versions of the same Web site.  The version for people with cognitive disabilities would not show secondary content such as columns of links and image-based advertisements.  Instead, it would only show primary, textual content and contextually-related imagery.  This is well and good from a design perspective.

However, a Web site’s primary content can be as confounding to people with cognitive disabilities as a cluttered design.  Text must be written in plain, simple language.  There are efforts all over the world to encourage the use of plain language for everyone.  See PlainLanguage.gov (U.S.), Plain English Campaign (U.K.) and Plain Language Association International (world).  So, though this problem is not unique to people with cognitive disabilities, they are put at a particular disadvantage because of the nature of their disability.

For the future Clear Helper Web site, I would like to have two content versions: one with standard language and one with a lower readability level.  Future posts will discuss how this might be accomplished technically.

Example Web Site

There is at least one Web site that enables users to switch between two language versions: one for “Standard” English and one for “Easy” English.  It is of The NSW Council for Intellectual Disability in New South Wales, Australia.  Clicking the “Easy English” button on the home page produces a welcome message with instructions on how to use the site.  As users navigate through the pages, each can be switched between the two language versions via buttons at the tops of the pages.

Usability Errors?

The site is designed to meet accessibility standards, but there are are some odd interface choices.  Examples:

  • The menu for the standard fact sheets has relevant images, but they are not clickable like the links below them.
  • All of the “Standard” English fact sheets are Web pages, but all the “Easy” English ones are PDFs. Browse Aloud, which is available on the site, can read PDFs.  Yet counting on users to have it and a PDF reader installed seems like an unnecessary complication.
  • The “Easy” English welcome page requires visitors to use the “Contact Us” tab at the top of the page because the “Contact Us” text referencing it is not clickable.

Despite these minor quibbles, I think it’s great that the Web site provides two language versions, one targeted to people with intellectual disabilities.  I soon will be attempting the same.

This post is a continuation of the following:

2 Accessible Versions, 1 for People with CD: Rough Draft In Action

~ John Rochford

I have working a rough draft of the idea I outlined in my previous post, “Switching Between 2 Accessible Versions, 1 for People with Cognitive Disabilities“.  On the Clear Helper Web site, I have enabled visitors to switch between two versions.  Both meet all accessibility standards.  One contains all content and the other contains only primary content.  This should help people with cognitive disabilities complete core tasks, such as finding the information they need, without the distractions of extraneous content.

Pictured below is the top half of the home page.  Its default style is two columns.  The left one contains the primary content.  The right one has the accessible, text-to-speech (TTS) player and a column of links.  At the top of the page, on the right side, is a menu that includes the choices “Regular” and “Simple”.  A click to one changes the page’s style respectively.

2-column Web page. Primary text on left. Player and links on right.

Clicking the “Simple” link changes the home page’s style to the one pictured below.  The column of links is gone, the TTS player is moved to the bottom of the page, and all of the footer content (not pictured) is also removed.  The primary, textual content expands across the width of the page.

1-column Web page displaying only textual content

In my implementation of the style switcher, I made one significant improvement over ones I have used on other Web sites.  I am using server-side scripting instead of JavaScript.  This means better accessibility for assistive-technology users and certainly for those who disable JavaScript.

I am open to suggestions for improvement.  I will continue to experiment and report on my progress.  It almost goes without saying, of course, that a “simple” style will be the default for the future Clear Helper Web site.

Switching Between 2 Accessible Versions, 1 for People with Cognitive Disabilities

~ John Rochford

It is a well-accepted axiom that a Web site can meet all accessibility standards yet still be unusable by people with a wide variety of disabilities.  The W3C discusses this in its article “Understanding Conformance“.

It is also true that a Web site can both meet all accessibility standards, and be usable by a wide variety of people with disabilities, yet still be unusable by a subset of people.  For instance, a Web page with columns of links, tables and image-based advertisements may be accessible to all who use assistive technology, yet be inaccessible to people with cognitive disabilities.

The WC3’s new Web Content Accessibility Guidelines (WCAG 2.0) define a technique entitled “C29: Using a style switcher to provide a conforming alternate version“. It is intended to allow Web developers to provide a version of a Web site that conforms to accessibility standards when its default version does not (meet a standard or standards).

For the future Clear Helper Web site, I am considering employing this technique a little differently.  I would like to enable users to switch between a version that meets all accessibility standards and contains all content, and a version that meets all accessibility standards but contains only primary content.  This would help people with cognitive disabilities complete core tasks, such as finding the information they need, without the distractions of extraneous content.

The details of how I might implement this will be the subject of a future blog post.

Good Info from a Self Advocate & a Person with ID

~ John Rochford

Today, I received good information from Mary, a self advocate, an active member of her community and an occasional Web user.  Mary is also a person with an intellectual disability.

Success & Suggestion

Mary told me she had used Google with success to find the mailing address of her local state representative.  She explained many people she knew would like to find similar information, and suggested I create a tutorial on how to do so.  That is a great suggestion for the future Clear Helper Web site.

Challenge & Resolution

She reported trouble using the DisabilityInfo.org Web site.  The home page, she said, was too full of choices.  I designed that site, and I agree with her.  Since I have been designing sites back when the Web was born, people have insisted that everything must go on the home page.  This makes for a very cluttered, confusing page that does not convey the site’s core message, and does not enable visitors to access its information easily.

When I first designed the DisabilityInfo.org Web site a few years ago, it met accepted accessibility standards (WCAG 1.0 AA compliance) and was given a good accessibility review by testers who were blind.  It is not perfect.  For instance, it does not use headings as well as it should.  Yet, most importantly to my current awareness, it has no accessibility features specifically intended for people with cognitive disabilities.  I will be redesigning it next year.  I will apply to its new design the accessibility- and the usability lessons I learn with the Clear Helper project.

Focus Group

Next month, Mary is hosting for me a focus group of ten people with intellectual disabilities.  I will be asking them the questions I outlined in my blog post on Interviewing People with ID about Web Accessibility.  I am sure they will have a lot of good ideas for me.  I will report them in a future post.

Note: Mary told me she wanted to learn American Sign Language to communicate with coworkers, but was unsuccessful finding on the Web such a training program.  (The agency that serves Mary found a local one geared for people with intellectual disabilities.)  If anyone knows of a Web resource listing training programs intended for people with intellectual disabilities, please tell me.  If there is not one, it may have to be a future project for me.

Great Text Accessibility Toolbar for People with Cognitive Disabilities

~ John Rochford

I recently discovered Talklets, a text accessibility toolbar for Web sites that could be of great help to people with cognitive disabilities.  It can be seen in action on the Web site of Rok Talk, the developer, and on the Web site of Regional Support Centre, Scotland North & East.  Take a look at it on the latter site.  To do so, click the button entitled “Click to Show Text Reader” on the right of the home page, near the top.  The toolbar then appears at the bottom of the page.  The main part of it looks like this.

strip of round, colored buttons with symbols for play, stop, record, etc.

Features

Via simple buttons, the toolbar enables Web site visitors to:

  • listen to the text of the entire page or just to the text to which a user points the cursor;
  • record the text to a MP3 file that can be easily downloaded;
  • enlarge, reduce or restore the text size;
  • highlight the text in different colors; and
  • see a help window that explains how to use each feature.

Extra features include enabling users to retrieve the definition of any word, change the pronunciation of a word, and highlight words as they are read.

The developer says the toolbar does not interfere with screen readers, and can be used by people who are blind (and don’t have access to a screen reader) via keyboard controls.

Follow-Up

I will be contacting Rok Talk to discuss its pricing structure and to determine if it would be willing to let me experiment with the toolbar on the future Clear Helper Web site.

Note: No endorsement is intended or implied for this product.

Interviewing People with ID about Web Site Accessibility

~ John Rochford

I will soon be conducting more interviews with people with intellectual disabilities.  I have three primary areas of interest:

  1. the sites they find inaccessible and accessible, which I am conveying as “easy to use”;  (I will explore the reasons.)
  2. which site features do they find helpful or not, “like and dislike”; (The answers may help me choose for which sites I should create tutorials.) and
  3. what they would like to learn about using the Web.  (This is to help inform me about the subject matter of future tutorials.)

These are the questions I will be asking of people:

  • Which sites are hard to use but you really want to use?
  • Which sites do you find easy to use?
  • Which parts of Web sites do you like, and which do you dislike?
  • What would you like to learn to do on the Web?

To obtain this information, I am visiting self-advocacy groups, and meeting in person with people with intellectual disabilities.  I anticipate having a computer available at each interview so people can show me as well as tell me.  I will be recording responses in narrative form.

Later in the project, as I design the site, I will need people to test it regularly and give me feedback every step of the way.  I have not yet figured out how best to organize that, but I am open to suggestions.

Note: The W3C has a good article about Involving Users in Web Projects for Better, Easier Accessibility.  I shall rely upon it to help guide my project.

Browser-Based Text/Font Size Switching: Dissatisfaction & Solutions

~ John Rochford

I am dissatisfied with some aspects of the approach that relies upon Web site visitors to use their Web browsers to change the size of Web site text.  I have attempted to solve the problems I perceive with this approach.  This post is a follow-up to my previous post entitled “Browser-Based Text/Font Size Switching”.

Reasons for Dissatisfaction with This Approach & Attempted Solutions

  • I think asking people to invoke a combined-key command with which they are unfamiliar, and with keys they do not use much, is confusing.
  • There are dozens of Web browsers.  Creating screen-shot based instructions for all of them is impractical.
    • I implemented a JavaScript application that displays a link to screen-shot based instructions only if visitors are using either Internet Explorer 8.x or Firefox 3.x.  If they are using another Web browser (or if they have JavaScript disabled) the page displays an instruction to refer to their Web browser’s help menu.
  • I created screen-shot instructions for Firefox 3.x and screen-shot instructions for Internet Explorer 8.x.  Their menus for adjusting text size are markedly different from those of their previous versions.  Many people do not use the latest versions.  Asking them to decide which to use of multiple sets of instructions, one for each previous Web browser version, would be very confusing.  Many people do not know what a Web browser is, let alone which version of it they are using.
    • The JavaScript application checks the visitor’s Web browser version.  If it is Firefox 3.x (the latest version), the page displays a link to screen-shot instructions for it.  I did the same for Internet Explorer 8.x (the latest version). If visitors are using an older version of either browser, the page displays textual instructions telling them how to use the old-style menus.
  • The screen shots for Internet Explorer are especially high/long.  It does not become apparent which menu to use until the visitor scrolls down the image(s).  This will likely be confounding.
    • I have no practical solutions for this.  Reducing the size of the images reduces their text size.  People who need to enlarge text size would not appreciate that.

I will consider how to improve this approach, or scrap it for something better.  As always, I am open to suggestions.