Liddy Nevile, CTIE, Monash University, Clayton Campus, Victoria, Australia. Liddy.Nevile@eng.monash.edu.au
universal access design, W3C guidelines, metadata, web accessibility initiative, OZeWAI - Australian Web Accessibility Information
'Universal web access' is defined by the W3C Web Accessibility Initiative (HREF1) as equal access to web content regardless of what device is being used to access the web. It caters for those with yet-to-be-developed mobile net phones equally with those who depend upon braille machines attached to computers. In this paper, the significant shift in web design from connected, free form pages to structured material with differentiated layout, metadata, and ratings is considered. The pay-off for the more demanding process is recognised and a case study of web professionals battling with the change is described.
'Universal web accessibility', as defined by the World Wide Web Consortium's Web Accessibility initiative, is not what people think it is. Universal accessibility embraces the needs of those with special access devices, such as screen readers, but it is not about making sure that everyone has equal rights to view web material. nor is it about making sure that a screen on the web looks the same on the two major browsers, Netscape and Explorer. Such definitions are too constrained: the W3C's universal access takes into account all these issues as well as the evolution of the web.
Recognising that getting the code 'right' is not sufficient, that testing the web pages on a range of browsers is not adequate, leads developers to deep conflicts between their almost automated, fast-learned web development techniques and those proposed as sufficient for the future if web pages are to be universally accessible.
The author worked with a well-established consortium of Melbourne web developers to produce what was to be a fully compliant universally accessible website. For the system developers, this meant significant changes in how the large website would be served, especially given the need to use Lotus Notes and the Domino Server. For the graphic artists, universal accessibility initially meant death to their craft, they thought. In the result, the graphics have benefited from the new design process and the new way of working with the document management system foreshadows a more acceptable web building future for the infrastructure developers.
In this paper, the author considers the particular aspects of the syntax and semantics necessary to make web sites universally accessible and shows why they can be difficult to work with, particularly in combination with document management software. The author then argues that the web accessibility design principles do offer freedoms which can enhance significantly the experience of web building, and it is this pay-off which justly rewards those who make the extra effort to review and renew their web building practices.
The web accessibility features of the Victorian Health Channel web site will be demonstrated via a series of online case studies.
Universal Web Accessibility design provides for universal web access regardless of the devices being used to access the web.
We have shown that everyone's awareness counts (see the Web Accessibility Information CD/ROM (OZeWAI) (HREF2)). More specifically, that:
This means more than merely checking that a site looks as good on Netscape as it does on Explorer, or vice versa. For web commissioners to be made aware of the need for and advantages of universal accessibility takes some effort. The Victorian Health Channel was the first of the government channels to have such requirements. In hindsight, it is amazing to think that such a criterion could be disregarded but universal accessibility was not well-defined until 1998 and very few of those who are concerned about web development have had time to promote it. Fortunately, once web commissioners or developers do hear about it, they are attracted to it as a standard. The problem is that this is not sufficient as the implementation does require hard work and new commitments, as described below.
Working groups of W3C (including the author and a colleague, Charles McCathyNevile) have developed guidelines (HREF3) for web page developers. Primarily these have been incorporated into new versions of HyperText Markup Language (HTML) and Cascading StyleSheets (CSS). Currently, new standards for web authoring and browsing tools are being developed (HREF4).
HTML markup code, as best it can, supports the use of syntax which universally accessible webpages need, such as mandatory ALT tags for images and descriptions of all other multimedia objects which can be read as text when the multimedia object is not presented in its original form (the OBJECT tag). CSS works by interpreting the structure of the web page, which encourages the structuring of web pages into headings, text, and other special sections. Tools for testing compliance with HTML and CSS standards are available on the web and gaining fair recognition.
Unfortunately, as the guidelines point out, even correct HTML 4.0 code and CSS 2.0 stylesheets can produce inaccessible web pages. What is needed in addition is compliant layout, which cannot be mechanically controlled or tested like code, and good metadata and ratings information.
We have argued (HREF5) that the responsibility is, therefore, with web builders who should:
We argue that we all should recognise that:
Unfortunately, we have had to concede that currently there is no simple way to produce universally accessible web sites other than by following the guidelines and applying them to the web site's metadata, structure, content and layout.
In the case study example, the experience proved to be as difficult as anticipated. It was not a lack of willingness to embrace the new paradigm but rather the difficulty of abandoning old practices and thinking freshly about new possibilities which tested the team. It was this which also energised the team.
The call for tenders used to select the development teams described the need for universal accessibility but little attention was paid to this aspect of the specifications by the tenderers, it seemed. Tendering companies assumed that using Lotus Notes and the Domino Server would be the most challenging aspects of the code cutting and that their established skills with these products would be sufficient. They did not fully recognise the problem of using document management systems which do not serve universally accessible web pages. The graphics teams were so familiar with testing graphics across platforms and browsers that they did not understand the difference between that and developing structured pages which draw on cascading stylesheets. The successful tenderers were those who quickly responded to the call for such radical reforming of their practices and showed the capacity and willingness to take on these challenges.
Fortunately, both the graphics and the computing teams were as capable and energetic as they needed to be. Their challenge was to learn about web accessibility and its implications for artistic design and layout, accessible web site architecture, appropriate user interface construction and how to apply all these within the Lotus framework. The author was required to support and monitor this process, not knowing how it would be achieved in the context.
Almost everything that had been taken for granted had to be rethought. There were lots of obvious and simple things to be done; no frames, no Java or Javascript, all images fully described, toolbars and navigation as easily comprehensible seen through a text browser as on a GUI browser. More complicated was the use of Lotus Domino, the current version of it did not serve text marked correctly in HTML 4.0 but instead, text directly marked with older standard tags. This could not be altered and the only way around it was to bypass many of the useful aspects of Lotus Notes and prepare and store text already marked up in HTML 4.0. This meant a new editor for the text, new search engines, and a lot more work.
In addition to the text problems, there were difficulties associated with the use of metadata. Given that metadata was very new as a concept in 1998, hardly any websites had been developed which used it for structuring the website. This seemed the appropriate use of it in the Health Channel context. Metadata was to be provided for every web object (document like object or DLO) as well as some which would ensure that web browsers set to filter out material considered inappropriate for schools, for instance, would not miss the Health Channel for the lack of ratings metadata.
The management process adopted for the project allowed for the steep learning curve anticipated for the development team. The available time (three months) meant that this process had to be fast-tracked and guaranteed of success. Urgent meetings were called and a quick lesson in universal access and the use of CSS 2.0 were offered by Charles McCathyNevile before he left to work in the US.
It soon became clear that the whole team would have to work collaboratively and very creatively if the targets were to be met. Those called in originally as consultants and quality assurance advisers were as intimately involved in the development as the contractors. "This is fun" was heard so often in the early stages of the project it was scary. But it was also reminiscent of those activities which in hindsight are recognised to have been 'a little out of the ordinary', to have produced from the participants more than the sum of their contributions.
Goodwill, collaboration and a strong sense of the value of doing the 'right thing' dominated all meetings and working sessions. Humility on the part of all was also frequently displayed. Adventuring into a new space brought new challenges, including identifying external groups to whom the project team's work would become relevant in time. What was done in three months by the Victorian team would need to be suitable for the Commonwealth Government health channel when it is developed in the following two years, for example. This meant anticipating in 1998 what others might do in 2000.
Once the need for a stylesheet driven layout was understood, the problem of developing a stylesheet which could provide useful versions of the website to those accessing it through computer screens, screen readers, print, braille and more had to be considered. There were few examples available and the fear was that compliance would mean boring graphics and unacceptable constraints.
As it eventuated, the main graphic designer embraced stylesheets as a challenge and discovered new freedoms. His creativity and coding expertise came together in ways which may not be possible for the vast majority of graphics designers. As with other potentially complicated aspects of the web, it seems that those with exceptional skills can hoist up others by allowing their developments to be used as templates for those that follow. In the case of universally accessible stylesheets, this is to be promoted as one way of making the web more accessible quickly.
But stylesheets depend upon well-structured information on webpages. This meant that the team had to think carefully about what information would be where and develop a structure for the site.
It was decided that a few entry pages would be 'hard coded' and then the site would be totally dynamic, generated on-the-fly depending upon what material was available at the time. Five levels were chosen: the splash page, the 'home' page, then levels two and three which were really menus, and level four which would present the content of the site. In addition, nine different languages were to be provided for, initially for at least the four top levels (with the aim of having level four content material available in the future).
Consistency of look and feel would need to be maintained so that those browsing the site would have some sense of where on the site they were at all times. Colour coding of headings and composite photographic images was chosen to support the users' sense of locality. This meant that the stylesheet should provide for different colours and images according to the content being provided on the page. Moving through the website by working down the menu pages would make this easy but a wide-ranging search facility was also required, and as some material might appear in more than one location, the problem raised some difficulties.
Metadata is information about information. The Health Channel was required to have metadata for accessibility purposes.
First, ratings information was required as it is evident that some web browsing communities are only accessing websites that have been rated in compliance with some censoring criteria, such as those believed to be in place in schools in Australia. RSACi was chosen as the service to be used as it was believed this was the most commonly used one at the time. No problem with the material was anticipated as no sexually explicit, pornographic, violent or bad language or images were used on the site.
The significant work on metadata was incurred with respect to the metadata for external discovery purposes and for structuring the website. Dublin Core (HREF6) and Australian Government Locator Service (HREF7) standards were to be observed. In addition, it was discovered that a federal health channel is to be developed in the future and it was important that the material from the Victorian channel would be discoverable from within the federal channel. This meant bringing vocabularies in to line and this, in turn, meant thinking about thesauri and fixed vocabularies.
The metadata works as follows on the various levels of the website:
|
Level of Website |
Role of Metadata |
|
splash page (level 0) |
choice of languages (9 available) |
|
homepage (level 1) |
choice of access: services directory, life events, healthy living, ... |
|
menu page (level 2) |
details of main categories within the grouping chosen at level 1 |
|
menu page (level 3) |
annotated list of documents available within categories chosen at level 2 |
|
content page (level 4) |
content documents and links to other documents with several overlapping metadata classifications |
The metadata has four main purposes: language orientation, external site visibility (discovery via web search engines), website structuring and content relation.
Internationalisation of websites can occur more easily than in the past with the availability of reasonable online translators. The Health Channel was not to pioneer the use of such devices but was to have nine languages available for users so that they could at least work through the website to find material of relevance to them, even if they would then need to get that material translated, once it had been discovered. In the future, content will be developed in the various languages.
External site visibility: This purpose would be satisfied if the main three forms of metadata were made available on each page of the website (as served to a user): Dublin Core, general search metadata and AGLS. In addition, the metadata for the extra categories likely to be used by the federal health channel were adopted. This meant that all webpages, as served, would contain substantial information in their head about what was contained in the body of the page. This in turn meant a high overhead in terms of filesize for each page, as served. It also meant that the Lotus manager and server would have to extract the required information and on-the-fly produce the complex head for the webpage. For internal document management purposes, there were to be even more categories of metadata associated with each page. This meant differentiation between metadata for public and private (in-house) access but it also allowed the distributed authoring process to be well supported by Lotus Notes.
Website structuring: The keywords associated with each page for structuring the website are selected from a predetermined set which gives a chosen look and feel to the five main categories of the website content. These words were developed from the content, ensuring that there would be content for all words chosen and also that the website would have a feeling of shape for users. They were ordered hierarchically: the five main categories, words that represented content within the groups, and finally words which identified actual content. For example, under the heading healthy living there would be healthy lunches and under that heading an article about healthy lunches for school children.
|
Level of Website |
Role of Metadata |
|
splash page (level 0) |
choice of languages (9 available) |
|
homepage (level 1) |
menu containing among other entries: healthy living, ... |
|
menu page (level 2) |
a menu including: healthy meals, exercise regimes, ... |
|
menu page (level 3) |
'Healthy Lunches for Children' - a document about making
healthy school lunches |
|
content page (level 4) |
the document that talks about what to put in school lunches for young children or for sedentary adults |
The metadata associated with the content that makes these menus possible is in three categories in the head of each document, and in the main database that contains the actual content. It involves three fields: the title field, the content description field and the keywords-structure field. The content annotation is the same as the information used for description in the head and was carefully written to a formula for consistency, each description being approximately 50 words long.
In this way, information which is useful for discovery is also useful for website structuring because it is used for menu generation. Free searches, available on the website, are expected to account for less navigation among external visitors to the website.
Another set of keywords was established with particular attention to the future. These words were chosen from a thesaurus which had hierarchical structuring of the words in the vocabulary. This means that each time a word is chosen by a user, its relationship to all relevant content can be guaranteed. The thesaurus used is the current version of the one to be used by the Australian Government Health Channel (REF1). For the Victorian Health Channel, four levels of preferred words from the thesaurus and one of colloquial words are available.
The problem and its solution are best illustrated when we think of a person trying to find out about a pain in the abdomen. Suppose they look for tummy ache. 'Tummy' is not a preferred word in the health thesaurus but the Victorian Health Channel system matches it with 'stomach'. Then stomach is matched with abdomen which is matched with body parts - truck. If a search is done looking for tummy, stomach and abdomen will be used to identify the content to be returned. If the words stomach and abdomen have been used as metadata for content, they will appear in menus at level three and also be used to find other similar content where there is a matching of more than one keyword from the list (see below).
Content relation: Level four content is served on a web page that has a set form. One of the features of the page is a section that identifies other content material with overlapping subject keywords. Another section points to services that may be of use to the browser of the level four page. These links work into the services directory. Currently they are not generated by the software but instead, selected by the content author from available services information.
Both of the keywords fields can be populated by up to ten keywords. A special metadata editor has been developed as well as a thesaurus management engine. Searches on the Health Channel are not on free text using the usual Lotus Notes system but instead searches of specific value-added metadata . This adds considerable value to the navigability of the site.
The work done with metadata was not merely for compliance with discovery requisites. Accessibility from the perspective of discovery does depend upon good metadata being available, but this can be achieved in several ways. One is to have the metadata in the head of the web page, as was done in the Health Channel. The first problem with such metadata is to comply with the standards of those who search and index websites. Dublin Core, AGLS and other standards are very new and it is not yet clear how they will work in the long term.
Metadata is also useful to agents in browsers, especially those that are beginning to use the metadata to personalise websites for the user, according to the user's preferences. Making the metadata available to such browsers does not guarantee good use of it but it is an important step towards making intelligent websites which respect the user's needs and preferences rather than those of the publisher.
Universally accessible websites will not be such until the users as well as the publishers comply with the guidelines. Unfortunately, the browsers most common in Australia, particularly outmoded versions of Netscape and Internet Explorer, do not make the best use of stylesheets or metadata. Even people who have browsers which do use stylesheets and could be making the most of them do not always know this is possible. Many people find they cannot manage to read web material easily and feel distracted by what they perceive to be excessive graphics, or are troubled by too small or not appropriately coloured text or backgrounds. Stylesheets do respect the user's needs above all others when they are available from the browser. Text and some specialised browsers, such as Lynx, Jaws and others actually make use of metadata to display or present the user with comprehensible content.
The experience of those working on the Victorian Health Channel suggests that universally accessible website development requires significant shifts in attention for web builders. They need to rethink how they design and work on the web sites, embracing the new standards to do with ratings, metadata, cascading stylesheets and they need to be prepared to structure their content and websites for easy navigation.
HREF1 http://www.w3c.org/WAI/
HREF2 http://purl.nla.gov.au/sunrise/ozewai
HREF3 http://www.w3.org/WAI/GL/
HREF4 http://www.w3.org/TR/WD-WAI-AUTOOLS/
HREF5 http://purl.nla.gov.au/sunrise/ozewai
HREF6 http://purl.org/DC/
HREF7 http://www.naa.gov.au/govserv/agls/
REF1 The Health and Aged Care Thesaurus, 4th edition, September 1998, Canberra: Commonwealth Department of Health and Aged Care.
Liddy Nevile, © 1999. The author assigns to Southern Cross University and other educational and non-profit institutions a non-exclusive licence to use this document for personal use and in courses of instruction provided that the article is used in full and this copyright statement is reproduced. The author also grants a non-exclusive licence to Southern Cross University to publish this document in full on the World Wide Web and on CD-ROM and in printed form with the conference papers and for the document to be published on mirrors on the World Wide Web.
AusWeb99, Fifth Australian World Wide Web Conference, Southern Cross University, PO Box 157, Lismore NSW 2480, Australia Email: "AusWeb99@scu.edu.au"