Accessible Web Content Design Primer

Dr. Dragomir D. Dimitrijevic

This article addresses the issue of web accessibility and web design suitable for visually impaired. My ambition is not to write an exhaustive tutorial. There are certainly much better references on the Internet. My goal is to bring the problem of web accessibility to attention of web designers and show them that, with very little effort and a few tricks, they can make a world of difference to visually impaired people. In addition, accessible web content design should not be considered as just extra work done for some 2% of people living on margins of today's society. Arguably, content that is organized to improve accessibility for visually impaired is also more readable and better organized for sighted persons.

Navigation on the Internet without eyes

In order to understand how a blind person communicates with a computer, try to close your eyes while someone reads you sequentially text on the screen. In reality, that other person is a screen reader, software designed for that purpose. First, in such a way you lose spatial information about objects on the screen. Second, you don't have information about graphic objects, unless someone describes to you the content of pictures.

Visually abled persons primarily use mouse (or even touch screens) to navigate the Internet. They can visually review the screen and then directly access objects of interest on the screen (e.g., buttons or links). On the other hand, visually impaired people use almost exclusively keybord. My mouse is lost somewhere in the mess on my desk and I have to dig it out when someone else has to use my computer. Using the keyboard, the screen is scanned in a sequential manner until the point of interest is reached. A typical web page on a site like Amazon, CNN or BBC has between 100 and 200 links, so you can imagine that it would take forever to scan them until the desired one is reached.

Now when we outlined the above problems we understand that the primary goal of good design for accessibility is twofold:

- to shorten the sequential scanning process and allow skipping of unwanted content
- to facilitate understanding of graphic content.

To facilitate this scanning process, screen readers use keyboard shortcuts such as:

- "h" jumps to the next heading,
- "1", "2", etc. jumsp to the next heading level 1,2,etc.,
- "G" jumps to the next graphics,
- "tab" jumps to the next link,
- "t" jumps to the top of next table,
- "f" jumps to the next form field on the page, etc.

In what follows, we will outline some techniques for good design of accessible web pages. By no means the techniques will be exhaustive, but the use of this minimal set will greatly improve accessibility of your web pages.

Use of headings

In this section, we will address how to use headings, i.e., HTML tags <h1>, <h2>, <h3>, etc. The title of this section is heading level 3, and when a screen reader reaches it, it will say "Heading level three use of headings", thus it will tell us the name of section and its position within overall context of the page. We can jump from heading to heading (all levels) by pressing key "h" or we can skip from heading to heading of certain level by pressing the appropriate level number, e.g. 3.

In sucha way, we can quickly skip over unwanted sections and reach the desired one. Unfortunately, many web designers use headings to control fonts and visual appearance of text. An example of horrible web design is FaceBook where many lines are under headings. Besides lost ability for quick navigation, it is pretty annoying to hear " e.g. "heading level three" at the beginning of many consecutive lines. To cut the long story short, use headings only to separate logical units of text and not to change font.

Graphics

They say that a picture is worth a thousand words. In case of visually impaired people it is the other way around. Even one word is infinitely more valuable than a thousand graphic jpg and gif files. Pictures are placed in web pages using <img> HTML tag. Screen readers are not capable of understanding pictures and web designers have to help them using "alt" and "longdesc" options. The following table shows the same picture with different options. Visually, the picture looks same. However what we hear from the screen reader is different. The table shows the picture, HTML code, and some self-explanatory comments.

Picture HTML Code Comments

<img src=camel.jpg width=100> This is the worst you can do for the screen reader. It will not be aware of the picture and it will remain mute while scanning with arrow keys over the picture. The picture will truly be invisible to a visually impaired person.

<img alt=. src=camel.jpg width=100> Now when alt option has some value ("." in this case), the screen reader is aware of the picture. In this case it will just say "Graphics" and notify you that you are scanning over some picture but without any information about it. Note that some HTML editors put "." or "null" as default values of alt option and it is duty of web designers to put some meaningful value.

Dragomir and Jasmina ride camels <img alt="Dragomir and Jasmina ride camels" src=camel.jpg width=100> Now alt option has some meaningful and descriptive value and screen reader will say "Graphics Dragomir and Jasmina ride camels"

