Building better websites by understanding blind users browsing behaviour

In January, I went to a JAWS screen-reader demonstration with the aid of John who is a registered blind. Meeting John has helped further my understanding of building websites for users like himself. John has been using the internet ever since the first release of JAWS and now teaches a variety of screen readers to novice users.

What screen-readers are there?

The three major screen readers are JAWS (by Freedom Scientific), Windows Eyes (by GW Micro), HAL and SuperNova (includes a screen magnifier) both by Dolphin. They are mostly designed to work well under the most common software from Microsoft and Adobe, including Internet Explorer and limited PDF support.

JAWS is available in various European languages and is estimated to have 50% of the screen reader market, and 80% of these users are over retirement age. Sadly few users update their version of JAWS because having paid £300 for a computer, a blind user then has to spend £800 on JAWS and then even more money for major updates!

Surprisingly there are few screen readers that support Welsh, and of the big 3 only SuperNova does (not natively, but there is a special Welsh version). SuperNova has many language as well as many non-European ones used in the Middle East or India.

How do blind people visualise a web page?

Users progressively build a mental model that is very different from what we see. For example when we want to go from A to B on a street map we can visualise the route needed to take, where a blind user would look through a pinhole starting at A with possibly some information of direction, be it North or South. As a result they build a very one dimensional route for navigating websites starting at the tree and only after being familiar will they then branch out. Making information quick to find and understandable is the goal.

It does depend on the site but typically John and other JAWS users would browse a page in order of:

1. Headings tags (primary)
2. Site search (primary)
3. Navigation menu (secondary!)
4. List all links on a page (secondary)
5. SiteMap (secondary)

Use Heading Tags

When opening a webpage using IE (Ctrl + O) JAWS will announce how many, if any, headings and links are found such as “Page has 5 headings and 30 links”.

Users can jump directly to headings (press H) and it is very common to jump to <h1> because often this is where the content starts.

Then by pressing H again a JAWS user can move through the headings to see if he can get closer to the information he requires. Pressing (INSERT+F6) brings up a menu of only headings.

There should be some consistent numbering of heading tags through every page. It is good practice to start the main content with a <H1> and there is no need to apply headings into logo's and navigation.

The six heading elements, H1 through H6, denote section headings. Although the order and occurrence of headings is not constrained by the HTML DTD, documents should not skip levels (for example, from H1 to H3), as converting such documents to other representations is often problematic. W3C

Including the Site Search

Having a good site search is great a great way for blind users to navigate any website especially larger sites. Positioning a site search first or as high up on the page as possible or provide an anchor/jump link.

<a href="#search">Site Search </a>

<form>
<feildset id="search">
<legend>Site Search</legend>
<label for="one">Keywords</label>
<input id="one">
<feildset>
</form>

Because the <legend> is used for logical groupings of inputs it can be removed from the above example to avoid repetition.

Forms

1. Users often presume the submit button is the last item on the form and content must therefore be above the button including for example a login page containing the links “Forgotten Your Password” and “Register” would otherwise be ignored.

2. Label inputs with Label tags and headings with <legend> tags. Text contained outside <label> and <legend> tags will not be read out in Forms mode in JAWS. This is often the case for "the question" in radial/check boxes because there is no explicit association with the input. Using a fieldsets even a nested fieldset are perfectly legit and make structural sense:

Radio/check:

<fieldset>
   <legend>Contract/other</legend>
   <fieldset>
      <legend>Do you like Apples or Oranges?</legend>
      <label for="one">Apples</label>
      <input id="one" type="radio">
      <label for="two">Or Oranges</label>
      <input id="two" type="radio">
   </fieldset>
</fieldset>

Dates:

<fieldset>
<legend>Date of birth:</legend>
<label class="offleft">Day of birth</label><input ...>
<label class="offleft">Month of birth</label><input ...>
<label class="offleft">Year of birth</lable><input ...>
</fieldset>

Include carriage return:

With the style sheet off and to benefit back end developers without access to a style sheet it would nice to include a clearing tag! This has been done with <p> and <li> however I tend to use a neutral tag such as <div>.

<fieldset>
   <legend>Contract/other</legend>
   <fieldset>
     <div>
      <label for="one">Name</label>
      <input id="one">
      </div>
      <div>
      <label for="two">Phone Number</label>
      <input id="two">
      </div>
   </fieldset>
</fieldset>

...but what about inline HELP?:

If a form requires inline help then the form is too complicated and should be redesigned. However often we do not have the authority to revert decisions from clients or the powers above who insist on inline help. I suggest this...

<fieldset>
   <legend>Contract/other</legend>
   <fieldset>
     <div>
      <label for="one">Name <span>Help text</span> </label>
      <input id="one">
      </div>
   </fieldset>
</fieldset>

