No Accessibility Benefit To Google Analytics Asynchronous Tracking

For years, I have used the Google Analytics JavaScript snippet to track Web page usage.  The problem for Web sites is they do not track visits by assistive technology (AT) users who, for accessibility reasons, have JavaScript turned off in their Web browsers.  The problem for AT users, particularly screen-reader users, who keep JavaScript enabled, is they are warned a JavaScript element is present, but it serves no practical value for them.

On December 1 of this year, Google introduced asynchronous tracking for its Analytics program.   It’s purpose is to speed the loading of pages.  What interested me was that it required the JavaScript snippet to be moved from the body of the page to its header.  I speculated that if it were located in the header, screen-reader users would not receive a warning about it.  I implemented the move, and found I was wrong.

In this WAVE accessibility evaluation report of the Clear Helper home page, the little yellow icon at the top, center, clearly shows a JavaScript warning.  Ultimately, this is not a problem for experienced AT/screen-reader users because they encounter such JavaScript all the time and know to ignore it.  For people with cognitive disabilities and others who do not use AT, it poses no problem at all.

Screen Readers, Web Site TTS Plug-ins, Etc.

For people who are blind or who have difficulty reading, there are a variety of solutions for converting text to speech (TTS).  This post is a follow-up to my brief look at Accessible Rich Media Players and TTS for Web Sites.

Screen readers are software programs that read out loud in a voice the text that appears on the computer screen.

Screen Readers For All Purposes

JAWS (Job Access With Speech) is the most popular.  I have been using its professional version, since its inception many years ago, to test Web site accessibility. Windows Eyes, Zoom Text and System Access are its closest, commercial competitors.

Free alternatives include Thunder and NVDA, which is growing in popularity.  Others are built into Windows (see Microsoft assistive technologies) and OS X (see VoiceOver, the well regarded screen reader that is part of Apple assistive technologies).

Screen Readers For The Web

WebAnywhere and FireVox, which is a Firefox extension, work only for the Web.  Both are free.

  • WebAIM Screen Reader Simulation provides a way to experience what it is like to use a screen reader.
  • Fangs, a Firefox extension, is a screen reader emulator that recreates a Web page similar to how it would be read by screen reader.

Text-To-Speech Plug-ins for Web Sites

Many Web sites offer their visitors TTS capability.  Visitors are required to download and install a software plug-in.  Once that is done, visitors are able to listen to the text on any Web site that uses the same TTS technology.  One popular example is BrowseAloud.  Its costs, which are for the Web site owner, are not listed on its Web site.  It does have a free trial.  Another example is Speaks For Itself. It appears to be free, but it seems it has not been updated recently.

Miscellaneous, But Related

ClaroRead, PenFriend and EasyTutor have screen-reader functionality, but are intended more for helping people read and write.

There are also screen magnification programs such as Magic (commercial) and Virtual Magnifying Glass (free).

Accessible Rich Media Players & TTS for Web Sites

At this point, I know of a few Web-based, rich media players that have various levels of accessibility, and a few possible text-to-speech (TTS) solutions.  This post is a follow up to my earlier one about Ideal Criteria for People with Intellectual Disabilities to Listen to Web Text.

Accessible Rich Media Players Embeddable in Web Sites

  • JW Player with the JW Controls Accessibility Plug-in. It plays MP3s and videos, including YouTube videos.  It is skinnable and re-sizable.   It has an intriguing Google Analytics plug-in that enables tracking of which videos are watched and for how long.  It’s cost is low.  It may be the most promising for the Clear Helper Web site.
  • Nomensa Accessible Media Player. Its Web site’s description says it plays videos and audio, but not which formats.  It does say it plays YouTube videos.  There is no mention of skinning or resizing capability.  The site says its cost is low, but there is no pricing information on it.
  • CodePlex Accessible Media Player is Silverlight-based, Microsoft’s Flash competitor.  It is in its first release.
  • Easy YouTube is designed to play YouTube videos only.  It has an interface with easy-to-use controls and big buttons.  I am not sure if it has any built-in accessibility features.

