Tag: Web Usability

Accessible Rich Media Players & TTS for Web Sites

~ John Rochford ~ 1 Comment

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

~ John Rochford

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.

Web Site Font Sizes & Switching for People with Cognitive Disabilities

~ John Rochford ~ 1 Comment

A common recommendation for designing Web sites for people with cognitive disabilities is to use large fonts and/or to enable the enlargement of them.  See WebAIM: Cognitive Web Accessibility Checklist and Inclusive New Media Design: Top Tips.

Though Web browsers enable resizing of a Web site’s default font, it is widely accepted by the community of Web accessibility professionals that most people do not know the feature exists.  This is the primary rationale for the placement of font-size switchers on Web sites.

For several years, I have incorporated a font-size switcher into the Web sites I have designed.  An example is in use on the Web site of the Massachusetts Disability Information Locator (MADIL).  It is located on the right side of the site’s pages, just under the site-navigation tabs.  It has five font-size selectors, including one that changes the page background color to black.

I will soon experiment with adding this font-size switcher to the “Clear Helper” home page.  In the interest of reducing the number of distractions, also a Web-accessibility recommendation for people with cognitive disabilities, I may limit the number of its selectors to three.  One will reduce the font to the same size as the default font of the visitor’s Web browser; one will make the font even larger than the site’s standard (large) font; and one will set/restore the font size to the site’s standard.  The way this works should become more clear once the font-size switcher is in action.

Note: There are two disadvantages to the font-size switcher.  One is that it uses JavaScript.  Thus it will not work for those people who disable JavaScript in their Web browsers.  The other is that it uses a cookie to store and use the visitor’s font-size selection across all of the site’s pages.  So, the font-size switcher will not work for those people who have prevented the use of cookies by their Web browsers.  If anyone knows of a font-size switcher without these limitations, please let me know.

INMD: Summary of Final Report on Web Accessibility for People with ID

~ John Rochford

In October, 2009, Inclusive New Media Design (INMD) published its final report on including people with intellectual disabilities (ID) in the World Wide Web.

It describes INMD’s effort to identify the best ways of encouraging Web designers to build Web sites accessible to people with intellectual disabilities.  It also examined the effectiveness of the Web Content Accessibility Guidelines (WCAG) to achieve such inclusion, and identified the factors that influence Web designers to embrace accessibility efforts.

Training & Actions Taken

INMD ran accessibility training workshops with Web designers and people with intellectual disabilities. It collected data about the work and the accessibility practices of Web designers.

As a result, participants took or planned action related to ID inclusion, and shared their knowledge with others. Action taken included:

  • “adapting use of imagery to support text;
  • using large fonts and simple text;
  • re-checking previous work for ID accessibility;
  • passing on information at work, or through blogs.”

Adaptations According to Disability Level

INMD’s success in contributing to inclusion was primarily for people at the mild end of the ID spectrum. While participants acknowledged that related adaptations could be beneficial to all people, they also recognized that adaptations for people with severe- or profound intellectual disabilities may be intrusive to non-disabled, Web site visitors.  Thus participants indicated they would be less likely to accommodate that segment of the population in their future work.

Barriers To Accessibility

Participants saw the WCAG as too complex to understand and to implement, though they did acknowledge their value.  They feared too much attention may be paid to meeting the guidelines rather than focusing on true accessibility.

Participants identified barriers to accessibility for people with ID and for other people with disabilities:

  • “the attitudes of decision-makers, who may not share participants’ commitment to an accessible web;
  • the nature of the projects they work on;
  • an absence of understanding of the accessibility needs of ID audiences;
  • an absence of guidance about how to address these needs, for example within the WCAG guidelines.”

Potential Accessibility-Barrier Solutions

