Testing With JAWS

During my consulting practice, many times I hear that a site was speaking with JAWS, so it must be accessible/WCAG conformant/Section 508 compliant. In this article I will show how JAWS works, when can we use it for testing, and why testing with JAWS or any screen reader only, we cannot establish the accessibility of a web site. If you need more information on the topic, or you require JAWS scripting services, please contact us

What is JAWS

A screen reader, called "Job Access With Speech" is commonly referred to as JAWS. This software is manufactured by Freedom Scientific. Currently, JAWS is the most commonly used screen reader, however, many more exist, such as SuperNova, Window-Eyes, Etc., just to name a few of the most popular ones. For the sake of simplicity, this article only deals with JAWS, but all claims made about testing can be applied to any screen readers. The reason for picking JAWS as opposed to any other screen readers is that many people refer to a screen reader as JAWS, given its popularity.

How JAWS Works

Before we talk about testing with JAWS, we need to understand how it works. If you are familiar with how JAWS or screen readers in general work, you can skip to the next section.

In a nutshell, JAWS reads information aloud displayed on the screen, or entered on the keyboard.

In reality, reading information is much more complex. The screen reader needs to know which information should be read aloud, and the user needs to know which part of the information is necessary to communicate with the computer. For example, life would be so much more difficult if JAWS read the whole screen every time something changed on the screen. However, if JAWS reeds all text which changes its highlight, it is so easy to scroll down a list with the down arrow keys, and hear the current item as it receives the highlight.

In the meantime, just in case JAWS gets it wrong, or the user needs to hear something again, we can use hotkeys to announce certain information. For example, we can have the title announced, the status bar, the current word, the next paragraph, etc. All of these functionalities are assigned to a particular key combination. And this is only a small sample of what JAWS or a screen reader can read. And remember, for any given criteria JAWS can read off of the screen, you need to remember a keystroke in order to use it quickly and efficiently. Only the listing of these key combinations would take up several printed pages.

How JAWS Reads Web Pages

When it comes to web pages, JAWS needs to use a new trick. It cannot just read information from the screen, it is much more advantageous to receive all information from the actual HTML page. I will not explain all the technical details here, if you are interested, scroll to the bottom of the page, and ask me a question, I will be happy to give you more information. For now, let's just say that it is easier to obtain data from the actual HTML page. The reason is that information needs to be reordered before it is presented to a blind user. Probably you have seen pages which contain more than one column of text. If JAWS just read the text line by line, then you would first hear the first line of the first column, then the first line of the second column, then the second line of the first column, etc. It is very much like reading a newspaper from side to side, left to right. Of course, this doesn't make sense. Just as you identify which text belongs to a given article in the paper, or which text belongs to one particular type of content on the screen, JAWS needs to make an intelligent decision on how to order data before presenting it to the user.

Therefore, JAWS opens a virtual viewer while the web page is displayed on the screen by the browser. Then JAWS breaks up the entire page into blocks, and presents these blocks to the user, trying to establish the right order, which is usually from left to right and top to bottom. So, the user gets to read one block at a time. For example, the top menu bar first, then the left column where we find main article titles, then the right column where we would find the text of the selected article, and the page footer at the end.

So far, we have a virtual viewer, and a completely dismantled and rearranged page. Therefore, we will have to navigate the page slightly differently than we would in the original layout of the browser. In this case, the content will not be as wide, but will be much longer, containing many more lines. Scrolling will become different. Also, now that the whole arrangement has changed, we might as well give blind people extra tools to help finding information faster. And this is where the fun begins. JAWS provides extra keystrokes for finding content on a web page. For example, you can jump to the next or previous heading, list edit field, frame, or block quote, just to name a very few of the multitudes of options. Above, we have discussed that a JAWS user should remember a great number of keystrokes. Those still exist, while browsing a web page, JAWS adds many more. But all these need a unique key combination. Once we have hundreds of these keystrokes, we will have to make use of all modifiers. But if these keystrokes are difficult to press, for the lack of efficient amount of combinations, we cannot make users twist their fingers just to add a key combination like left Control-right shift-alt( any will do)-number 4. Did you try it? Now think about people who cannot use one of their hands, or can only press one key at a time. Fortunately, screen reader developers thought about these scenarios too. And the solution is excellent: JAWS uses the letters on the keyboard without any modifier keys for those key combinations which are most frequently used during browsing. The reason why we can do it in a browser is because during browsing, in average, we will need less interaction between the computer and the user. For the most part, we just need to navigate, and find information quickly. And once we need to interact, we can enter a special forms mode, where we can use the keyboard in a regular way to enter information. Once we are done entering text or checking boxes, we can get back to our virtual viewer and continue browsing, using the letters to navigate.

