Text-To-Speech Services: Choosing ROKTalk over BrowseAloud

This post briefly describes ROKTalk and BrowseAloud, and discusses why ROKTalk was chosen over BrowseAloud for an upcoming Web Site for people with cognitive disabilities.

That Web site will be a report for The Massachusetts Department of Developmental Services.  It will be published by The Eunice Kennedy Shriver Center, for which I work.  The project staff and I received good Webinar-based demonstrations from company representatives.  We saw BrowseAloud and ROKTalk in action on production Web sites.  We also paid careful attention to their usage instructions provided for the benefit of site visitors.


BrowseAloud and ROKTalk read Web pages aloud.  Web sites incorporate these text-to-speech (TTS) services for use by site visitors who find reading difficult.  Common reasons for this include intellectual disabilities, learning disabilities, mild visual impairment, and/or illiteracy.

Both services offer other features, such as increasing text-size, highlighting text as it is read, translation of text to other languages, and changing the background color.  These features can be activated from a floating toolbar, the appearance of which can be invoked by the site visitor.

An image of the BrowseAloud toolbar is displayed below.Browse Aloud toolbar has 7 multi-colored buttons in a horizontal strip.The ROKTalk Toolbar is pictured below.  The image is significantly smaller than the toolbar’s actual size.

ROK Talk toolbar has feature sections with icon-based buttons in each.


BrowseAloud requires Web site visitors to download and to install software.  For people who do so, an advantage is that BrowseAloud can be used for other purposes, such as word processing.  For Web developers, perhaps especially for inexperienced ones, an advantage is that no related scripting has to be incorporated into the Web site.

Neither of these advantages outweighed what the Shriver project staff and I believe to be the primary disadvantage.  Downloading and installing software would be too difficult for anticipated site visitors, some of whom are likely to have intellectual disabilities.  Likewise, we judged Browse Aloud’s usage instructions to be too complex.

For people who visit a Web site with ROKTalk, the TTS and other text-accessibility features can be used immediately.  No download and installation are required.  That said, it may be the toolbar itself is too complicated.  We may try a customized, less fully-featured version that presumably would be easier to use.


Cognitive Web Accessibility Assessments: 2 UK Sites With Top Scores

I performed cognitive Web accessibility assessments on five more sites.  Two of them, both of organizations located in the United Kingdom, received all possible points.  The results for the rest were varied.

Assessed Sites and Scores

View detailed results, assessment criteria and methodology.

Site Highlights

People First

The People First site features a large site-navigation menu (pictured below). For menu options, there are contextually-relevant icons, which are also used throughout the site.

People First Site Navigation Menu


The Mencap site incorporates many captioned videos (example pictured below) as an alternative to text content, and relevant images to augment it.  The site’s My Life section is specifically designed for constituents, with plain language; simple navigation, and lots of images and videos.

Man pictured with a quote, "We work in partnership with the  parents".


Though the Web sites of Mencap and People First have minor problems, it is apparent the two organizations expended great effort to make them accessible to their constituencies.  I offer my congratulations.

Note: This post is part of a series on cognitive Web accessibility assessments.

Draft Database of Results from Cognitive Web Accessibility Assessments

I now have a database of results from my assessments of cognitive Web accessibility.  It is a work in progress.

I am displaying the database data on The Clear Helper Web site.  Because, to date, I have assessed only 2 of my planned 100 Web sites, few data are presented.  Yet it seems a good idea to start the database development and the data presentation now, partly in hope of soliciting feedback from followers of this project.

The assessments home page references two pages that display the same database data differently.  Its main purpose is to describe the assessment criteria and methodology.  I will use it to record any related changes I make as a result of what I learn from performing subsequent assessments.

Via table and pie chart, the first page shows Results By Numbers of Web Sites that meet the assessment criteria.

The second page shows summaries of Results By Web Site.  Each has the criteria met, the number of points recorded, and the conclusion. Seven of the criteria are based upon the sections of WebAIM’s Cognitive Web Accessibility Checklist.

A future page will show results by the guidelines that form the checklist’s sections.  It might be interesting to create a page of results by country.  It may be, for example, that cognitive-disability organizations in the countries of the U.K. are more likely than those in other countries to make their Web sites accessible to their constituencies.

I would like feedback.  If you have suggestions for how I can improve my related efforts, or for other ways to display the results, please post a comment or contact me.

People with Intellectual Disabilities at the Boston Accessibility Unconference

The Boston Accessibility Unconference is Saturday, May 15, 2010, from 10 AM to 5 PM at the Adobe facility in Waltham, Massachusetts.  (Please join us!)