The impairment diversity of people with ID, and their related accessibility requirements and assistive technologies, account for such absences, as does the paucity of expertise about ID among the WCAG working groups. This caused the INMD to conclude that:

  • “WCAG guidance needs to be exceeded to address ID accessibility needs
  • Information about how to do this, and on ID accessibility, needs to be made widely available, for example through the development of an online resource.
  • Key decision-makers in the web design process  –  clients, line managers, copy writers, editors – play an important role in ensuring maximum accessibility.
  • In order to achieve inclusive new media design and ID accessibility, it  is necessary to engage with these stakeholders of web design in future action research.”

Recommendations on encouraging ID-accessible design included:

  1. “Develop an online resource about  ID accessibility: including  tips, how-to videos, examples of good practice and of user interaction; information about how to exceed WCAG guidelines; and the facility to build a community of web professionals committed to ID accessibility.
  2. Engage with intellectually disabled web users: most participants cited user testing as the most beneficial aspect of our workshops. User testing put a human face on the issues discussed with participants, and addressed their lack of understanding about ID audiences and their accessibility needs.
  3. Engage a diverse range of stakeholders:  decision-makers affect accessibility practice. Further research needs to engage with a more diverse range of stakeholders – line managers, copy writers, policy makers – in order to make ID accessibility happen.
  4. Develop research with people at the severe/profound end of the ID spectrum: people at the severe or profound end of the ID spectrum are more likely to be left out of the web, because accessibility measures which address their needs are more intrusive to non-disabled audiences than measures which address mild ID, or sensory or physical impairment. Therefore further action research is needed to attempt to achieve their digital inclusion.”

View the INMD final report (PDF).

Using TTS & Microsoft SAPI on Clear Helper Home Page

~ John Rochford

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.

Juicy Studio Readability Test: Contradictory Results

~ John Rochford

For the current text of the “Clear Helper” Web site home page, I conducted the Juicy Studio Readability Test.  Results from the readability test’s automatic calculation were significantly different from those derived from my manual calculation.  I don’t know how to account for this.  It makes me distrust the test.

Automatic Summary Results

I submitted the URL of the Clear Helper home page.  A summary of reading level results was produced.

Total sentences 59
Total words 370
Average words per Sentence 6.27
Words with 1 Syllable 211
Words with 2 Syllables 66
Words with 3 Syllables 47
Words with 4 or more Syllables 46
Percentage of word with three or more syllables 25.14%
Average Syllables per Word 1.81
Gunning Fog Index 12.56
Flesch Reading Ease 47.73
Flesch-Kincaid Grade 8.16

Note the last three results.  They indicate that someone with almost 13 years of education or someone in the eighth grade could understand the current text of the Clear Helper home page.  The Flesch Reading Ease scorer of 47.73 falls below the ideal of 60 – 70.

These scores and their indications are worse than those I determined by following Juicy Studio’s instructions on how to calculate the scores manually.

Gunning-Fog Index: Manual Calculations

  • This test “… is a rough measure of how many years of schooling it would take someone to understand the content.”
    • To calculate this score, as instructed, I added the average number of words per sentence (6.27) to the number of words with three or more syllables (93) and multiplied the total by .04. Score = 4.
      • This indicates a fourth-grader would be able to understand the home page text.
        • Note: I think there is an error in Juicy Studio’s instructions.  It first says to use the percentage of 3-syllable words but, in the formula, indicates the number of 3-syllable words should be used.  Calculating the formula with the percentage produced a score of 1.  Because it seemed quite unreasonable that a first-grader could read the home page text, I instead calculated the formula using the number of 3-syllable words.

Flesch Reading Ease: Manual Calculations

  • For this test, “… the higher the score, the easier it is to understand the document.” The ideal score is 60 to 70.
    • To calculate this score, as instructed, I subtracted the sum (153.126) of 84.6 multiplied by the average number of syllables per word (1.81) from the sum (6.36405) of 1.015 multiplied by the average number of words per sentence (6.27). Result = -146. 76195. I then subtracted this result from 206.835 to achieve a score of 60.
      • The score of 60 falls within the ideal range.
        • Note: In calculating the score, I had to change the negative result number (-146. 76195) to a positive number.  It was the only way to produce a reasonable result.

