Accessibility and Office Documents

This is the fifth in a series of articles about accessibility and office documents. As more and more information is now shared with the general public via the World Wide Web (WWW), in this article we’ll begin a discussion of web sites and accessibility. In future articles in this series we’ll deal with specific applications that can be used on line to communicate information and how the needs of those using Assistive Technology (AT) must be considered.

General Considerations about Web-based Communications

This article is intended to discuss some of the many accessibility issues regarding information that is shared with the general public via web sites. It is not intended as a primer on web site design, or the various coding languages that are used in web site design (e.g., HTML, CSS, etc.). Rather it is assumed that the reader is using some form of "editing" software and/or some "design templates" to post information on a publicly viewed web site.

Many experts in the field of web accessibility lament the fact that many well-designed and published web sites can be made instantaneously inaccessible by one person’s content. While systems to ensure that this does not happen have been incorporated into many applications, the fact remains that the only method to avoid these "accidents" is professional development and vigilant testing and monitoring.

Things to Consider

Having reviewed many web sites over the years, including ones purported to meet accessibility standards, I have found certain errors to be the fairly common. The message here is that despite one’s best efforts, knowledge and training, only vigilance will ensure your web site is fully accessible. With this in mind, here are some things to watch out for.


Headings (H1, H2, H3, etc.) are one of the most overlooked tools found in the digital documents. All authoring applications contain this tool but few people get into the habit of using them.

