Month: December 2009

Browser-Based Text/Font Size Switching: Dissatisfaction & Solutions

~ John Rochford

I am dissatisfied with some aspects of the approach that relies upon Web site visitors to use their Web browsers to change the size of Web site text.  I have attempted to solve the problems I perceive with this approach.  This post is a follow-up to my previous post entitled “Browser-Based Text/Font Size Switching”.

Reasons for Dissatisfaction with This Approach & Attempted Solutions

  • I think asking people to invoke a combined-key command with which they are unfamiliar, and with keys they do not use much, is confusing.
  • There are dozens of Web browsers.  Creating screen-shot based instructions for all of them is impractical.
    • I implemented a JavaScript application that displays a link to screen-shot based instructions only if visitors are using either Internet Explorer 8.x or Firefox 3.x.  If they are using another Web browser (or if they have JavaScript disabled) the page displays an instruction to refer to their Web browser’s help menu.
  • I created screen-shot instructions for Firefox 3.x and screen-shot instructions for Internet Explorer 8.x.  Their menus for adjusting text size are markedly different from those of their previous versions.  Many people do not use the latest versions.  Asking them to decide which to use of multiple sets of instructions, one for each previous Web browser version, would be very confusing.  Many people do not know what a Web browser is, let alone which version of it they are using.
    • The JavaScript application checks the visitor’s Web browser version.  If it is Firefox 3.x (the latest version), the page displays a link to screen-shot instructions for it.  I did the same for Internet Explorer 8.x (the latest version). If visitors are using an older version of either browser, the page displays textual instructions telling them how to use the old-style menus.
  • The screen shots for Internet Explorer are especially high/long.  It does not become apparent which menu to use until the visitor scrolls down the image(s).  This will likely be confounding.
    • I have no practical solutions for this.  Reducing the size of the images reduces their text size.  People who need to enlarge text size would not appreciate that.

I will consider how to improve this approach, or scrap it for something better.  As always, I am open to suggestions.

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.

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

~ John Rochford

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

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

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.