CSUN and Assistive Technology

CSUN/Tseng College LogoAssistive Technology (AT) is experiencing amazing growth. An increasing aging population is creating new needs to address. Specialists are needed to identify user needs and connect them to the right AT. Assistive Technology used to focus on hearing, sight, or movement issues. Newer technologies are helping the way we learn and process information. These include:

  • Cognitive aids that help people with challenges in thinking skills
  • Computer software/hardware: voice recognition, screen readers, closed captions
  • Artificial Intelligence
  • Machine Learning
  • Neuroscience

Recently, I learned about Assistive Technology programs at Tseng College. Tseng College is a part of California State University, Northridge (CSUN). Located in Los Angeles. One area that it specializes in is programs for mid-career adults. These programs are mostly online. This gives working people the ability to learn new skills on their own time. Instructors, classmates, and field experts create a supportive group environment.

Master of Science, Assistive Technology Engineering
This program is taught by working engineers. Students have hands-on experience in addition to the online course. The program provides:

  • Design experience to create new assistive technology
  • Project and team management skills
  • New technical abilities
  • Ability to define new uses for existing technologies
  • A working portfolio to share work with potential employers

Master of Science, Assistive Technology Studies and Human Services (ATHS)
This program is the first of its kind in Southern California. It creates skilled AT specialists who can:

  • See the connection between human and technology factors
  • Assess AT users’ needs and identify solutions
  • Explain and train the solution to the AT user
  • Translate the legal and political history of AT

Accessibility and IoT / Smart and Connected Communities

Association for Information Systems

I recently published an article, “Accessibility and IoT / Smart and Connected Communities” in the journal of the Association for Information Systems (AIS).

The intended audience is user experience (UX) designers.

Article Content

  • How the Internet of Things (IoT) Can Best Work for People with Disabilities and Everyone
  • Independent Living
  • Loneliness
  • UX Accessibility
  • UX Security and Privacy
  • Smart Cities

Notes

First Thoughts on iPad Potential for People with Intellectual Disabilities

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:

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.

Conferences Related to Technology, Web Accessibility and Cognitive Disabilities

Two upcoming- and two recent conferences are listed below along with their related topics and presenters.

Upcoming Conferences

All Together Now: The Power of Partnerships In Cognitive Disability & Technology

  • October 21, 2010 – Westminster, Colorado, U.S.
  • Forty Years after PARC v The Commonwealth of Pennsylvania: Is there a right to technology access? – Gilhool, Thomas
  • A Partnership for Technology to Improve Quality of Life – Pietrangelo, Renee
  • Accessible TeleMEd and eHealth Strategies for People with Cognitive Disabilities – O’Hara, David
  • Technologies to Improve Quality of Life for People with Cognitive Disabilities – Kautz, Henry
  • Developing an Accessible National Information Infrastructure for People with Cognitive Disabilities – Coleman, Bill

Web Accessibility London 2010 Unconference

  • September 21, 2010 – London, England
    • “The unconference will have a motor impairment theme … ” but “… will also consider cognitive impairments and the wider-disability population.”

Recent Conferences

12th International Conference on Computers Helping People with Special Needs

  • July 14 to 16, 2010 – Vienna, Austria
  • Track IV, Session C: People with Specific Learning and Cognitive Problems: ICT, AT and HCI
    • 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
  • Track IV, Session D: Easy – to – Web
    • 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

Know of another such conference? Please post a comment.

New Readability Tool Built Into Safari 5

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.)

Wikipedia page displayed within Safari 5.

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.

Three columns. The middle one contains the article's text. The others are black bars that mask distracting elements.

Clicking the button again or pressing the “Esc” key deactivates Reader.

Features

  • 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.

Problems

  • 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.

Thoughts

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.

Other Readability Tools

Free Readability Tool for iPhone & Desktop Web Browsers

Readable Tool Better Than One David Pogue Says Is Best Tech Idea Of 09

Readability: Free Tool Strips All Distractions From Web Pages

Note: The version of Safari referenced above is 5.0 (7533.16). No endorsement of it is intended or implied.

Free Readability Tool for iPhone & Desktop Web Browsers

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

Stop Using JAWS for Web Accessibility Testing?

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

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. “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.
  • Reason 5 may mean I should place more emphasis on my experiments with text-size enlargement and incorporation of text-to-speech features.
  • The quotes attributed to Kevin Carey were provided to me by a person who attended the seminar.
  • I am interested in feedback.  Please comment.

[Editor’s Note: Readers may be interested in a follow-up post, “First Experiment with MAGic for Web Accessibility Testing“.]

E-mail Usage Monitoring for People with Intellectual Disabilities

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.

Related Posts

Note: No endorsement of CogLink is intended or implied.

50+ Assistive Technology Resources Related To Cognitive Web Accessibility

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.

Links to Assistive Technology Index & RSS Feed

Future Indexes

I will soon publish other such indexes. To see a list, please refer to my previous post, “Upcoming Indexes of Resources Related to Cognitive Web Accessibility“.

Notes

Building an API for JAWS Users May Be Useful to People with Cognitive Disabilities

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.

Building an API for Research It

I am considering creating an API for the databases of DisabilityInfo.org, a Web site maintained by New England INDEX, the UMass Medical School project for which I work.  I would also create custom rule sets and lookup modules for Research It to access the API. This would be particularly useful to JAWS users living in Massachusetts because the databases contain information about disability-specific programs and services within it.

Possible Search Interface

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.