<img longdesc=camel.html alt="Dragomir and Jasmina ride camels" src=camel.jpg width=100> In case of a complex picture that requires long description, you can use this most comprehensive option. Screen reader will say "Graphics Dragomir and Jasmina ride camels. Press enter for long description". If you press enter, a new HTML page defined in the longdesc option will pop-up and it may contain arbitrarily long and detailed description of the picture. In most of the cases you will not need this option. However, if you want to make accessible a chart with numbers or enumerate all people in some picture, you may choose to use it. I suggest that, depending on the structure of your site, you keep these files with long description either in a separate folder, or keep them together with graphic files and give them the same name as the corresponding graphic file.

Graphic links

Similar to what has been described in the previous section is the issue of graphic links. Designers often use graphic links, especially in menus in the left-hand side of the web page. Here is what I found on one real site on the Internet:

<a href="overview1.jsp"><img name="menu_2" src="images/menu_2.gif" width="67" height="69" border="0"></a>.

And here is what the screen reader told me:

"Link graphic images slash menu underline two".

I had to click on that link to find-out that behind the link is page entitled "What we do - overview". You already guess, a friendlier solution is to place title of the target page in the "alt" option of the original image of the link.

Use of tag words

Although use of headings allows fast scanning over the page, sometimes use of some unique words in headings can eeven more expedite scanning of page. Every person will find his or her words characteristic for intended content but web designers might help that process. For example, my tag word onBBC News is "last" which immediately brings me to heading "last updated" where are the latest news. Similarly, although CNN has more than 100 links, by searching for "latest" I quickly get to the beginning of latest news. Ofcourse, it is a good idea to preserve these key words for people who are used to them and periodically visit your site.

Use of shortcuts

It is possible to asign shortcuts for quick access to some frequently visited places on the page so for example Ctrl+1, Ctrl+2,... may be assigned for quick access to some frequently used links, form fields or buttons. Personally, I don't use them, but many people do, so it is something to think about. You may see how it is implemented on the very good afforementioned BBC site. Use of shortcuts is usually documented with a list of shortcuts available on the page.

One thing that I find very annoying is sequential traversal over left-hand side menus that may be very lengthy. Namely, when you jump from page to page on the same site, the screen reader cursor is positioned on the top-left corner of the screen. Then you have to go over the menu on the left-hand side which is usually the same on every page of the site. There are two solutions to this problem:

A frequently used solution is to place a "skip to content" link in the top left corner which makes a jump internally within the page.

A simpler solution which I personally prefer is to start content with heading level 1 so the reader may skip to content by pressing "1" or "h" keys.

In such a way, one can choose either to go sequentially through the menu or skip directly to the actual content of the page.

Language issues

Depending on installation, screen readers may have multi-lingual capabilities. Screen reader communicates with the computer and receives a stream of characters that have to be pronounced. The way character stream is interpreted and pronounced depends on the currently active language synthesizer. The problem may arise when language of the character stream and the language synthesizer missmatch. Then it may sound like for example, an Englishman who does not speak French tries to read French text.

Most of the time, screen readers use the default language that was set-up by the user. However, it is possible to force them to change language within an HTML page using "lang" option. That may happen if for example in a French text you need to insert some English quotation from Shakespeare. I believe that very few web designers (if any) think of changing language in the page when change language of the text.

Generally, tools for web design insert into web pages language information of the locale set up on the computer used by the web designer. The problem occurs when the language of the text differs from the computer locale. For example, once I planned to visit a recommended restaurant in Germany and searched information on the restaurant's web page. The page was written in English but the default language code set by a German web designer read the text as a German person who does not know anything about English so I had to use some tricks to read the page.

Things may be even funnier. Once I received an HTML email from a friend who somehow picked up Portuguese language code. It was hillarious to hear Serbian text with Portuguese prononciation and Brazilian accent.

Now let's see how to control language in web pages. Consider the following HTML sequence:

<p lang=SR>
srpski
<p lang=FR>
Francais
<p lang=IT>
Italiano
<p lang=EN-GB>
English-Great Britain
<p lang=EN-US>
English-United states

The screen reader will first find change to Serbian language. Since my primary screen reader does not speak Serbian (I have another one for that purpose) it will admit that fact by saying in the current language (English) "Serbo-Croat" and read the word as an English-speaking person would do. Since the following four synthesizers are available (including British and American version of English), the reader will properly read text without any announcement about the change of language.

