Graham Lewis and Christine Smith, Centre for Academic Practice, University of Warwick
When we decided to have an edition of interactions on Web accessibility, it was obvious that we needed to address this issue for the Interactions site itself. This article takes you through some of the thinking that went on and hopefully demonstrates that the process is not an onerous one. The article assumes basic knowledge of HTML.
So how accessible does it need to be?
The University of Warwick standard on web accessibility states that:
"The site should not produce any Priority 1 errors when checked against the guidelines of the W3C Web Accessibility Initiative (WAI)."
The W3C (World Wide Web Consortium) is the chief body concerned with devising standards for the Web. The guidelines referred to here can be found on the W3C site and are organised into 3 priority levels with Priority 1 being the most urgent. A Web content developer must satisfy Priority 1 guidelines. Otherwise, one or more groups will find it impossible to access information in the Web site. Although there is no case law in the UK yet, it is likely that the UK will take the lead of the US and refer to the W3C guidelines.
Therefore we decided that the current issue of Interactions must meet the Priority 1 requirements and that efforts would also be made to meet the level 2 and 3 requirements. We have left previous editions unaltered for now as a reference point.
Testing Web Accessibility
The Bobby tool was used to check the accessibility of a previous issue (Vol. 5 No. 2) of Interactions in order to determine what changes, if any, were needed.
Screenshot of Interactions Volume 5 No 2 Index Page
Bobby can either be used online (for checking individual Web pages) or downloaded as a desktop application for checking a complete web site. In both cases a report is generated which lists any accessibility errors and their priority level. Bobby also raises further issues which require human judgement. Using the online Bobby is a quick and easy way of testing individual Web pages - simply type in the URL of your page and the report is generated.
Screenshot of the Online Bobby Tool
We step through the important items of the validation summary that Bobby gave us below.
Priority 1 Level Approval
Bobby detected no Priority 1 accessibility errors with Interactions Vol. 5 No. 2. Therefore it is awarded a Priority 1 level approval.
That was easy!
However some issues that required human judgement were raised. As an example a summary of points for the index page:
1. "If an image conveys important information beyond what is its alternative text, provide an extended description."
This applies to images used to convey information (e.g. graphs or complex diagrams). On the index page the two images are both logos so the description contained in the ALT attribute of the IMG tag is adequate. However as these images are also links it was necessary to add text links so that text only browsers would be able to use the page.
2. "If a table has two or more rows or columns that serve as headers, use structural mark-up to identify their hierarchy and relationship"
This involves using tags to group rows and columns to indicate their contents. However the table structure is used only for layout and grouping rows or columns would not be meaningful.
Priority 2 Level Approval
A Web content developer should satisfy the Priority 2 guidelines. Otherwise, one or more groups will find it difficult to access information in the document.
To gain Priority Level 2 approval, three errors had to be addressed:
1. "Avoid use of deprecated language features if possible."
Deprecated language features (usually HTML tags) are ones, which have been replaced by newer tags or methods. While browsers currently support these older features, they may not in the future and it is best to avoid them where possible.
An example of deprecation is the FONT tag which has been replaced by a new way of defining text font, size and colour: Cascading Style Sheets (CSS). The majority of problems with the example page were due to the use of FONT tags. A CSS style sheet was created and all the font tags removed. If you don't want to learn the black art of CSS at this point and your Web authoring program does not create them for you, you could simply remove any FONT tags so that the page will revert to the default font of the user's browser.
2. "Separate adjacent links with more than white space"
Just using white space to separate adjacent links can cause problems for many screen readers. The suggestion is to use bullet points or some other character to indicate the beginning of a link. On the example page the links were organised into lists. Any item placed in an list will automatically be bullet pointed.
Example Code Snippet
<a href="http://www.warwick.ac.uk/ETS/interactions/info.htm"> About Interactions </a>
<a href="ed.htm"> Editorial </a>
Note: if you want to create a numbered list use the ordered list <ol> tags instead of the unordered list <ul> tags.
3. "Use relative rather than absolute units in markup language attribute values"
Many HTML tags have optional attributes such as the ALT attribute that sets alternative text for images e.g.<IMG SRC="home_buttob.gif" ALT=""Home Button">.The table <table> and table cell tags <td> have optional width and height attributes. In the example page these width attributes were defined in numbers of pixels rather than as percentage of the width of the browser window. Percentage values were used instead as these can be scaled by the user via their browser settings
For example <td width="100"> was changed to <td width="20%">
Priority 3 Level Approval
To gain priority 3 level approval two errors had to be addressed
1. "Identify the language of the text".
The HTML element at the beginning of each page should use the HTML 4.0 "lang" attribute to help specify the main language of the text on the page, such as English, French, German, Japanese, etc. This helps the computer or access aid to present information in a way that is appropriate to the language and also helps automatic translation software that translates text from one language into another.
A English language attribute for the HEAD tag was set
i.e. <HEAD lang="en">
2. "Provide a summary and caption for table"
Like ALT text for images, each TABLE element should contain a "summary" attribute that briefly describes the table structure and purpose. The browser does not normally display the summary as it is mainly of use to non-visual users. Captions are displayed and assist in understanding the table. However with the example page, this was required as the table was used only for layout.
Although not an error the issue of colour was raised as a Priority 3 level item which could require further action.
i.e. "Check that the foreground and background colours contrast sufficiently with each other."
Currently the example page layout has a lilac background with a paler shade of lilac being used to highlight certain sections of the pages e.g. the edition contents and articles. Also the standard text is dark blue. Generally there was not felt to be enough contrast between these elements for anyone suffering with any degree of partial sightedness or colour blindness
By simply changing the background to white and the standard text to black a sufficient level of contrast was achieved.
Validating for use with a Screen Reader
For people with severe visual problems the use of screen readers may be their only method for accessing what appears on a computer screen. An initial worry was that the tables used for presentation layout may have caused problems and the content flow would not be logical
As a further test of accessibility, a demonstration version of JAWS (Job Access With Speech - a commonly used screen reader) was downloaded from the JAWS Website and used to test the accessibility of the Interactions Vol 5 No. 3 contents and editorial pages. Both pages were found to be easily understandable when converted into speech.
And finally.... here is a screenshot of the new index page with the changes highlighted.
Screenshot of Interactions Volume 5 No 3 Index Page
We hope that documenting our journey encourages rather than discourages you from making efforts to create accessible Web sites. Please contact us at CAP if you need additional advice.
Centre for Academic Practice
University of Warwick
Centre for Academic Practice
University of Warwick