Text-To-Speech For Web Sites

  • TextAloud converts text to MP3s and has natural-voice fonts.  TextAloud can be used on a Web Site and can generate text on-the-fly.  Its cost is low, but the cost of its compatible natural voices for the Web start at $1500.
  • Cognable Speeka converts Web text to MP3s.  It uses open-source voices only.  It may have its own embeddable player, but there is no information about its accessibility.  It was developed specifically for people with intellectual disabilities.  No cost is listed on its Web site.
  • SpokenText converts Web text to MP3s, but does not appear to have an on-the-fly generation capability.  It has a variety of low, annual subscription costs.  SpokenText also has a Firefox extension.

Other TTS Applications

To manually convert Web page text to MP3s, there are non-Web TTS programs I could use, such as Alive Text To Speech or SpeakText.  Previous posts mentioned other such programs I have used, but I will likely try both  TextAloud or Cognable Speaka.

I found a couple of Web-embeddable TTS applications with avatars (talking, lip-syncing characters).  I might experiment with CrazyTalk or Cognable Avatar TTS.

Ideal Criteria for People with ID to Listen to Web Text

People with intellectual disabilities, as do many people, have trouble reading.  For the Clear Helper Web site, I am considering setting up a way for people to listen to its textual content.  Here are my ideal criteria for this feature.

For Web site visitors, I would like:

  • No need for a screen reader.  They are complicated, are very expensive and, at least to my knowledge, are generally not used by people with intellectual disabilities.  (Of course, I will make the Clear Helper Web site compatible with screen readers.)
  • No need to install related software (e.g. a plug-in or a Web browser extension).  This too, in my opinion, would be too complicated.
  • An easy way to play the audio version of the text.  For instance, a click to a standard “play” button that appears and acts the same way on every page.

For the Clear Helper Web site, I would like:

  • A rich media player that:
  • Sound files that:
    • can be played both by an embedded rich media player and later by the user on any computer.  MP3s come closest because of their ubiquity and the wealth of software, free and commercial, that play them;
    • either are generated on-the-fly for dynamic text or are automatically updated any time static text is edited; and
    • use natural-sounding, royalty-free voices;
  • Video files that:
    • are embeddable into a Web page without the need for Flash (HTML 5 has that promise, but it’s probably a long way off.)

Am I asking too much?  Well, my research so far has revealed the solutions that come closest to these ideals.  They will be the subject of my next post.

Using TTS & Microsoft SAPI on Clear Helper Home Page

Today, on the “Clear Helper” home page, I replaced the “Chilled US/Canadian Male” voice font, which I had obtained from Cognable’s speech demo, with the Microsoft Anna voice font.   Though also obviously a computer-generated, text-to-speech (TTS) voice, it sounds a little better than the male voice I first used.  (See Post: “A Beginning for the Clear Helper Web Site“.)

I used a different tool this time to generate a MP3 recording of the home page text.  Balabolka is a freeware TTS program that provides access to computer voices installed on Windows PCs.  Using the Microsoft Speech API, Balabolka enables alteration of a voice’s rate and pitch, among other properties.

The rate of Anna’s voice seemed fine to me, but I did lower its pitch.  Check out the results by playing the MP3 file embedded on the “Clear Helper” home page.  I will continue to try other voices and TTS tools as I find them.

Note: Once again, I did not set up closed captioning for the MP3 file because the entire text of it is right on the home page.  If anyone objects to this, please let me know why.  Thanks.

2 Community-Driven Projects to Independently Improve the Accessibility of Inaccessible Web Sites

I know of two projects intended to improve the accessibility of inaccessible Web sites.  A couple very intriguing qualities they have in common are that:

  • they depend upon the community to report accessibility problems, to fix them, and to share their fixes with the rest of the community;
  • their intention is that the accessibility problems can be fixed even if the inaccessible designs of Web sites do not change!

The projects are:

AccessMonkey, by The Department of Computer Science and Engineering at The University of Washington, and funded by a National Science Foundation Grant.

