About the Tests
These test results present the spoken output from JAWS, version 8.0, and Window-Eyes, version 6.1, when reading the 252 character references specified in HTML 4.01. Though JAWS 9.0 was not tested, Iâm assuming, based on correspondence with Freedom Scientific, that its results would be identical with those of JAWS 8.0.
Each screen reader was tested with default settings using Internet Explorer 6 and 7, as well as Firefox 2, on WinXP Pro. It turns out that, except for in a few cases with Window-Eyes, the output from each screen reader is consistent across all three browsers. The spoken output is also identical for both character entity references and their decimal numeric equivalents.
The tests were performed on an HTML table that included one column for the character entity references, and one for the numeric character references, with each character reference in its own cell. The tableâs rows and cells were navigated using the screen readersâ regular keyboard commands to direct the cursor.
The spoken output was noted for each character reference, both in normal reading mode, as the cursor entered the containing cell and tried to speak its contents, and in letter by letter mode as the cursor was moved over the distinct character reference within the cell. With Window-Eyes, the spoken output upon hovering the mouse pointer over the character reference was also noted, though in all cases this output was the same as what Window-Eyes spoke in letter by letter mode.
Update: Almost two years later, I performed a quick check with JAWS 11, and things donât seem to have improved much, if at all, at least with JAWS. For example, out of the box, JAWS 11 still wonât speak the minus sign (− or −), still reads the greater-than or equal to sign (≥ or ≥) as âequalsâ, and still reads the square root symbol (√ or √) as âvâ.
How hard can it be to match these simple character references with somewhat reasonable spoken output? I guess it remains up to users to modify their own pronunciation dictionariesâŠ
Guide to the Results
How the Results Are Organized
For each screen reader, there are three sets of results. The first presents how the specific reader speaks or doesnât speak each of the 252 HTML character references. The second lists just those character references not spoken in normal reading mode.
The third set of results includes my suggestions for improvements to the default spoken output in normal reading mode for specific character references. These suggestions, some of which, Iâm sure, could themselves be improved, are contained in the âPreferred Outputâ column. As Window-Eyes speaks almost none of the character references in normal reading mode, the âPreferred Default Window-Eyes Outputâ tables include entries for almost all of them, whether or not Window-Eyes happens to speak them in letter by letter mode. And where its output solely in letter by letter mode doesnât seem quite right, a preferred output has also been recommended. For more on these ways of reading, go to âHow JAWS and Window-Eyes Read Textâ.
There is also a comparison table that combines the results from both screen readers.
JAWS says the same thing in both normal reading and letter by letter modes, and so its test results include only one column for the spoken output. The result tables for Window-Eyes include two columns for the spoken output. The âOutput Reading Normally/On Hoverâ column presents what Window-Eyes speaks when it comes to a distinct character reference in the normal flow of reading a line or sequence of text, or when the mouse pointer hovers over it. The âOutput Reading Letter by Letterâ column presents what is spoken when the cursor is moved over the individual reference as a distinct character, or when Window-Eyes spells out the letters in a word or phrase containing the character reference.
How the Screen Reader Output Is Presented
Where the screen reader does not speak anything for a particular character reference, the output is noted as being âNOT SPOKENâ. Where references to space characters like are concerned, this obviously makes sense. It is curious to note that, in letter by letter mode, Window-Eyes says the word âquestionâ for a good number of the character references it otherwise does not support, whereas JAWS simply remains silent.
In some cases, where the screen reader does speak a character reference, Iâve attempted to write the output somewhat phonetically in order that the relevant reader pronounce this text version of the output properly, that is, in the same way as when it reads the actual character reference in a page. For instance, both JAWS and Window-Eyes tend to pronounce the first letter of the alphabet in its short vowel form, that is, as âuhâ. To reproduce its long vowel pronunciation where needed, and because of some minor differences in how the two readers speak certain vowel combinations, it is written as âayâ for JAWS, and as âaiâ for Window-Eyes.
How JAWS and Window-Eyes Read Text
Normal Reading Mode
JAWS and Window-Eyes will speak full words, sentences and the like as they come across them. That is, as keyboard commands direct the cursor to a new line or sequence of text such as in a paragraph, list item or table cell, the screen reader will attempt to speak the text it contains. This is referred to here as the screen readerâs normal reading mode.
Do note that when being used for their grammatical purpose, certain punctuation characters such as apostrophes and some quotation marks tend not to be spoken in normal reading mode. Such character references will only be spoken in normal reading mode, at least by JAWS, when they are found on their own, that is separate from their active use as punctuation. For example, the phrase, âIâm testing âscreen readersâ,â will be read as, âIâm testing screen readers,â and neither the apostrophe nor the opening and closing single quotes will be spoken. On the other hand, the phrase, âplease use the â character,â will be spoken, at least by JAWS, as, âplease use the apostrophe character,â because the apostrophe in this case is a standalone character not punctuating anything.
At default settings, Window-Eyes in Internet Explorer will also read a single line of text when it is hovered over with the mouse pointer. In Firefox, Window-Eyes seems to only read individual words that are moused over. Jaws does not work this way with the mouse pointer.
Reading Letter by Letter
Using other keyboard commands, both Window-Eyes and JAWS can also be made to spell out a word or read text letter by letter, speaking each individually as the cursor moves past it as a distinct character. The text sequence, âIâm hereâ, will be spoken, moving letter by letter, as âI apostrophe m space h e r e.â
It should be noted that Window-Eyes, for the most part, only speaks character references when reading letter by letter, that is, when the cursor is moved past the specific character reference individually. It otherwise speaks almost no character references when it is reading words, sentences, or lines of text, or when the mouse pointer hovers over them. JAWS speaks the same thing in this letter by letter mode as it does when it meets a character reference in its normal reading mode.
Background
The Issue
At their default settings, JAWS and Window-Eyes offer little support when reading some very basic characters. In this case, at issue are HTML character entity and numeric references like − (the minus sign) or ≥ (the greater than or equal to sign). For instance, using character references, a mathematical statement like âxâyâ„zâ (that is, x minus y is greater than or equal to z) will be pronounced by JAWS as âx y equals z,â and by Window-Eyes as âx y z.â
Window-Eyes speaks hardly any character references in the normal course of reading words, sentences, or lines of text, whereas JAWS speaks a good many of them. On the other hand, when spelling out the particular characters in a sequence of text, Window-Eyes speaks some character references that JAWS does not.
This level of screen reader support for character references has been addressed before, and at least one interesting and helpful study has previously been made.
Intermediary Solutions Arenât the Point
It is not impossible to make mathematical statements, for example, accessible through screen readers. JAWS with Internet Explorer and the MathPlayer plug-in will read math equations and the like when they are marked up with MathML. But MathML, while not the most complicated thing, seems overkill for most situations where web authors might wish to include some basic math characters in their HTML.
One can also use Firefox with the Fire Vox screen reader plug-in to read MathML. However, if one normally uses JAWS or Window-Eyes for all or most of her screen reading needs, having to run yet another screen reader, and possibly a different browser than usual, just to hear a few equations seems a hassle at the least.
If a web author wishes to make the meaning of some unsupported character references, mathematical or otherwise, accessible to screen readers, several intermediary options are obviously available. These include writing full words and phrases instead of using the appropriate characters; replacing character references with images that have proper text equivalents in their alt attributes; and wrapping a sequence of character references in its own HTML element with a reader-friendly title attribute. I donât mean to suggest that such techniques should not be used as part of an attempt to overcome the current situation. However, each of them has its drawbacks, and ultimately seems a rather forced accommodation, considering that the character references are all just there, Unicode- and W3C-approved for some time now, just waiting to be mapped to some useful speech output. It is just that, while such intermediary solutions may exist, I would suggest that they shouldnât need to.
Still, a web author could also provide instructions to the user on how to modify her readerâs dictionary so that character references are spoken as desired. Certainly, users are responsible for learning and knowing their software tools, and both JAWS and Window-Eyes have editable pronunciation dictionaries. Nevertheless, it hardly seems excessive to request that JAWS and Window-Eyes, at their default settings, be able to read character references like − or &8805;. Indeed, one might fairly expect them to support all 252 character references. Or, if not all of them, maybe just some of the standard mathematical symbols, or a few of the common Greek characters.
Petitioning the Software Makers
Perhaps with a more comprehensive understanding of how JAWS and Window-Eyes speak character entity references and their numeric equivalents, one might be better positioned to petition Freedom Scientific and GW Micro, the software makers, to improve the current support for character references that their products offer out of the box. This, along with developing a greater familiarity with screen readers, was the reasoning behind the tests whose results are presented here.
About the Tester
My name is Jason Kiss. I am not an active screen reader user, so I would be grateful for any comments or suggestions on how to improve the tests or results presented here. I would especially appreciate help when it comes to what Iâve suggested as improvements to the screen readersâ default output. Please feel free to email me.