This does look really bad on the front end. Using JavaScript you could then reposition the span to appear in a nicer location or replaced with one of those DHTML things. Testing with a screen reader is then required.

Unique and descriptive Link Text

Users can browse through all links on a page (INSERT+F7) with the only information being read out being the anchor/link text. For this reason it is important to avoid words such as “click here” and “read more” and replace these to be more descriptive; “more about wiggets”.

Graphics alongside text

Where the graphics and text are next to each other and link to the same URL, make them both link using the same <a> tag to prevent them being read out twise! The alt attribute of images should usually be left blank unless it contains critical content available to visual users that is not in the text and there for not purely presentational.

Use List Item for Lists and Navigation Links

During the design stage the number of navigation links on each level (hierarchy) should be kept short. Markup using Lists Items will tell the users the number of links in the list before reading the first one out. If multiple levels of navigation are displayed on a page they should be separated out and skip links can be used to label them (though all List Items are skipable using a screen reader they are still useful for non-mouse users):

<skip main nav>

<ul>
  <li>A</li>
  <li>B</li>
  <li>C</li>
  <li>D</li>
</ul>

<sub nav>

<ul>
  <li>1</li>
  <li>2</li>
  <li>3</li>
  <li>4</li>
</ul>

Use Paragraphs

In JAWS a new paragraph can be identified using <p> or <br><br> and may read out “blank” using Jaws. JAWS users are able to skip between paragraphs.

Tables for design

It is very bad practice to use tables for design for reasons outside the scope of this article. However, you may use them for screen read users as long as the table tags contain no meaningful tags and attributes (e.g. <th>, caption, summary, scope etc...) that would wrongly identify them as data tables.

Use Data Tables

For data tables, identify row and column headers. [Priority 1] For example, in HTML, use TD to identify data cells and TH to identify headers.

Tables should be used for example in timetables, measures, prices etc. They should be structured correctly and should be made simple and 2-dimensional. If there are Table’s inside Tables they become too complex to understand and the page should be re-designed. JAWS users can have the information in a Data Table presented in the following ways:

1. Read out line by line.
2. Using the arrow keys to move along or up and down and JAWS reads out the heading of the column plus the content of the cell.
3. With the focus in a particular cell, the keyboard command (Alt+Ctrl+Num Pad 5), will cause JAWS to present the information relating to the selected cell. That is, the cell content and, if the table has been coded correctly, the associated row and column headings.

Title of the table should be contained in the HTML table as <caption> tag. <h> <p> <tr> <td> may all cause problems. When coding a table, the <caption> should come immediately after the table element and before anything else.

The “summary” attribute of table are useful for complex tables to provide an overview of the layout...

SiteMap

SiteMaps are useful if the user can not use any other preferred navigation such as site search. It is recommended each section of the SiteMap be broken down into Headings and the content as List Item tags. In order to pronounce the words correctly, SiteMap should be typed ‘SiteMap’ or ‘Site Map’. Not typed ‘Sitemap’. Same goes for HomePage.

Capitalise correctly...

Capitalise correctly, JAWS pronounces words differently depending on the context, and capitalisation is a factor, e.g. “read more” is pronounced “red more”, not “reed more”. So use "Read more about wiggets".

PDF

Tags are required to facilitate accessibility of PDF files. Tags can be inserted into a PDF by using and editor such as Acrobat. Tags are to identify such things as Headings, Paragraphs and Tables. There is a limited auto tagging option in the latest version of Acrobat that is currently very poor. It is better to convert into HTML where possible.

JavaScript, DHTML, AJAX and Flash

JAWS has introduced partial support for JavaScript so it will not have access to any content between the “noscript” tags. But older versions of JAWS commonly used will read the “noscript” tag!

Some onMouseover events are triggered but the results are unpredictable. These include Pop-up Layers or Windows so a user may not be able to locate or access the new content.

Flash can be made accessible to all users using best practice, including building in scalability, self-voicing and keyboard accessibility (focus, TabIndex etc...) and sadly only supported in later versions of JAWS, Window-Eyes, and IBM Home Page Reader. Flash content is rarely designed to include all accessibility features at the same time making it inaccessible in some way. Content must have been developed using Flash MX or later and more information for developers can be found on Webaim Creating Accessible Macromedia Flash Content.

AJAX is not supported though if you have access to the JavaScript there is a huge drive to make it so. Default AJAX using .NET2 is outside the scope of this article and I believe the .NET2 JavaScript can not be edited unless you provide your own.

Copyright

Screen Reader users often hear the copyright text as the end of the page so they stop reading there. For this reason it should always be the last in the HTML.

Unsupported methods by JAWS at this time!

Abbr and Acronym tags while useful for sighted and mouse users who can view/access toolTips, the abbr and acronym elements are not supported by JAWS. Looking to the future the <acronym> is not supported in HTML 5 and so future support may depend on <Abbr> tag for both.