I invited a couple of people from the focus group that is assisting me with the Clear Helper project.  They may learn valuable information that would help them navigate the Web better than they can now.  While I hope that happens, I confess I have another hope.

I think it would be great if the Web accessibility community gains personal experience with people who have intellectual disabilities.  I have noticed the community, in general, lacks interest in cognitive Web accessibility.  I have multiple theories about the cause.  Among them is that developers have little exposure to people with cognitive disabilities, in particular folks with intellectual disabilities.

The people in the focus group are great self-advocates.  I don’t think they would be shy about telling people at the unconference how they find Web sites to be inaccessible.  Perhaps this would help motivate attending developers, for example, to produce Web sites more accessible to them.

Cognitive Web Accessibility Assessments: Lessons Learned So Far

This is a follow-up to my previous post that described my second structured assessment of cognitive Web accessibility.  The work’s progression can be seen via this blog’s Category of Cognitive Web Accessibility Assessments.

Assessment Scoring System Needed Revision

The result of the second structured assessment was that the Web site was inaccessible to people with developmental disabilities.  Had I followed my original assessment plan, the result would have been the opposite.  This is because of the plan’s scoring system.

I had intended to score one point if any Web site feature met even one guideline of each of the sections of WebAIM’s Cognitive Web Accessibility Checklist. While following this system during my second structured assessment, I realized it was too generous.  Points were adding up although it was obvious to me the site was likely inaccessible by people with developmental disabilities.

Consequently, I decided to average the number of guidelines that were met (successes) with those that were not (failures) for each checklist section.  Arbitrarily but within reason, I also decided an average success of 80% or higher would score one point.  I will apply this standard to future assessments unless I learn it is unworkable.

Assessments Require Significant Effort

When I developed my original assessment plan for 100 sites, I had been hoping the work could be performed quickly.  That was naive.  I now recognize much more work is needed.  Every relevant guideline in all of the checklist sections must be evaluated to portray a site’s cognitive Web accessibility as well as possible.  Indeed, because I evaluated all the relevant guidelines in the last (and only) structured assessments, comprehensive portrayals of the sites’ cognitive Web accessibility were produced.

Assessments Should Be Performed By Users

The cognitive accessibility of Web sites would be best assessed by users with cognitive disabilities.  I was reminded of this by Joe Chidzik after I posted my second structured assessment.  Specifically, his message was, “A site may be *likely* to cause accessibility issues, but to claim it does so without user testing isn’t helpful”.  Point taken.

Yet this assessment work, in part, is an attempt to find a uniform way for developers to help determine the cognitive accessibility of Web sites.  Of the many automated tools that help assess general Web accessibility, none are focused on cognitive Web accessibility.  WebAIM is pursuing funding to incorporate such assessment into its WAVE Web accessibility evaluation tool.  My work is an unofficial precursor to that.  I hope it will be helpful.

That said, I would like to include people with cognitive disabilities in this work.  Honestly though, I don’t know how to do it simply and economically.  (This project’s work is performed primarily on my own time and is unfunded.)  I am open to constructive suggestions.  Please post a comment with one.

Cognitive Web Accessibility Assessment, Second Attempt: Site Failure

This post is my second structured assessment of cognitive Web accessibility.  I describe how it is performed in my assessment plan.  It is less-detailed than my first assessment, but it again addresses every relevant guideline of WebAIM’s Cognitive Web Accessibility Checklist.

Web Site: National Association of Councils on Developmental Disabilities

