Testing using a Screen Reader


I guess I will not be original if I say that the tester’s work I like for what ever faced with something new. And, sometimes, not just new, but rather unusual. And today, I would like to talk about these "unusual".

A few months ago, on my test site got a very well-known charitable organization. At first, nothing foreshadowed trouble … This site as a site – a lot of PHP and MySQL, a handful of images and HTML. In general, as usual, if … if the organization was not charitable, and one of her priorities would not be to help people with visual impairments. Naturally, in this case is not the last item in the test plan was testing the site with screen readers. Initially, the item I did not care. But it lasted exactly as long as it did not come directly up to the test.

What is a screen reader?

Screen readers – software designed to interpret everything that happens on the screen in a voice message (using the so-called, text-to-speech engines), or in Braille (Braille), that can be put into a special Braille display. But do not think that the work of articulating the text screen reader ends. They are very closely interact with the OS in general and with some programs such as allowing the content to represent it in the form in which it will be as clear to the user, guided only by sound, not visual presentation. This is achieved by transforming a block of information in line. In practice, this means that the beloved Google.

In addition to the transformation of the content, screen readers are accustomed us to change and navigation (eg, the order of the transition on the links by pressing Tab), as well as allow you to perform certain actions (basically those that sighted people perform with the mouse) using the hot keys.

If we talk about the technical side of the issue, the interaction with the browser is a software interface WAI-ARIA, and which allows to parse HTML, JS etc. converting them to a form that can be processed by screen readers. At the moment, this interface supports IE, FF, Safari and Opera. However, with Opera as usual – it does not support screen readers

The most popular screen readers are Window-Eyes and JAWS. They work only on Windows, respectively, and test you have to exclusively under Win. Their value can hardly be called encouraging, but the good (albeit dubious) both have a screen reader demo mode through which they can be "slightly popolzovavshis" for free.

Those who want a more detailed understanding of the principles of screen readers may refer to the article Designing for Screen Reader Compatibility.

And we try to understand …

  • And what’s the problem?
    Indeed, what is? Like, it is clear that a screen reader somewhat differently is familiar to us interface. It seems to be clear that he has a kind of control. But …
  1. … you are seeing. That’s why you will be very difficult to catch all the subtleties of using a screen reader.
  2. … Each person uses a screen reader in different ways. That’s why you will not find a universal recipe that will help make the interface comfortable for all.
  3. … You, like any other, an experienced computer user, you read the manual to the program only after a "step on a rake." That’s why you have a lot of problems in the first stage of testing.

These problems, in my opinion, are more philosophical, and therefore give clear guidance in the spirit of "go there, click here check it out …" is silly. But to give some recommendations (their own and others) that will help you solve these problems alone, I think it quite possible.

So …

As briefly become blind?

  1. First of all, learn to use a screen reader. No, you should not just learn how to open the page and listen to his monotone mumble, and learn to surf on the internet focusing only on the voice message program. Believe me, this skill does not prove superfluous in the testing process.
  2. "People in the topic" recommends an evening or two of surfing the Internet with a disabled monitor and mouse.
  3. Do not use the mouse during the test, otherwise you may miss potential problems with your application. Always remember that people with low vision will not use a mouse, and will not try to get it on "out of the link in the upper right corner. They did not know that there is a link, until then, until she gets into the focus screen reader.
  4. If you have any doubt about whether voiced by one or another part of the interface, then simply turn the monitor off or close your eyes and try to take advantage of the "suspicious" fichey relying only on your ears.
  5. Before starting the tests will not be superfluous, to get acquainted with the fact that in general, screen readers are able to use the ARIA-interface. This can help you set the test cases for the WAI-ARIA.
  6. During testing, move around the page in all possible ways: on the links, headings, paragraphs, controls, etc. It was so moved by page blind, they seldom read the whole page.
  7. If you have a text version of the site (with a minimum of markup and JS), then watch carefully to all the extra markup has been removed because screen readers can "see" a little bit more than you. For example, JAWS gladly seeks out on any page display: none of what you are immediately reported.
  8. Be suspicious of any kind to AJAX’am. "Sweet Couple" FF + JAWS really "loves" dynamically loaded elements sometimes continuing to articulate the text, which no longer exists on the screen.
  9. Test in IE, and FF. The difference between them can be very substantial. As for different versions of IE, then any differences between IE6 and IE7 I have not noticed, but in IE8, in my opinion, Pages sounded a little more adequately.

I hope that these few uncomplicated tips to help you during testing. Well, finally, the most important thing – …

How not to go crazy?

If you do not understand why you can go crazy testing using a screen reader, it means only one thing – you’ve never used such software. In order to understand what I mean, try to listen to a few minutes of "Uncle Sam", who lives at Control Panel – Speech. I think that the questions will disappear by themselves. Of course, Microsoft Sam – exaggerated version, but even allowing for a more pleasant and appropriate pronunciation of the normal screen reader, listen to stories in the computer for eight hours straight is very difficult. In connection with this (and more), I can recommend:

  1. Immediately set a nice tone of voice computer "buddy".
  2. Customize adequate reading speed at which you will not fall asleep, but also be able to catch all the words uttered reader.
  3. Purchase a license for a screen reader (or insist on its purchase), unless you’re a masochist and you do not have big fun PC reboot every 40 minutes.
  4. When you purchase a license, immediately decide how you will work with a screen reader and how many PCs. For example, JAWS requires activation for each PC, as well as an additional license to work on RDP. (By the way, JAWS works fine on a virtual machine, even on the test VM to Virtual PC from Microsoft. IMHO, this is the best option when working with the demo version)
  5. Before you begin, be sure to look through manuals and HELP. Better yet, read them carefully before installing, for the first time guess why JAWS’u (hell, again JAWS) 3 installation disk, it is not so simple.
  6. At the time of testing off your favorite second monitor, so as not to catch the blue screens with an enviable consistency.
  7. If you need to test only one screen reader, choose the Window-Eyes, because it is easier to install and learn, as well as more appropriate in the work (this is my deep IMHO, and still better, "potytskat" demo before you choose).
  8. Relax and enjoy. Pleasures of mass: you can open Chrome, and try to guess what will be spoken in front of a URL or ponazhimat on Caps Lock and fun to listen to the howling JAWS’a when typing in upper case.

See Also

    Advertising

    Archives