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.
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.
Reader, a new feature of Safari 5, removes visual distractions from Web pages. This is a boon for people with cognitive disabilities, indeed everyone distracted by advertisements, contextually-irrelevant images, etc..
How Reader Works
For any Web page Safari 5 recognizes as an article, a gray button labeled “Reader” appears to the right of the Web address at the top of the screen. (The button is indicated by a red arrow in the image below of a Wikipedia page.)
Clicking the button, which changes its color to purple, activates Reader. The following image shows the result: a view of only the page’s primary text.
Clicking the button again or pressing the “Esc” key deactivates Reader.
A toolbar appears near the bottom of the screen. It presents options to reduce- and enlarge text size, forward the article via e-mail, and print it.
Safari 5 remembers the selected text size the next time the article is viewed.
Every page of the article is displayed within Reader.
Neither the toolbar nor the Reader button are keyboard accessible.
The toolbar appears for just seconds, so using it means acting fast and with accuracy.
Clicking a link to an external page, even if Safari 5 recognizes it as an article, displays it outside of Reader.
This is the first time such a readability tool has been built into a popular Web browser. I hope it is adopted by all the others. For now, equivalent tools can be added to browsers via plug-ins. Three I have reviewed are listed below.
I also hope these readability tools show Web designers how difficult the reading experience can be. Large- or animated advertisements and other distractions can drive people from Web sites. Simple page layouts designed for readability can have the opposite effect. An example of this is Craig’s List.
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.
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.
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”.
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.
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.
Reports have two sections: monthly- and weekly statistics. Each has two subsections.
times e-mail is checked;
hours spent using CogLink;
messages received; and
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).”
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.”
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.
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 (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.
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.
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.
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.
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.
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.]
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.
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.
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.
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.
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.