Using Headings are essential to persons using a screen reader as they often the user in navigating through the document. All screen reading technologies allow the user to "scan" through the document by jumping or skipping through the document reading every heading sequentially or reading selective Headings based on the Heading level (i.e., reading only the H3's). In much the same way a person without visual impairments may quickly scan down the length of a document to determine its content and intent, the screen reader user, by skipping from heading to heading can accomplish the same.

Although the use of the Heading tag generally changes the font-size, font-weight and even the font-family, more important is the order of Headings. Every web document should only have one H1 which is usually used to identify the Title of the document. The first subheading would be H2 and the first sub-sub heading H3 and you may continue heirarchally down to lower levels if the document requires. What is important to remember, to the person reading your document with a screen reader, the hierarchical order of the headings will give the reader a semantic picture of the theme of your document. If you jump around from Heading 1 to Heading 4 and then back to Heading 2, or choose poor headings for your document, the user scanning the document may become easily confused.

You should never identify content as a Heading unless it is a logical subsection of the document. And, unless the document is very long (e.g., a book with many chapters), care should be taken to limit the number of Headings to a reasonable amount.

For more information about Headings, see the WebAIM article: Semantic Structure.


Most web designers know about the major accessibility concerns surrounding the use of images in web pages. People familiar with publishing web content know that alternative text (the ALT attribute) ensures screen reader users are able to "see" the images that are on the web page by creating a description of the image. However, we often find web pages with images that do not have the appropriate coding and thus remain invisible to these users. As a solution, a number of web authoring applications including Dreamweaver/Contribute have been reengineered to cue the author to add an alternative description whenever an image is added to the page. Many web appliances like blogware and content managements systems are also designed to automatically (and often arbitrarily) add ALT text to the image or create an empty or "null" version of the ALT text (ALT=""). Unfortunately, some of these applications choose the file name as the ALT text so you get strange text like "johnb03485.jpg" as the alternative description.

What many people don’t realize is that sometimes text used for the alternative description makes the page more confusing to the user. For example, suppose you are reading along a document and all of a sudden the text changes to say "image: red ball." Apart from the fact that this can be very annoying, the information provided by the alternative text does little to contribute to the understanding of the content of the web page and may actually make the content more confusing.

Personally, I advocate for the universal use of the empty or null ALT text for all images except in the rare case when the image is actually a text graphic (i.e., words or wording provided in a graphic form). In my mind, 95% of the images on web sites are simply "pretty pictures" and add little to helping people understand the content of the page. There are of course exceptions to this practice, but if you examine your own web content seriously, I suggest than less than 5% of your images add important content to your documents.

Here are some resources regarding how to properly add alternative text to images on web pages.


The "proper" purpose of the HTML Table (the <table> element) is to present and display data in a web document. When using data Tables one needs to remember to add the appropriate "header" code (the <th> element) at the top of each column (Note: the <th> tag is NEVER used when Tables are used for layout). This tag tells the screen reader that the content is displayed in tabular form and helps the user navigate through the content.

Also, if you do use Tables for layout, you will need to ensure that the order of the information makes sense to the reader. Since screen readers (in English speaking countries) read across the page from left-to-right and top-to-bottom, the user can become easily confused if the content in the table does not follow a logical pattern. I have demonstrated an example of "bad" layout tables here and here are some resources demonstrating how to correctly code and test layout tables.


When creating on-line Forms (the <form> element), one needs to make sure every Form element (i.e., text field, checkbox, dropdown list, etc.) has a Label attribute and that the Label is associated to the correct element. Doing this allows those using screen readers to correctly identify where and what information is supposed to be entered in the text field or checkbox.

The number one accessibility error I have found over the years is the failure to add the <label> tag to search engine input boxes. Often this resource is added to a page through a template or widget meaning the web designer or web master may have to fix this error.

There are many tutorials on the web demonstrating how to correctly add Forms to web documents. Here are some resources on how to correctly build Forms.

Links and Hypertext:

Perhaps one of the most common accessibility mistakes is adding hypertext (or simply links) to web pages and failing to make sure that all of the hypertext contextually makes sense. In other words, if someone reads only the hypertext they should be able to understand where the link will take them.

The most common error in this regard is the use of hypertext that simply states "click here." Outside of the context of the sentence or paragraph, "click here" does not provide the user with any information as to where the clicking will take them. Often screen reader users navigate around a web page by tabbing from link to link. You can try this yourself and watch where the "focus" of the page goes. If the link does not provide a clearly understandable phrase or name, the person visiting your site will have a tough time understanding your links information and may travel down several "dead ends" in an attempt to find the information they are seeking.

One of the controversial issues related to the use of links is whether to actually write the Uniform Resource Locator (URL) into the text of the document (e.g., ""). There are two schools of thought. One says that you should always use hypertext. That is, the URL coding should always be "hidden" in the page’s HTML code and the reader should only see the "semantically correct" hypertext highlighted to indicate it is a link (e.g., Maine CITE Program). The other school of thought says that since people often print out the content from a web page (which shows only the highlighted text), the full URL should always be included.

Since many URLs are long and complicated strings of numbers, letters and symbols which are contextually meaningless, a reasonable compromise would be to include the full URLs only when they are short, easy to read, and clearly understandable.

An additional side note about accessible links . . . some accessibility experts proclaim that one should also use the Title attribute in all link coding. They reason that the Title can be used to provide additional information about the link to the user. Unfortunately, screen reader software generally does not pay attention to the Title attribute and unless the user has this feature turned on, they will not "see" this information at all.

Here is a resource regarding the use of links and hypertext

Final Thoughts

While many of the ideas discussed in this article can be accomplished with the click of a button, some recommendations require access to the actual HTML code. In some cases, the person posting the content into a web page will have the access needed to edit the direct code. However, in many cases the author will need to rely on the services of the web designer or web master to ensure their final document meets accessibility standards. Therefore, content authors must work closely with web designers to ensure their web sites meet accessibility standards.

In all cases, web documents should be thoroughly tested and validated before posting on live website. For more information about this process, readers are encouraged to review the resources on the Maine CITE Accessible Web Design page or visit WebAIM’s Introduction to Web Accessibility.

Where to go for help . . .

Maine CITE provides additional resources that can help you with your goal of creating accessible documents.

About the writer

John Brandt is a web designer and consultant who works with the Maine CITE Program in the area of accessibility and universal design. He may be reached at

Return to Accessible Documents page

Return to Maine CITE