Let's Start Testing

Now let's say you have a web page to test, and you would like to make sure that it is accessible. You have downloaded or purchased JAWS, and you would like to test your web site. You will start with the login screen. You click on the user name field, and try to enter your name. For the sake of this exercise, let's assume your name is Joe. As you hit J, a dialog box pops up asking you which line of the virtual viewer you would like to jump to. Since you don't want to jump anywhere, you close the dialog box and continue typing, hoping that you have entered the letter J. When you hit O, JAWS will announce that it cannot find an object. Probably you won't even pay much attention to it, because you are used to type fast, you just hit the letter E, which will jump you to the password field, because E means that you want to jump to the next edit field, and on a login screen it would be the password field. So far we got stuck on the first page.

Let me give it away, so we can get past the login screen.

• Tab to the user name field
• Hit enter. JAWS will enter into the forms mode.
• Hit tab to move to the password field
• Type your password
• Tab to the Login button
• Hit enter

It might be slightly different depending on the layout of your login screen.

This one was only one example of how JAWS behaves differently in a browser, but there are many more. You can see it will require a learning curve to understand how to communicate with JAWS in order to work efficiently in a browser.

It is also not negligible that if you haven't worked with a screen reader, you will have to get used to synthetic speech. Nowadays, speech systems are much more understandable, but it is definitely a different experience to have a system read to you something which you used to read with your eyes.

And now comes the most difficult part, which is often overlooked. A blind person who has used JAWS for long years to browse web pages and perform any other daily tasks has an established method of requesting information from the screen in order to access all information. We might be able to ensure that all information can be pronounced one way or the other. But is it the right way? Do we get the information one way, or the fastest way? Unless we can put ourselves into the shoes of a blind person, it will be a difficult task to make a page work effectively with JAWS. The best way around it is to ask somebody who has used JAWS for years to test the page.

And How About People With Other Disabilities?

And while we are testing with JAWS we are excluding so many other people who need an accessible web site. Primarily those, who use another screen reader. While the concept of reading a screen is very similar, other screen readers might behave slightly differently. Not to mention a different version of JAWS we did not test with or is due to be deployed soon. Besides, we did not talk about those visually impaired people who don't need a screen reader, they would either just adjust the browser settings, or use a screen magnification system. But visual impairment is not the only type of disability. There are people with hearing impairment, others using voice recognition systems, etc. We cannot possibly test every single page with all available assistive technology products and with all their past and future versions.

How Can We Test For Accessibility?

articles on this site and elsewhere on the web.

How can we use JAWS For Testing

Because of the above mentioned reasons, JAWS should not be used to establish the accessibility of a web site in general. However, it could be used productively. If you know that a large number of blind people will use your site, for example at a government agency's office, it makes perfect sense to have one of the blind people review the web site and make sure it works well with JAWS. Sometimes, some suggestions may improve blind people's productivity with JAWS, even if a web site is already accessible. But also make sure that if you follow the route of testing with any assistive technologies, include other tools, such as screen magnification or voice recognition systems. In certain cases, there is a large gap between current accessibility standards and what assistive technologies work well with. While this gap should not exist ideally, while it does, you can help people with disabilities in the meantime.

Conclusion

What we have discussed in this article, mostly applies to any screen reader, not only JAWS. The access keys might be different, but the concepts are the same. There are hundreds of thousands of people who use JAWS or any other screen readers. It is a good idea to make sure that they are comfortable using the web sites you design. However, JAWS, or any other screen readers should not be used to test for any accessibility standards or guidelines. Rather, these tools should be applied to test for the usability of a site with a particular assistive technology.