The way it works is that the community reports accessibility problems, AccessMonkey developers create scripts the community can use to ameliorate the problems, then the community shares them with others.  AccessMonkey is based upon GreaseMonkey, the widely-used Firefox extension that allows people to customize the way Web pages look and function.

Note: I am worried about the future of this project because I have not seen any recent activity on its Web site.

Social Accessibility Project, by IBM alphaWorks.

Focused on improving accessibility for users of screen readers (JAWS only at this time), it works in the following way.  Users report a Web site’s accessibility problems to the Social Accessibility server.  Volunteers respond by creating and publishing accessibility metadata. These metadata are attached to the original Web page so all users who visit the page benefit from it.  Users can also make accessibility improvements to a page by submitting landmarks to the server.  They are then made available to all screen reader users.

Note: You can sign in as a guest if you want to just explore this active utility.

On the “Clear Helper” Web site, I may be able to easily and usefully incorporate the community-reporting aspect of these two projects.  Perhaps I could set up a site feature that would enable people with cognitive disabilities to report problems they experience on popular Web sites.  Based upon that information, I could create tutorials on how to use particular features of them.

A Beginning for the Clear Helper Web Site

The “Clear Helper” Web site has its first page!  The home page has a decent look for a first attempt, and it experiments with a few accessibility elements.  However, its design is definitely not the one I am imagining for the site when it is available for use by people with cognitive disabilities.

HTML 5 & CSS 3

It took me eight hours to create the home page.  I spent much of the time learning enough HTML 5 and CSS 3.  I’m using those technologies primarily because they should work best with WAI ARIA, which defines a way for assistive-technology users to identify and to navigate visually-rich user interfaces.  Will I be using such interfaces or applets on the site?  I don’t know, but I want to be prepared for that possibility.

Voice Narration

One of the accessibility attributes the home page uses is a way for visitors to have its text read to them without needing to use a screen reader.  I created this feature with two tools.

I used Cognable’s speech demo to create a MP3 narration of the home page’s text.  I did this by:

  1. entering text for the MP3 title;
  2. copying and pasting the home page text;
  3. selecting the “Chilled US/Canadian Male” voice font;
  4. proving to the Captcha tool that I am human; and
  5. pressing the “Create MP3” button.

I then downloaded the created MP3 file for use on the home page.  Easy!

I embedded NCAM’s accessible MP3 player into the top, right of the home page.  I followed the simple instructions provided for the ccMP3Player.

The voice narration sounds okay, but it would be significantly improved by the use of a commercial voice font, I bet.  I did not set up closed captioning for the MP3 file because the entire text of it is right on the home page.

Immediate Next Steps

I will test the page using two tools:

  • WebAIM’s WAVE.  There are other Web accessibility evaluation tools, and I will use them.  Yet I am especially interested in WAVE because it will soon incorporate tests specifically for cognitive-disability accessibility attributes.  (More on this later.)
  • Juicy Studio’s Readability Test.  I plan to use this tool to analyze the home page text, then revise it until it reaches a reading level  likely to be understood by most people.  This experimentation, hopefully, will help train me to write explanatory text at an appropriate reading level.

I will be doing a lot more testing, experimentation and design revision.  All of it will be the subjects of future blog posts.

Reservations on the Usability of Automatic Captions

Lately in the mainstream press, there have been articles trumpeting that Google is adding automatic captions to YouTube videos. For examples, see:

Captioning For YouTube Is Not New

For at least a year now, Google has provided the public the capability of adding captions and subtitles to videos uploaded to YouTube.  This enables human-generated transcriptions to serve as the captioning.  What’s new, at least for YouTube, is that Google is now using speech recognition technology to convert the speech to text automatically; no transcription files have to be uploaded manually.

Automatic Captioning Is Not New

Unheralded by the mainstream press, last year The National Institute on Disability and Rehabilitation Research (NIDRR) funded a project that used IBM Research Labs technology to automate the closed captioning of video-based instruction.  It was intended to improve accessible distance learning for people with cognitive disabilities, The Deaf and the hard-of-hearing.