home page of National Association of Councils on Developmental Disabilities


  • Consistency. One point is awarded.
    • Success
      • Navigation is consistent throughout the site.
      • Similar interface elements and similar interactions do produce predictably similar results.
  • Transformability. No point is awarded.
    • Success
      • Images are readable and comprehensible when enlarged (scaled to 200% and 300%).
      • Color alone is not used to convey content.
    • Failure
      • Increased text sizes (200% and 300%) are not supported by the navigation menu.
      • The disabling of styles is not supported.  On the home page, Latin (Lorem Ipsum) text appears, as well as non-contextually relevant links (“Sub-Link 1”, etc.).
  • Multi-Modality. No point is recorded.
    • Success
      • Icons of top menu are contextually-relevant.
    • Failure
      • No video- or audio alternatives are provided for textual content.
      • No images are used to convey or to enhance content.
  • Focus and Structure. One point is awarded.
    • Success
      • Distractions are avoided.
      • Stylistic differences are used conservatively to highlight important content.
      • Content is organized into well-defined groups.  Headings and lists are used.
      • White space is used for separation.
      • Background sounds are not used.
    • Failure
      • White space and visual design elements are not used to focus user attention.  Particularly because of the red background color of the menus, attention is instead focused on them.
  • Readability and Language. No point is recorded.
    • Success
      • There is no tangential-, extraneous-, or irrelevant information.
      • Grammar and spelling are correct.
      • Tables of contents are provided for complex or lengthy content.
      • Text-readability criteria are met.
    • Failure
      • Language is not as simple as is appropriate for the content.
      • The reading level is inadequate for the audience (assuming it is people with developmental disabilities).
      • Jargon is used.
      • Expansion of abbreviations and acronyms is inconsistently implemented.
      • Text is not succinct.
  • Orientation and Error Prevention/Recovery. No point is recorded.
    • One form was found.  It has only one field (password).  It fails assessment of the related checklist criteria.
  • Assistive Technology Compatibility. No point is recorded.
    • Success
      • A logical heading structure is used consistently.
      • The navigation order is essentially logical.
    • Failure
      • Use of alternative text is inconsistent.  There is none for the images of the text-size changer.
      • Form labels: the only field on the one form is missing a label.
      • Links do not make sense out of context.  There are multiple “Learn More” links on the home page.
      • Keyboard accessibility is problematic.  Navigation menus are not visible via keyboard navigation.
      • Descriptive and informative titles are missing from many pages.
  • The site attempts to meet W3C accessibility standards. One point is awarded.
  • There is no accessibility statement. No point is awarded.
  • There is no explanation about how to use accessibility features. No point is awarded.


Three of ten points possible are recorded.


The Web site of The National Association of Councils on Developmental Disabilities is inaccessible to people with developmental disabilities.

Upcoming Web Site to Include Accessibility for People with Cognitive Disabilities

I am working on a Web site that will incorporate two significant features with which I have experimented: text-to-speech (TTS) and plain language. The site will have other accessibility features for people with cognitive disabilities, text enlargement and text highlighting among them.

The site will be a report for The Massachusetts Department of Developmental Services (DDS).  It will be published by The Eunice Kennedy Shriver Center, for which I work.  Because the constituency of The DDS is people with intellectual disabilities, Shriver project staff would like the report to be as accessible to them as can be afforded at this point.  I have thus been in discussions with representatives of Web-accessibility technology companies.

Web Accessibility Technologies

An accessible content management system (CMS) from WebCredible has been purchased for the Web site. WebCredible reports that, in addition to its purpose of creating accessible Web pages, the CMS includes two other features, ones that attracted me to it.

  • Its back-end, content-management interface is itself accessible; and
  • “… content editors are forced to … produce accessible and well-written page content …”.

I will begin using the WebCredible CMS next week.  Future blog posts will describe what I learn about it.

The Shriver project staff and I are considering two other products from The United Kingdom: BrowseAloud and ROKTalk.  Each provides TTS and text-accessibility features for Web sites. I have mentioned both products in previous blog posts, and reviewed the one from ROKTalk.  A future post will describe which we choose, and why.

Plain Language

The report to be published is long and contains complex information.  For the home page of each section, we plan to write a plain-language version of the section’s main points.  I am concerned about doing this well because, as I have said before, writing “easy” text is not so easy.  Our related efforts will also be the subject of future blog posts.

Note: No endorsement of the above-mentioned products is expressed or implied.

50 Web Accessibility Blogs

On The Clear Helper Web Site, I published a list of

Web Accessibility Blogs.

At the time of this writing, there are fifty.  More will be added to the list as I find them.

Selection Criteria

  • Each is either a blog that focuses on Web accessibility, or is the blog’s Web-accessibility category.
  • All are active; they have articles published this year (2010).
  • All in the list, at least as of now, are written in English.


Every listing has a link to the blog’s home page and is annotated with an edited quote from a top-level page.

I have started a list of cognitive Web-accessibility blogs.

Suggestions Desired

I would like to include blogs written in other languages.  If you have a suggestion, please comment or contact me.

Note: No endorsement of the blogs is expressed or implied.

Sources of Research Articles on Cognitive Web Accessibility

On The Clear Helper Web Site, I published my

Sources of Research Articles about Web Accessibility for People with Cognitive Disabilities.

Most are vertical search engines of research from related fields.

Each listing is annotated with an edited quote describing the source.  At the top of the page, I note the approximately twenty search terms I used.  The following blog posts are about the results of this effort.

Since I published the above, I have significantly increased the number of articles for each list.