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.
I tried to write instructions in simple language. E.g., I used “big” instead of “larger” and “make big text” rather than “enlarge text”.
There are dozens of Web browsers. Creating screen-shot based instructions for all of them is impractical.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
“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.
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.
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.
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.”
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.
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.