This feature developed in parallel by both companies appears to be a boon for the affected populations.  Unfortunately, speech recognition technology still has far to go to produce language understandable by most people, especially people with cognitive disabilities.

The YouTube automatic captioning is based upon Google Voice technology.  I am a user of Google Voice.  Its conversions of voice-mail messages to transcripts is so bad that I keep using it because it consistently gives me a good laugh.  Its speech recognition is quite poor.

At least, in concessions, Google “… promises that the technology will improve over time” and IBM advertises an “…over 90 percent accuracy”.  That seemingly short way to go, and the small remaining percentage of improvement, actually account for an amount of errors so significant that the transcriptions produced are difficult to comprehend.

The other feature Google announced is that it is giving people the option of using its automatic translation system to read the captions in any of 51 languages.

It was almost twenty years ago that I first researched and started following the effort to computerize the translation of written text from one language to another.  Despite its great strides forward since then, its Achilles’ heel has always been parsing context.  Here is a simple example.  If it is said that employees are green, Americans understand that to mean they are inexperienced.  Computers have always had difficulty determining context, so that a common automatic translation mistake is to misstate that as “the employees are the color green”.

Users of the current Google Translator service, which translates Web site text from one language to another, often tell me it provides an idea of the content being translated, but it has far to go to match human-translated content.


The promise of these automatic tools is that they will make it much easier to caption videos, thus promoting the widespread use of captioning.  Due to insufficient speech recognition, and the problem with context parsing, I predict that, for years to come, all the automatic addition of captions to YouTube videos will require human revision to make them understandable.  Once people realize this, I expect the use and the adoption of it will be low.

The good news is that Google has a strong financial incentive to get this right.  Its empire relies upon the association of advertisements with textual content.  The more accurate Google can make automatic captioning and translation, the more it will be able to monetize other content, such as video and audio, via their captioned text.

Accessible Video Players

On the future Clear Helper Web site, I plan to embed videos as an option for visitors to take tutorials.  At the time of this writing, I know of three accessible video players.  On the Clear Helper Web site, I may experiment with each to see which works the best.

  • ccPlayer, from the National Center for Accessible Media is the one I have been using for a couple of years on another Web site.  It was selected for use because of its accessibility features for screen readers and for keyboard users, for its closed-captioning feature, and for its ability to play well the site’s streaming-video files.
  • Easy YouTube, developed by Christian Heilmann, may be an option if Clear Helper’s videos are hosted on YouTube.  It has big buttons and clear video-size options.  Visitors with cognitive disabilities may find those controls easy to use.
  • Section 508 Video Player, was just released by Business.GOV, an official site of the U.S. Government.  Like Easy YouTube, The Section 508 Video Player is intended for use with YouTube videos.  One feature that may make it unique is that it “… plays a single video or a playlist, which is a group of videos within a single player.”

E-Mail Software for People with Cognitive Disabilities

CogLink is e-mail software designed for use by people with cognitive disabilities.  It comes with “automated” training and unlimited access to help-desk staff.  At the time of this writing, there is a one-time cost of $49; there are no continuing subscription fees.

CogLink was designed based in part upon a longitudinal study using participants with cognitive disabilities.  A separate Web site, Think and Link, details the related research.  It was conducted by The University of Oregon and was sponsored by The National Institute on Disability and Rehabilitation Research.

I look forward to reviewing the “automated” training, especially the video-based tutorials.  There is one about how to use a mouse, one on how to use a keyboard (not touch-typing) and one on how to use the CogLink e-mail software.  They were developed using instructional techniques of task analysis, errorless learning, chaining and practice repetition.  Perhaps I will be able to use these videos as models or as reference points when developing the video tutorials for the future Clear Helper Web site.

I have just purchased CogLink for evaluation.  A subsequent, related posting will follow.  No endorsement is intended or implied for CogLink.

Note: The Email Standards Project may be of interest to readers.  It “… works with email client developers and the design community to improve web standards support and accessibility in email.”  At the time of this writing, its Web site contains reviews of over a dozen e-mail clients.