Accessible Web Content Design Primer

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. Third, unless helped with the appropriate organization of navigation, you have to traverse sequentially the entire content that comes before information you want to reach.

Visually abled persons have problems to understand how it lookss like working without eye sight even when they professionally work with blind people. I have heard a funny anecdote from a blind guy who consulted a company that worked on development of a Serbian screen reader. He had problems to explain to the visually abled software developer what was the problem with the installation procedure. Finally, he turned off the monitor and told to the developer to do installation without the monitor. The developer jumped and said "But I don't see anything." and the consultant replied "Now you have got the point.".

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 burried somewhere in the mess on my desk and I have to dig it out when someone else needs 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 300 links, so you can imagine that it would take forever to scan them sequentially 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 the 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,
• "l" jumps to the beginning of the next list,
• "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.

In sucha way, we can quickly skip over unwanted sections and reach the desired one. Unfortunately, many web designers either don't use headings or use them to control fonts and visual appearance of text. An example of horrible web design is FaceBook where, until recently, many lines were 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. If you want to change fonts use cascading stylesheets (CSS) and HTML attribute "class" defined for <p> or <div> HTML tags.

Picture	HTML Code	Comments
Picture starts Picture ends	<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. Text above and below the picture is for the benefit of users of screen readers because no sound will be produced by the <img> between the two lines of text. The picture will truly be invisible to a visually impaired person.
	<img alt=. src=camel.jpg width=100>	Now when alt attribute 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 attribute 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 (ofcourse with the appropriate file name extension).

<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" attribute of the original image of the link.

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 several 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 and the beginning of content is labelled using anchor like <a name="content">.
• 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 case of a long text, it might be a good idea to create a table of content with links used to jump to the beginning of a new section, as it can be seen on this page.

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

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" attribute. 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 ("de" for German language) 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 ("pt-BR" language tag).

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

<p lang="sr">srpski</p>
<p lang="fr">Français</p>
<p lang="it">Italiano</p>
<p lang="en-GB">English-Great Britain</p>
<p lang="en-US">English-United states</p>

which will produce the following output

srpski

Français

Italiano

English-Great Britain

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 <html> or <body> tags. If you want to have a limitted scope of certain language that spans over several paragraphs and pictures (including textual description of pictures), you can enclose this sequence of HTML code with <div lang="en">...</div>.

<form>
<label for=name>Your name</label><br>
Some other text<br>
<input id=name type=text name=your_name/>
</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 edit"announcing that we reached an editable field labeled as "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 (CAPTCHA - Completely Automated Public Test to tell Computers and Humans Apart). Obviously, use of the "alt" attribute 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.