I am intrigued by the iPad’s potential as a computer for people with intellectual disabilities (ID). It could be set up as a Web-access only device, and essential functions could be Web-based. This could be done with computers, but the iPad has at least two distinct advantages.
no or low hardware-maintenance
minimal management of software updates and installation
These advantages alone are enormous in terms of overall ease-of-use. They are also great for dramatically reducing long-term technical support- and training costs compared to those needed for computers.
I think that to make an iPad truly useful for people with ID, an even simpler interface could be developed for it. I imagine that, upon being turned on, the iPad could present three or four buttons.
One button could start a Web-based e-mail app, such as CogLink that is designed for people with ID, or one with which a user is already familar, such as Yahoo Mail.
A button could start a Web browser app, like Web Trek, which is designed for people with ID.
Another button could start an augmentative-communication app. They exist already. Jane Farrall recently posted a list of iPhone/iPad augmentative communication apps on the Spectronics Blog.
An iPad, with a simple-to use interface similar to those presented by augmentative communication apps, would be a lot less expensive than single purpose AC devices or multi-function computers.
Readers may be interested in these articles:
All eyes on iPad, a Great Schools article, by Valle Dwight, which describes how the iPad might be a an assistive-technology device for her son with Down Syndrome.
iPad Accessibility, an Anikto blog article by Kel Smith, which discusses the iPad’s potential for people with cognitive disabilities.
Note: For the purpose of exploring the iPad’s potential for people with intellectual / cognitive disabilities, one was generously provided to me by the project for which I work, New England INDEX at the Shriver Center, part of The University of Massachusetts Medical School.
Developing a Multimedia Environment to Aid in Vocalization for People on the Autism Spectrum: A User-Centered Design Approach – Al-Wabil, Areej
EasyICT: a Framework for Measuring ICT -Skills of People with Cognitive Disabilities – Dekelver, Jan
Involving users in the design of ICT aimed to improve education, work, and leisure for users with intellectual disabilities – Gutiérrez y Restrepo, Emmanuelle
Methodological Considerations for Involving SpLD Practitioners in the Design of Interactive Learning Systems – Karim, Latifa
PDA software aimed at improving workplace adaptation for people with cognitive disabilities – Ferreras, Alberto
The Performance of Mouse Proficiency for Adolescents with Intellectual Disabilities – Wu, Ting-Fang
Towards an Interactive Screening Program for Developmental Dyslexia: Eye Movement Analysis in Reading Arabic Texts – Al-Wabil, Areej
When Words Fall Short: Helping People with Aphasia to Express – Al Mahmud, Abdullah
Adaptive Reading: A Design of Reading Browser with Dynamic Alternative Text Multimedia Dictionaries for the Text Reading Difficulty Readers – Chu, Chi Nung
Easy-to-web search for people with learning disabilities as part of an integrated conception of cognitive web accessibility – Erle, Markus
EasyWeb – A Study How People with Specific Learning Difficulties Can Be Supported on Using the Internet – Matausch, Kerstin
In-Folio: An Open Source Portfolio for students with learning disabilities – Ball, Simon
Supporting the web experience of young people with learning disabilities – Weber, Harald
The need for Easy-to-Read information on web sites – Bohman, Ulla
Annual Conference of The American Association on Intellectual and Developmental Disabilities
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.
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
No endorsement of TidyRead is intended or implied.
Since before Web-accessibility evaluation tools were available, developers have used JAWS to test their Web sites. I have for so long that not using it never occurred to me. I was spurred to consider the possibility at a recent demo about the newest version. Eric Damery of Freedom Scientific, the maker of JAWS, proposed it. This post details the reasons I am considering no longer using JAWS for Web accessibility testing. Future posts will discuss alternatives.
Description of JAWS
JAWS is wonderful software. For a person with a significant visual disability, it reads aloud or converts to Braille the content sighted people view on their computer screens. Without the JAWS screen reader or one of its competitors, hundreds of thousands of people would be unable to use computers, nor would they be able to access the Web.
Using JAWS For Accessibility Testing
People who are blind have long been considered the most excluded from the Web. This is the central reason Web accessibility standards have been focused on making sites accessible to them. (An even larger excluded population are people with cognitive disabilities, but that is a topic for another day.) Thus accessibility-minded developers have always considered it important to test sites with a screen reader. JAWS is chosen for this because people with visual disabilities use it more, by far, than any other screen reader.
Another benefit of accessibility testing with JAWS is that sites made compatible with it also often work well for people with physical disabilities. People who can not use a mouse, and/or who use a single-switch device instead of a keyboard, can navigate an accessible Web site in a way similar to that of JAWS users. A simple approximation of this experience is to visit a Web site and attempt to navigate it using only the Tab key.
Reasons I Am Considering No Longer Using JAWS
Though I have used JAWS to help test Web accessibility since the time (1995) it was first available, I know only enough about it for such testing. Like all screen readers, JAWS is complicated. For people who must use it to access a computer, many months are typically needed to learn it well. Over the years, as I have hired developers and introduced them to Web accessibility and JAWS, it has been difficult for each to master it sufficiently for accessibility testing. In part this is because they don’t have to use it all the time as people who are blind do.
Another reason developers find JAWS troublesome is that the Web content it reads can not be visually tracked. The temptation for sighted developers to watch JAWS is too great. They are so dependent upon their sight that trying to get them to test Web sites while their screens are off, for instance, is difficult.
Sighted developers inexperienced with JAWS, and sighted people to whom JAWS is being demonstrated, are often confounded by the way it reads Web content. They expect it to read an entire Web page as they perceive they do. Instead, JAWS reads Web pages in chunks and pauses before links. This behavior closely mimics what sighted people really do, which is to skim Web page content.
JAWS is expensive. At the time of this writing, it costs $895 for most people, plus an annual software maintenance agreement (SMA) of $120. Cost alone can be an initial barrier for people who are blind and, as a population, are chronically underemployed. For developers who use JAWS to test accessibility, Freedom Scientific requires the more expensive professional version. Its cost of $1,095 plus a $200 yearly SMA can be a barrier for developers without institutional backing. To evangelize accessibility testing to other developers, I am interested in lower-cost or free alternatives.
“Ninety percent of blind people don’t use a screen reader.” Kevin Carey, Chairman of the Royal National Institute of Blind People (RNIB), said that recently at an INMD seminar for Web developers. He also said that is the reason Web sites should be made “self-voice”. I imagine he was referring to people who are legally blind. To access Web sites, they must use screen-magnifiers, text-to-speech software, and/or Web site widgets.
Notes
JAWS is only one of many tools my team has used to test Web site accessibility. Most importantly, people with disabilities have always been hired to vet the accessibility of our Web sites as much as possible.
This post is about reports from CogLink, e-mail software designed for people with intellectual disabilities. I have been receiving them in my capacity as the “Helper” of the person using Coglink (also me).
In my review of CogLink, the last of three posts about it (see list below), I explained the CogLink term “Helper”. It is someone who installs it, provides assistance during automated training on how to use it, and manages its advanced features. One of them is an option to receive monthly usage reports.
Report Contents
Reports have two sections: monthly- and weekly statistics. Each has two subsections.
Social Measures
Number of:
times e-mail is checked;
hours spent using CogLink;
messages received; and
messages sent
About this section, the report explains:
“These items reflect the user’s initiation of and overall engagement in email, including time spent emailing and the level of social exchange (i.e. messages sent vs. received) with their email partners. Decreases in email activity over time may indicate the need for the support person to contact the user and/or their partners concerning possible reasons for these changes (e.g. technical problems, change in email address, out-of-town).”
Skill-based Measures
Number of:
hours spent composing email;
words per minute;
words per sentence; and
characters per message
About this section, the report states:
“These items reflect the user’s email message composition skills. For example, examining trends in the average # words per sentence or sentences per message may reveal changing skills in using email.”
Conclusion
I think these reports are useful in helping people with intellectual disabilities learn how to use e-mail. Because repeated, consistent training is likely needed, these reports are a good way to track related problems over time.
The reports do not include confidential information, such as the content of e-mail messages, nor statistics broken down by e-mail “Buddies” (Coglink’s term). In my opinion, the reports provide just enough information to be helpful without being invasive of privacy.
I have created an index of readability resources related to plain language; measurement tools; guidelines, research; content; symbols; and free- and commercial products and services. At the time of this writing, there are over fifty. I will add more as I find them.
Characteristics Of Readability Listings
All have links to the original sources.
All are annotated with related information, primarily edited quotes from source pages.
The majority are free- and commercial products and services. The rest are research articles.
The publication dates of original studies and articles range from 2001 to 2009 / present.
I have created an index of assistive technology resources related to cognitive Web accessibility. At the time of this writing, there are over fifty. I will add more as I find them.
Characteristics Of Assistive Technology Listings
All have links to the original sources.
All are annotated with related information, primarily edited quotes from source pages.
About half are original studies and articles. The rest are free- and commercial products and services.
The publication dates of original studies and articles range from 2001 to 2009 / present.
Research It is a new feature that enables JAWS users to quickly access information. It uses APIs of publicly-available databases to retrieve the information on demand. For each of the databases on DisabilityInfo.org, I could create an API for JAWS users. I could then develop a Web-based search interface to query that API and others, and that is accessible to people with cognitive disabilities.
JAWS
JAWS (Job Access With Speech) is screen reader software used mainly by people who are blind or who have a significant visual disability. It reads aloud in a voice the information sighted people see on their computer screens. Yesterday, I attended a demo of JAWS 11, the newest version. It was held at the Perkins School For The Blind by Eric Damery of Freedom Scientific, the maker of JAWS.
Research It
Of the new JAWS 11 features Mr. Damery demonstrated, it was Research It that caught my attention. It is designed to be the equivalent of desktop gadgets. Sighted people can glance at a desktop gadget to obtain information, then quickly return to their primary task. Research It serves the same function for JAWS users.
With a single keystroke, JAWS users can open a field in which to type a query for weather reports; local businesses; FedEx-package tracking; baseball- and football scores, etc.. At the time of this writing, Research It can access 17 information sources. Mr. Damery mentioned he had six more under development.
APIs
An Application Program Interface (API) is a software component that enables interaction with other software. An API controls which data can be accessed and what can be done with them. When JAWS users type a search term, such as “pizza; 33716”, Research It queries a publicly-available API that returns a list of pizza restaurants within and around that Zip code.
Using best practices of accessibility for people with cognitive disabilities, I could then develop a Web-based search interface to query the new API of the DisabilityInfo.org databases. On that Web site, the search interface would not need to use the API because it would directly access the databases. However, it could be embedded on other Web sites so their users could query DisabilityInfo.org databases via the API. It also could be extended to be more universal; it could query the APIs of other publicly-available databases. This would be especially useful for bypassing inaccessible interfaces such sites may have.
For many of the Research It search demos, Mr. Damery used two-word terms. At least one had three, that for city, state and “weather”. Although I am sure the intention is to keep search terms as simple as possible so using them is speedy, others could require even more words. Implementing their syntax and remembering them may be beyond the capabilities of users with cognitive disabilities. Therefore, I would likely develop an alternative solution I previously discussed, a search-wizard interface.
Note: On March 1, 2010, Freedom Scientific will conduct a Research It Webinar on creating custom rule sets and lookup modules.
I created a test page for an experiment with Speeka text-to-speech (TTS), graciously provided by Simon Evans of Cognable. I plan to incorporate TTS into every page of the future Clear Helper Web site.
Background
Speeka, a free service, is a work in progress. It is not a polished, commercial product. It is one of many Mr. Evans is developing to improve accessibility for people with intellectual disabilities. A brief description of each of his projects can be found on the Cognable home page.
I think Speeka’s initial implementation was on the the Web site of Inclusive New Media Design. INMD is an organization that, like me, is working to develop best practices of Web accessibility for people with intellectual disabilities. When I first saw Speeka, I immediately liked its small form factor compared to that of ccPlayer, which I have been using.
Appearance & Placement
Speeka is embedded throughout the INMD site in the top, right of the content section. It appears as the image below. On my test page, it appears as the following image.
I too placed it in the top, right of the content section. Of the Web sites I have visited that use a TTS feature, most embed it in a similar location. Those that don’t place it on the bottom of their pages.
Configuration
Setting up Speeka in my test page was a simple affair. I inserted the HTML code provided by Mr. Evans. I needed only to change the referenced file name. I made one addition; that of the application landmark role to Speeka’s container. This helps people with screen readers, who use WAI–ARIA, to identify it. Upon placing the test page on the Clear Helper Web site, I invoked a hyperlink Mr. Evans provided to inform Speeka of the page’s presence.
Voice-Narration
I configured Speeka so it reads only primary content. It can be set up to read all the textual content of a page, including menus, but I suspect it would be tiring to listen to the same menu over and over.
I chose to use a natural sounding, British male voice. [Edit on 2010-01-31: The voice is now an American one.] The test page it is reading contains text written as simply as I could at the time. Its pronunciation of the words and the sentences is very good. It had no problem with my last name. I will have to test it with more complex text and with unusual proper nouns.
It announces every heading with the word “heading”; each list item prefaced by the word “bullet”; and the beginning- and the end of every list. I was surprised. This feature is the first I have experienced with a TTS application. It may be useful, but I think it would better serve as an option. [Edit on 2010-03-14: Announcement of list bullets, beginnings and ends is now an option. It is not active on the test page.]
General Navigation
The three-button interface is simple. The audio narration can be played and paused with the same button. The forward button advances the narration by six seconds; the back button rewinds it by four. Suggestions:
Perhaps it would be better if the forward- and the back buttons advance and rewind to adjacent sentences.
An option to restart the narration from the beginning may be helpful. The only way I could do it was by refreshing the page using the Web browser.
Audio- and visible text labels for the buttons are a necessary feature, I think. An example can be found in a BBC Flash Player designed for people with intellectual disabilities. It can be seen on the BBC’s Us 5 site, by clicking the link “Launch Us5 videos in pop-up windows”, then by selecting an actor.
Keyboard Navigation
Pressing the Tab key cycles through the buttons. The Space Bar or the Enter key invokes them. I had no trouble with this navigation within Speeka, but I could not tab inside the Web page to get to it. I could use the Tab key with Speeka only after changing focus to it by clicking it with my mouse. This is not unique to Speeka. I experienced the same with ccPlayer. Keyboard navigation is important because many people with intellectual disabilities also have physical ones. Such disabilities often preclude the use of a mouse, and require keyboard use or a single-switch device.
Interface Text
When the play button is clicked, the “audio stopped” text changes to a countdown of time until the end of the audio narration. I think being presented immediately with the “audio stopped” text is potentially confusing. I also think both it and the countdown test may not be necessary.
Speaka-Service Functions
Speeka converts Web-page text to MP3 files. When a Web site visitor clicks the play button, the MP3 is streamed to the visitor’s computer from a Cognable server. This is advantageous for Web sites that do not have a streaming-media server nor the bandwidth to support one.
A great feature of Speeka is it checks the text of each page on a regular basis. When it detects a change, it updates the associated MP3 file. Graphed statistics about this can be found on the Speeka home page.
Conclusion
Speeka has many nice features. I think its inclusion on a Web site designed for people with intellectual / cognitive disabilities would provide site visitors with a significant accessibility feature. With all of Mr. Evans’ projects, I don’t know if he has the time to consider some of the options I have mentioned, but I plan to discuss them with him.
Note: No endorsement of Speeka or Cognable is expressed or implied.
Ray Kurzweil is a giant in the accessibility industry. He has been inventing reading machines and devices used by people with visual- and reading disabilities for 35 years. His newest creation is the Blio eReader, digital-book-reading software.
Note: At the time of this writing, the Blio eReader is not yet available to the public. However, in a CNET interview (video below), Ray Kurzweil says it will be within one month.
Blio eReader Feature Highlights
It combines full-color, digital content with Web content, video, and audio narration.
It runs on Windows computers, tablets and mobile devices such as the iPhone.
It is free, and has access to a million free books. (Presumably, there will be a store of books for sale.)
Its catalog includes “cookbooks, travel guides, how-to books, schoolbooks, art books, children’s stories, and magazines”.
Books can have interactive, multi-media content and quizzes.
Accessibility Features Good for People with Cognitive Disabilities
The Blio eReader:
reads books aloud via either an accompanying, human-read audio track or via a text-to-speech reader;
synchronizes its synthesized voices with “follow-along word highlighting”;
has adjustable reading speed and font size;
has a text-only mode good for minimizing distractions and also for displaying on small screens;
uses a “3D book view which includes realistic page turning”; and
can be connected to a personalized set of reference Web sites for “one-touch look-up of highlighted phrases”.
In the YouTube video below, CNET interviews Ray Kurzweil about the Blio eReader. A demonstration of it begins at about 2 minutes, 23 seconds (point 2:23). This video is not closed captioned.
On my 