Web Accessibility for the Impaired

On completion of this page you will know how to use an HTML validator to check the accuracy of your code and interpret its results.

Introduction

POSH is one of the foundation stones of web accessibility. It involves using the elements that HTML5 provides us with, but we must use them in the way they were meant to be used. One example of this is the humble <p></p> pairing that define a paragraph. Although the final closing </p> is strictly optional, for screen readers to be able to interpret the HTML code correctly it must be used. Consequently omitting the is considered bad practice

As we saw earlier one of the requirements of a Robust web page is that all opening tags should have corresponding closing tags regardless of whether the closing tag is optional or not. This does not apply to just the <p> but to every other html tag.

Checking through a large web page to ensure that each opening tag was matched with the corresponding closing tag would have to be one of the most demoralising tasks any developer could imagine. Welcome to the world of HTML validators.

HTML Validators

Like so many software HTML validators exist as web based and desktop applications. One example of a desktop version is CSS HTML Validator. There are validator attachments available for both Google Chrome and Firefox, although neither organisation appear to endorse them. For more information click on the following link for a comprehensive list of online and desktop HTML validation software.

For our exercises here we shall be using the CSS HTML Validator. It is intuitive and can test for accessibility up to WCAG AAA standards.

Preparing for validation

In order to test our validator we shall put some deliberate errors into our HTML code.

                    
                            <h3>Tane Mahuta separates Rangi and Papa</h3> 
                            <h4></h4>
                            <p>Mankind have but only one set of primitive parents. They were Rangi and Papa, the sky father and the earth mother. They existed in the darkness of Te Po and their children existed in the same darkness.
                            <p>Wearied by the continual darkness, their children yearned for the light. They consulted among themselves how they could be rid of their parents. Tumatuenga suggested that they should kill them but Tane Mahuta wanted to simply push them apart. All of the brothers agreed with Tane Mahuta except Tawhirimatea.</p>
                    
                

In the code snipped above we have put in two deliberate errors. The first is in line 30 where we have put the empty <h4></h4> tags. The second is at line 31 where we omitted the closing </p> tag. (You will have to scroll across to see this.)

Now we shall see if the validator will pick up on those two errors.

Running the Validator

Our first step is to run the validator. Once it is up and running we use File/Open to search for the file 'Maori Creation Stories.html' and open it. To start the validation program we press F6. The image below shows us the display once validation is complete

The upper part of the image shows a portion of the code where errors have been found. The lines where the errors have occurred are highlighted. In the lower half, a detailed explanation of each error is given.

First of all notice that the empty <h4></h4> tags cause only one error. This is because both the opening and closing tags are there and thus there is no rippling effect further down through the code

On the other hand the missing </p> at line 31 causes quite a few ripples. These are:

• Is the end of the line the end of the paragraph or not?
• We are not able to interpret the opening <p> at line 32 since we don't know if it should be there or not
• It breaks the logic of the structure as two <p> follow each other without a </p> being between them

This is simply a rewording of the last three error messages.

Printing results

All four messages above are quite long. Lack of space as well as the very small print size makes those messages difficult to read. If you need to study the messages in detail or keep a record of them, then the system offers a way to print them to a text file. You do this by right clicking on one of the messages. From the drop down list select Save Messages to File. From the second list select As text. This is shown below.

Click the following link to view a copies of the error messages produced above

So far we have looked at the Errors tab. We also notice that there is a marker on the Accessibility tag. Since the whole objective our exercise here is web accessibility we should examine this tab also.

Here we see that the system gives us a list of the WCAG guidelines that we have broken - in this case only one. Again we have long messages and small text which means that we should also print out the messages here. This is done exactly as in the previous example.

Click here to open the file containing messages regarding accessibility

Summary

Strictly speaking we don' need HTML validators. We can actually go through the code manually and check that each tag has a corresponding end tag. Similarly we can check that we have not nested any elements that should not be nested. We can also check that we have no broken hyperlinks, that we have a proper title on the page and that we have specified the language of the page. Now what about syntax errors that we are not even aware of since our knowledge of HTML is not perfect.

Checking for errors that we know about may takes a day for a small page and perhaps a week for a larger complex page. It will take an HTML validator only seconds to perform the same task.