Flesch-Kincaid Grade Level: Manual Calculations

  • This test “… is a rough measure of how many years of schooling it would take someone to understand the content.”
    • To calculate this score, as instructed, I multiplied the average number of words per sentence (6.27) by 0.39 and added its sum (0.24453) to the sum (21.358) of the average number of syllables per word (1.81) multiplied by 11.8. Result = 21.60253. I then subtracted 15.50 from the result. Score = 6.
      • This indicates the home page text requires a sixth-grade education to understand.

Conclusions & Speculation

The results from the manual calculations indicate someone with a fourth- to sixth grade education should understand the home page text, and that its readability falls within the ideal scale.  This is significantly better than the results and the indications of the readability test’s automatic calculations.

I wonder if the different results are due to the consequence of following contradictory- and confusing instructions about how to perform the manual calculations.  Perhaps the errors are mine.

I will have to revisit this at a later date.

A Beginning for the Clear Helper Web Site

~ John Rochford

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

~ John Rochford

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.

Reservations

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.

Predictions

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.

3 Tools to Measure Usability of Navigation Icons

~ John Rochford

One possible way to evaluate the usability of navigation icons may be to determine the amount of interaction Web site visitors have with them.  Common sense says that the higher the click rate, the greater the indication that visitors are attending to them.  Of course measuring click rate would not indicate that visitors were understanding the intended purpose of the navigation icons, but use of them would presumably mitigate that.  The reason is that the more often a visitor uses a navigation icon, the more opportunities there would be for the visitor to learn its purpose.

At the time of this writing, I know of three tools that could provide an accurate measure for the click rate of navigation icons.  Each is marketed as an evaluator of Web site usability.

They are CrazyEgg, ClickTale and Google Web Site Optimizer.  These tools essentially work the same way.  On a test Web page, a “heat map” is set up that tracks where on the page a visitor clicks.  Clicks to navigation icons embedded in such a page can be tracked.  A high percentage of clicks to a navigation icon or icons, compared to the percentage of clicks to other elements of a test page, would indicate that visitors are attending to them.

I plan to use the Google Web Site Optimizer because it appears it will meet my intended purpose, it is free, and it is simple to set up.  Future blog posts will describe the set up process and the related test results.

A drawback to all of the these tools, I believe, is that they use JavaScript in their implementation.  Some people with disabilities do not use JavaScript-enabled Web browsers, or disable JavaScript in the Web browsers they use.  For these folks, click-rate measuring won’t work.

Note: No endorsement is intended or implied for the tools listed above.

Proposed Back & Next Navigation Icons For Future Clear Helper Web Site

~ John Rochford

I plan to use a consistent set of navigation icons for the future Clear Helper Web site.  My first attempt is represented by the “BACK” and the “NEXT” icons below.  Others in the set will follow.

The development of them is not derived from research, which is beyond the scope of the project at this point.  However, they were created following WebAIM’s “Creating Accessible Images” guidelines.  In particular, they: are not animated; don’t use color alone to convey meaning; look okay even when enlarged to 500%; and use good color contrast between the text and the background.

Of these guidelines, the last can be objectively measured with the following tools.  Each is based upon the latest Web Content Accessibility Guidelines (WCAG 2.0).

Accessibility Color Wheel created by Giacomo Mazzocato.  This tool is used to choose a color pair, especially of foreground- and background colors, that is accessible to people with any of three color-blindness conditions. This tool rated the color contrast of the icons below as “13:1 ok”.

Luminosity Colour Contrast Ratio Analyser from Juicy Studio.  This tool also rates color contrast.  It reported the ratio as “12.96:1 … very good … ” and passing at WCAG 2.0 Level AAA, which is the highest standard.

I would appreciate any constructive feedback about these icons.  They are being shown at the size I plan to use on the Web site.

Back

Next