Using Web Sites With A Screenreader
I was recently asked the following questions concerning accessing web sites via a screen reader.
- When using a screen reader on a new page you’ve never accessed before, how do you typically figure out what’s on the page and how to navigate around it?
- Has there ever been a site that pleasantly surprised you with how easy it was to navigate? If so, what was it and what made it so exemplary?
- What are the bugs or layouts that frustrate you the most and make sites impossible to use? What are the things that make you quit using a website and never return?
This really got me thinking about the history of screen reading software, accessibility, and the powerful yearning and desire to seek, find and read information! Before I spend time discussing my thoughts on web pages, it is necessary for me to provide a brief context about how screen reading software works.
The evolution of screenreader software really starts back in the days of CRT terminals. In fact one of the first terminal screen readers was called TotalTalk and it was based on software modifications to a HP 150 vT100 terminal developed by Maryland Computer Services.
TotalTalk converted information that was displayed on the VT100 CRT screen to speech, using software that drove a Votrax speech synthesizer. There were various commands that could be executed with the control and function keys that would say the current line, say the current word, say the previous line, say the next line. All of these commands were based on saying text that was relative to the current cursor location. when one moved the arrow keys which changed the position of the cursor, the TotalTalk would say the character, word, or line depending on the preference settings.
There are two features about the TotalTalk that are touch points for that stage of the accessibility evolution.
1) For the first time there was a solution for accessibility that provided the results via the spoken word.
2) Since the spoken word is being utilized, only one word at a time is presented. This is true whether one is reading a line, a single word, a character, or a sentence. The common block is still one word at a time even if those words are strung together to present the larger blocks of text. This contrasts quite vividly from the way in which one reads. In print reading, multiple words are segmented together; The sighted person takes them in instantaneously. In grade II braille reading, the braille dots that stream past one’s fingers represent entire words within one cell of braille. With my four fingers I can easily perceive three to four words almost simultaneously.
It is important to differentiate between the manner in which sighted persons look at a screen and the manner in which screen reading software presents the information. It is my understanding that a sighted person looks at a screen by quickly scanning segments that may consist of multiple words and/or multiple lines. The emphasis is on “quickly” as in very fast! This means that a common differentiator that permits one to find a certain piece of information on a page must employ attributes that are unique and easily recognized. This has lead to screen reading software attempting to duplicate this process by permitting the user to get a glimpse of the attributes of a screen. Fast forwarding to today where screen readers are attempting to view the graphical user interface elements, this can be quite daunting. Screenreader software tends to still present a screen as textual. In most cases graphical elements are totally ignored. A few more granular attributes are included that didn’t exist in the TotalTalk implementation such as headings and font changes.
Let’s dive in to the questions!
!If I am accessing a web page for the first time I pay attention to the title of the page. A good concise description is greatly appreciated. Then I will invariably query the screenreader software to tell me the elements on the page. I am interested in elements such as headings, links, style changes. If there are headings that clearly delineate the sections of the web page I will find a heading that matches my interest and drill down to list all the links under that heading, or if there are no links, I will begin reading the text of the page starting at that heading. If there are no headings, I will query whether there links on the page. I will then query the screenreader to list out all the links. This gives me a sense of the page. If there is an indication that there may be a form to fill out I will query the screen reader to show me the form fields. The key approach is to try and unlock the mystery of the web page and see if there is any logic to the elements. In all of this exploring the granularity of what can bee examined is a very tight window. This means that The more logically a web page is grouped, the more descriptive the links the better.
In my exploration of web pages, I have certainly seen all manner of presentation styles. One of the easiest pages to navigate is apple.com. I can immediately discern by the headings of the page the various sections. The links within the headings are well described. This experience has not always been the case. Years ago, the Apple site was one of the most confusing sites on the web.
An example of a very confusing and annoying site is http://my.safaribooksonline.com. This site seems to scatter information throughout pertaining to support help interspersed within the actual book browsing links. Another site that is quite difficult to access is godaddy.com. Sites that dynamically change as one browses are also very confusing because there is no indication of the change. This is true of sites such as gmail, linkedin.
As far as never returning to a site, that really depends on whether I need to access the site. An example is bitbucket.org. That site is seemingly totally full of javascript and dynamic changes. Yet I need to house repositories there. In these cases I am forced to hire a sighted reader to interpret the site for me.
Please comment with your experiences in accessing the web with screanreader technology!