Finally, language set-up in the above example has local validity within the paragraph. If you want to set language on the level of entire page, you have to do it in the <body> tag.

Colors

For people like me, colors have no meaning. However, there are people who can see but are color blind i.e., they see things in black and white. Have them in mind and, before releasing your web design, turn off colors on your screen and verify appearance of your design. It may happen that your favorite combination of collors is close when seen as black and white and details become indistinguishable.

HTML Forms

Generally, labels of form fields may be placed in different positions with respect to the field itself (e.g., left, right, top of the field). In addition, labels may be physically separated from the field by some other objects/text on the page. In such a way, relation between the label and the field may be lost. To help the screen reader to connect the label and the field, it is a good practice to mark text of the label using HTML tag <label> such as:

<form>
<label for=name>Your name</label><br>
Some other text<br>
<input id=name type=text name=your_name><br>
</form>

This will produce the following form:

We may access this field directly from another part of the page by pressing shortcut "f". When we reach the field from far away, the screen reader will correctly say "Your name" despite the fact that the text of the label is physically separated from the field itself.

There is a problem with accessibility that is related both to forms and graphics that I often encounter on the Internet. Submition of comments and inquiries to owners of web sites is often done via forms. In order to avoid spammers and automated submission of a large number of inquiries, the submitter has to retype a randomly generated password drawn on apicture (graphic file). Obviously, use of the "alt" option would defeat the purpose of the use of graphic file since a computer generated attack would be able to read the password. Sometimes, such a web page is equipped with a link to an audio file that reads the password. In order to avoid automated voice recognition, such audio files are scrambled, often to much so one cannot recognize content. Other owners of web sites forget that there are people who cannot see and ironically, next to the picture of password is the instruction that the submitter should retype the password seen on the page, as if all site visitors can see.

Change of font size

People with low vision i.e., those who can see somewhat, mey require large fonts. Some sites provide buttons/links that programatically increase/decrease font size and keep it that way during the entire user's session on that site. This can be done using Java scripts that you can easily find on the Internet. I might be subjective because large font cannot help me, but I don't think that this feature is a must. Namely, everyone can adjust font size individually locally on the browser. It is even possible to define a personal stylesheet that shows web pages in certain way (colors and fonts) irrespectively to what the web designer defined on the site.

Other references and recommendations

As I mentioned at the beginning of this article, I had no intention to be exhaustive with details. The idea was to giv personal and subjective view to the problem of web accessibility, and to encourage web designers to at least try to make web more accessible with a minimal set of tricks.

Undoubdtly, the best authority on the issues of web accessibility is World Wide Web Consortium (W3C). They defined the "W3C-WAI Web Content Accessibility Guidelines 1.0" which prescribes formal rules for evaluation of web accessibility.

The "Americans With Disabilities Act" (ADA) is very well implemented site and should be looked at as a reference implementation. Also, I like very much the BBC News site.

Picture	HTML Code	Comments
	<img src=camel.jpg width=100>	This is the worst you can do for the screen reader. It will not be aware of the picture and it will remain mute while scanning with arrow keys over the picture. The picture will truly be invisible to a visually impaired person.
	<img alt=. src=camel.jpg width=100>	Now when alt option has some value ("." in this case), the screen reader is aware of the picture. In this case it will just say "Graphics" and notify you that you are scanning over some picture but without any information about it. Note that some HTML editors put "." or "null" as default values of alt option and it is duty of web designers to put some meaningful value.
	<img alt="Dragomir and Jasmina ride camels" src=camel.jpg width=100>	Now alt option has some meaningful and descriptive value and screen reader will say "Graphics Dragomir and Jasmina ride camels"
	<img longdesc=camel.html alt="Dragomir and Jasmina ride camels" src=camel.jpg width=100>	In case of a complex picture that requires long description, you can use this most comprehensive option. Screen reader will say "Graphics Dragomir and Jasmina ride camels. Press enter for long description". If you press enter, a new HTML page defined in the longdesc option will pop-up and it may contain arbitrarily long and detailed description of the picture. In most of the cases you will not need this option. However, if you want to make accessible a chart with numbers or enumerate all people in some picture, you may choose to use it. I suggest that, depending on the structure of your site, you keep these files with long description either in a separate folder, or keep them together with graphic files and give them the same name as the corresponding graphic file.