Category: About Project

Browser-Based Text/Font Size Switching

~ John Rochford

On the Clear Helper Web site, I have implemented a text-resizing approach suggested by Jared Smith, of WebAIM.  It relies upon visitors to follow instructions about using their Web browsers to change the Web site’s text size.

Background

In a previous post entitled “Web Site Font Sizes & Switching for People with Cognitive Disabilities“, I proposed adding to the Clear Helper Web site a font size switcher that looks like this image.

line of 5 letter 'A's in ascending order of size

In a response to that post, Jared Smith discussed several reasons why such a widget should not be used.  He said Web site visitors should use their Web browsers instead.  He suggested the approach of SSA.gov.  At the top of its pages, on the left, there is a link entitled “Need Larger Text?”  Clicking it produces a page with text-based instructions on using the keyboard to enlarge text.  On that page is also a link to a W3C page with related text- and picture based instructions for four Web browsers.

My Implementation of an Approach Similar to SSA.gov’s

At the top of the Clear Helper Web site pages, on the left, there is now a link entitled “Need big text?”.  Clicking it produces a page with text- and image- based instructions on how to use the keyboard to enlarge text.  From that page, another page can be reached that has screen shots to explain how to use Internet Explorer menus to enlarge text or how to use Firefox menus to enlarge text.

My next post will describe problems with this approach, and what I have done to solve them, or at least to ameliorate them.

No Accessibility Benefit To Google Analytics Asynchronous Tracking

~ John Rochford ~ 1 Comment

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.

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.

WebAIM WAVE Evaluation: Success For Now

~ John Rochford

I ran the WebAIM WAVE Web accessibility evaluation tool against the “Clear Helper” home page. It detected no accessibility errors.

View the WAVE report about the “Clear Helper” home page.

WAVE has many useful features.  Unlike any other such tool I have used, it provides a visual layout of a Web page with embedded icon indicators.  Red ones are for accessibility errors; yellow ones are alerts for possible issues, green ones are for accessibility features, and light blue ones are for elements that may aid accessibility.

Ordinarily, when using WAVE, I prefer its Toolbar version.  The following descriptions are for the Web-based version of WAVE, which people use for a quick check to determine if a site has made an attempt to be accessible.

Near the top, right of the WAVE report is a button to disable/enable styles.  This is useful to show how readable the page is should a user decide to disable page styling.

Across the top of the report, there are tabs for ancillary reports showing the Web page’s:

  • Structure/Order, which indicates the order in which the content will be read as a person tabs through it.
  • Text-only, which shows the page without images or styling.
  • Outline, which displays content headings and their order.

Use of WAVE is a good start for determining a Web site’s accessibility.  Other such tools, commercial and free, and many of which I have used on other sites, attempt to check against sets of standards such as 508, WCAG 1, and WCAG 2.  Ultimately though, true accessibility can be determined only with testing by people with disabilities.

Note: When the “Clear Helper” Web site is available for public use, I expect its design will be much different.  Yet, because this is my first foray into using HTML 5 and CSS 3, I wanted an indication I am using those technologies accessibly.  I will continue to perform accessibility checks as I experiment.

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.

Experimenting with Landmark Roles on the Clear Helper Home Page

~ John Rochford

Today, I experimented with placing WAI-ARAI landmark roles into the “Clear Helper” home page.   For users of screen readers, landmarks provide a method to identify standard content sections of Web pages in a consistent way.

I followed the instructions on “Using WAI ARIA Landmark Roles” by Steve Faulkner of  The Paciello Group Blog.  I inserted the following landmark roles: banner, navigation (not currently in use), main, complementary and contentinfo.  Per Mr. Faulkner’s suggestion, I viewed the results using The Juicy Studio Accessibility Toolbar document landmarks feature.  All went well.  The Juicy Studio tool redisplayed the page, showing borders around each delineated landmark section.

Among other uses, landmarks are intended to replace “skip-to-content” links now found on many accessible Web sites.  Even so, I intend to use such links on the “Clear Helper” Web site, essentially for two reasons.  One is that people who access Web sites via a keyboard, and who are not screen reader users, find such links to be useful.  The other is that though JAWS (as of version 10), the most popular screen reader, supports landmarks, their adoption and use by the community has been slow.  Results from a recent survey of screen reader users indicated that “42% of respondents did not know that ARIA landmark functionality even exists”.

Smith, J. (2009-10-29). Screen Reader User Survey Results. WebAIM Blog. Retrieved from http://webaim.org/blog/screen-reader-user-survey-results/

Do landmarks assist people with cognitive disabilities?  I am sure they could for those who also have a visual disability.  An important point to keep in mind about the design of the future “Clear Helper” Web site is that, yes, I will be using best practices of accessibility for people with cognitive disabilities; but I also will be adhering to the latest general accessibility standards (WCAG 2.0).

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

~ John Rochford

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.

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.