New Accessibility Models: the Web Site of a Research Institute

Contributes to Accessibility and UsabilityThe Case of the Web Site of a Research Institute

Barbara Leporini, Massimo Martinelli, Institute of Information Science and Technologies (ISTI), National Research Council (CNR), Italy

(2005)

AbstractCreating a web site is a complex task which involves many aspects such as massive information structure, information daily updating, accessibility and usability issues.It is crucial to plan in details a site and its future maintainability, structuring information and, at the same time, it’s important to write pages in a way suitable by assistive technologies used by people with disabilities, which represent a significant percentage of the users.Aim of this paper is to analyze specific solutions we have adopted to improve the Web site of the Institute of Information Science and Technologies ( http://www.isti.cnr.it/ ), an institute of the National Research Council (ISTI-CNR), in terms of accessibility and usability, like ordered lists for adjacent links, heading levels and hidden labels, automatic assignment of tabbing order. Some approaches to Web pages development, in order to make easy to create a site, are also discussed.

Keywords: accessibility, usability, Web interface, blind users, disability

Index

1. Introduction ...................................................................................................................................... 2 2. Background ...................................................................................................................................... 3

2.1 Navigating through a screen reader ............................................................................................ 3 2.2 Accessibility and usability guidelines ........................................................................................ 4

3. Our approach ................................................................................................................................... 5 3.1 Technical approach ..................................................................................................................... 5 3.2 Accessibility and usability issues ............................................................................................... 5

4. Application samples ......................................................................................................................... 7 4.1 Adjacent links ............................................................................................................................. 7 4.2 Heading levels and hidden labels ............................................................................................. 11 4.3 Automatic assignment of tabbing order ................................................................................... 16

5. Discussion and conclusions ........................................................................................................... 18 6. Acknowledgements ......................................................................................................................... 18

1

1. Introduction

Realizing a Web site requires managing a lot of information as well as issues regarding quality of Web pages, in terms of conformity to actual markup standards, accessibility and usability.It is crucial to plan in details the site and its future maintainability, structuring information as well as dividing pages into well defined areas: an error at this level of the work, largely increase the time needed to change things later.Web sites designers and responsible of institutions and organisations should take in mind that a high percentage of users have different abilities and that they could need to operate with computers by special devices. In fact, assistive technologies used by people with disabilities require web pages structured and written in a suitable way in order to make easier Web page navigation.Even though creating an accessible and usable web site is, for the most part, a matter of common sense, it involves several and different issues: education, training, laws, etc []. That means several activities are necessary in order to provide an accessible and especially usable Web site. However, if accessibility and usability aspects are taken into account from the beginning of site design, achieving a comfortable Web site requires minor efforts. In the case of the Web site of the Institute of Science and Information Technologies “Alessandro Faedo” ( http://www.isti.cnr.it/ ) of the National Research Council (ISTI-CNR), not all the accessibility and usability issues had been foreseen at the beginning, but thanks to the planning and the structure of the site, we have been able to improve our work even after Web pages had been written. We followed several guidelines in order to realize the ISTI-CNR site with a good level of accessibility and usability for any user, trying to further improve these aspects in particular for blind people.The large number of guidelines proposed are often not easy to interpret and apply, besides, some solutions are quite particular and directed towards specific group of users and their application could come out unfavourable to others users. For example, the accessibility guidelines checkpoint regarding adjacent links that aim at facilitating users with visual and motor impairments, risk annoying blind people (in section 4.1 we propose a new solution). In this work we propose a possible solution which could be suitable for both groups of users.Basing on our experience, in this paper we are going to describe an approach aiming at facilitate developer’s work to make a Web site accessible as well as usable, also make easier the browsing for users who are constrained to use special devices (e.g. screen readers). In particular, basing on the personal experience of one of the authors, we focused on usability issues for blind users. Although in a first phase the Web site was accessible, a certain restructuring had been necessary in order to improve page navigation.The paper is structured as follows: after having introduced a background related to Web navigation difficulties when interacting through a screen reader, and to the main accessibility and usability guidelines, in section 3 we describe our approach. In section 4 case applications are described by proposing possible technical solutions to help developers in applying them more easily.

2

2. Background

2.1 Navigating through a screen readerUsually the analysis of digital obstacles for the disabled only addresses accessibility, although usability is fundamental for simplifying both navigation and interaction for users using assistive devices or those with special needs. Blind users navigate the Internet by using a screen reader, which announces the page content, whereas visually-impaired users can interact by means of magnifying programs. For users with certain disabilities such as vision or hearing impairment, or movement difficulties, the layout and structure of the interface play a meaningful role. When navigating by a screen reader the user perceives the page content in a different way from its rendering on the screen.A screen reader is a software application that attempts to identify and interpret what is being displayed on the screen. This is then presented to a blind user as speech (by a voice synthesizer) or by a Braille display. Several screen readers have been developed, herein we refer to JAWS for Windows [] which is the most used by blind people. When browsing the Web, JAWS gives users quick access to the Web pages, and provides detailed information about their structure and organization. Tables, lists, headings, and alternate text for images are all announced. The information comes right from the HTML used to create the page. HTML 4.0 is designed with accessibility in mind, and JAWS supports more of the built-in HTML accessibility features than any other screen reader. Any time user reads an HTML document, JAWS uses the Virtual Cursor. With the Virtual Cursor, Web pages are very similar a text document, because the HTML content is made in a sequential way. Thus, it is possible read the page content by using the standard JAWS reading commands, use the TAB key to move through links and easily follow them, display lists of links or headings to quickly find and move to what need.

Although sites may adhere to accessibility recommendations, users can still experience navigational problems. This is partly due to the fact that Web pages are increasingly designed for parallel or non-serial navigation, offering a variety of options within one page (frames, tables, drop down menus etc). Parallel design can cause problems for users who are navigating the site using assistive technologies which force them down a serial (or linear) route. In brief, the main problems encountered by a blind person when navigating through a screen reader or a magnifier are:

o Lack of context – Navigating by screen reader (or a magnifier) the user accesses only small portions of texts and may lose the overall context of the current page.

o Information overload - The unchanging portions of the site (menu, frames with banners, etc.) may overload the reading, because the user has to read through all the items nearly every time, thus slowing down navigation.

o Excessive sequencing in reading the information - The command for navigating and reading can force the user to follow the page content sequentially. This may provoke great frustration in the user.

o Keyboard navigation – Blind users do not use the mouse function (i.e. pointing, scrolling, selecting, etc.) for moving around the page; but instead move by means of keyboard commands, such as Tab key, arrow keys, and so on. Consequently, navigation around a page is slowed.

Although the Internet is a precious source of information and offers great availability of services (e-learning, e-business, e-government, etc.) all these drawbacks can discourage blind and visually-impaired users from accessing on-line services. A more general discussion about several issues related to visual layout and different kind of perception – i.e. through a screen reader or magnifier - can be found in [] and [].

3

2.2 Accessibility and usability guidelinesUp to today a lot of work has been already done to help webmasters to realize accessible and usable web pages and software producers have built several helpful tools in order to this, whose use is, unfortunately not widespread yet. [, ].Regarding accessibility of Web sites, a big effort has been done by the Working Groups of the World Wide Web Consortium (W3C) under the Web Accessibility Initiative (WAI) [] by providing the Web Content Accessibility Guidelines (WCAG). WCAG do not refer to a particular version of HTML nor to a specific technology (browser, screen reader, etc.) able to manage the information, they are general and not specific guidelines which give basic indications. Providing methods for exploiting general and customised characteristics and giving context navigation and awareness, the wide number of users and devices are able to access information. Section 508 of Workforce Rehabilitation Act [] requires that USA Federal agencies' electronic and information technology is accessible to people with disabilities. It provides guidelines for Web applications development similar to WCAG (but sometimes different as for example in the managing of scripts, applets, and more permissive in case of the change of the natural language, and more restrictive for the flickering).In the last years various Web accessibility laws are proposed at national levels. So, new “local” requirements have to be considered. For instance, the Italian law [] lists twenty-two requirements [] for Internet sites of public administrations (State, government, research, educational, etc.). Each law requirement is based on one or more WAI and Section 508 checkpoints, but some differences exist. This law adopts some of the first two levels of accessibility of WAI guidelines and, from the language point of view, proposes different level of compatibility allowing the use of a tidy HTML or, if possible, XHTML Strict.Important steps for improving usability requires to involve potential user before, during and after the design and realisation of a Web site, by collecting and analysing the feedbacks and also watching people surfing it: as regard we have to point out, Jakob Nielsen [] as one of the main source of information. Another important source providing useful information for building usable Web sites is IBM []: IBM Ease of Use Group provides guidelines for creating easy-to-use Web interfaces focused on a user-centered design process based on collecting information on each user's understanding of what a system provides in terms of functions and objects, and how the system responds when the user interacts with it, and the goals the user wants to accomplish during that interaction. Even if we have followed accessibility and usability guidelines, further improvements have been necessary in order to make navigation by a screen reader simpler. In the following we are showing new main improvement we have applied to our site.

4

3. Our approach

3.1 Technical approachOur work started debating on the information to publish on the ISTI Web site, taking also Web sites of other research institutions into account: during this phase, besides defining and listing the information type we had to publish, we have tried to guess other possible future information and where to publish it, to fit all the tiles in our mosaic: a draft list of informative sections to be included in the site has been produced as first result.A graphic designer was contacted: we asked him to limit the use of dynamical contents, in case to use strongly annotated Scalable Vector Graphics (SVG) [] and Synchronized Multimedia Integration Language (SMIL) [], but nothing else (the actual version of the site has no dynamical content, this has made our work easier). The graphic designer has produced two templates in HTML format, the first for the home page and the second for all the other pages. We rewrote the templates into XHTML transitional [], taking into account main accessibility issues (e.g. WAI level A guidelines as alternative descriptions), but without separating the content from its rendering (i.e. no style-sheets were used) and without changing the graphic design at all. Later, but even before Italian law on accessibility has been approved, we revised the Web site by rewriting it in XHTML strict with CSS [] and better considering accessibility as well usability aspects.For our purposes, we have used a number of software programs, in particular:

- HTML Kit [] to write XHTML pages;- W3C Validator [] to verify conformity to the XHTML Strict DTD;- Webxaxt [] tool to verify conformity to WAI guidelines.

Functionality and layout of the pages have been then verified with different browsers, in particular with Firefox and Internet Explorer, and on computers using different operative systems (Windows, Mac Os and Linux).We have afterwards divided the second template into different files structuring it into well-separated sections, each one with its own task (main content, static and dynamic information based on the context).This has been the most important thing because in this way we have obtained a modular structure able to set content writers free of other assignments and leaving us free of further modifying XHTML code to improve accessibility and usability later on, even now that the site is published and daily updated, and also guaranteeing us the possibility to apply a change to all the pages in one shot.Templates separated into several files together with a system for assembling these at the user request largely reduce time needed to web masters to build Web sites. At this aim we have decided to use Server Side Includes (SSI) to assemble files composing pages, static for the most part, while we have chosen PHP Hypertext Processor (PHP) as scripting language for information assembling when part of information comes from a database, for example the ones regarding people (room number, phone, email, etc…).We have afterwards realised an external tool to semi-automate news publication: a Java Servlet applying XSL-T (eXtensible Stylesheet Language for Transformation) stylesheets dynamically generates Java Server Pages (JSP) with XHTML Forms that are used to insert, modify and delete news. The Java Servlet itself, using other XSL-T stylesheets, generates RSS files and also XHTML fragments assembled by SSIs as previously described.

3.2 Accessibility and usability issuesAfter the rewriting Web pages and templates in XHTML Strict, we have worked on how to implement accessibility and usability issues. Regarding accessibility, mainly W3C (WAI) guidelines and Italian law requirements have been considered.

5

In practice, we have focused on all the parts that could be included in the templates, writing these once and for all, and which guidelines must be considered by developers whenever a page is written or modified. We have thought of this aspect in order to facilitate developer's handling job as much possible. In fact, the ISTI Web site is updated and maintained by several people and so it is important to reduce work in order to reduce possible errors and oversights. Besides, not all people who update Web pages are able to manipulate XHTML code in depth.Main accessibility aspects considered can be summarised as follows:

• Alternative descriptions: at first a generic descriptive alternative text has been assigned to images; later, more significant descriptions have been used. For example, for a decorative image representing a portion of moon, the alternative description “decorative” was used as the value of the “alt” attribute; later, it has been changed to "orange moon slice" in order to make the description more readable by a screen reader.

• Separation of adjacent links: according to the accessibility guidelines (WAI Checkpoint 10.5), a sequence of links should have a separating special character; we have used a different technique which gives a similar result. In this work we show how a list tag <ol> instead of a printable character (like “|”, “-“, “.”, etc.) can be used; this solution has been used both for horizontal and vertical groups of links (see section 4.1 for more details);

• Site search: since some old browsers do not allow identifying a form field through the “Tab” key, a default text is added to site search field, as checkpoint 10.4 of WAI suggests. This fact implies users to delete the default value before setting the text to search for. Blind users could have some difficulties to do it, so that they could write incorrect search text. To this end, a javascript function aimed at deleting the default text is executed when the search field receives the focus.

Regarding usability, we have especially concentrated ourselves on how to improve Web navigation for those users who interact with a screen reader and, in particular, we have focused on the following issues:

• Page structuring into logical sections: heading levels and hidden labels have been added in order to provide users a general idea about main logical sections composing pages (see section 4.2);

• Importance levels: visiting order of links depends on the page level within the site tree hierarchy. For instance, in a second level page, links belonging to vertical menus are visited before those of the horizontal ones. To this aim, we propose a specific javascript procedure for assigning automatically tabindex values to interactive elements of the page (more details can be found later in the section 4.3);

• Shortcuts to main links: main links (e.g., Home, People, Organization, Research units, and so on) can be reached by pressing specific keys (e.g., Alt+H, Alt+P, Alt+O, Alt+R, etc.). In order to inform users about the list of available shortcuts, a special “help” page (reachable from any page) has been prepared;

• Identification of page content: in order to let people jumps to page main content, a “skip to content” link has been added; however, we propose another way to make content identification easier by adding a specific hidden heading level (see section 4.2 for more details);

• Page pathway: for each page the <title> tag (within the <head> section) contains the path needed to reach the current page starting from the “home page” (e.g., Home::Research Units::Research Laboratories::…). Besides, in order to highlight which is the current page, its related link (in the left menu) is bold (<strong>). To make this “visual” information accessible, we propose to add a hidden label “(current page)” to the link content. For example, if the current page is “About ISTI”, its related link (in the left menu) is “About ISTI (current page)”, where “current page” is interpreted only by the screen reader.

6

The proposed code to do this is<a href=”.”><strong>About ISTI<span class=”hidden-label”>(current page)</span></strong></a>

For more details on hidden labels refer to the section 4.2.

4. Application samples

In this section we describe some main new ideas and the application samples in order to explain how we have taken into account the problems and we have modified the XHTML page code. In particular the following examples are being described:

- adjacent vertical and horizontal link separation using ordered lists (accessibility)- headings levels and hidden labels helping sections and subsections navigation (accessibility

and usability)- automating assignment of tabbing order using javascript (usability)

4.1 Adjacent linksA problem we have faced is the separation of adjacent links in order to facilitate the interaction by people with motor/visual impairments. According to the accessibility guidelines (WAI 10.5 checkpoint), a sequence of links should have a special separating and printable character (like “|”, “-“, “.”, etc.). This requirement should be fulfilled even when the links are on different rows and divided by an appropriate margin and also by some paragraphs (<p>). Even if this solution can be correct for user with motor/visual impairments, it is at the same time strongly annoying for blind users that have to listen to the character several times, thus we have thought of a different technique to obtain a similar result.We have then put both horizontal and vertical adjacent links into ordered lists (<ol> XHTML tag) without list-style, setting also appropriate margins. We think this solution makes moreover the context easier to understand because the item number can be reported by the screen reader even if it has no list-style. Listing “1” shows a coding version in an XHTML document, and figure “1” shows how a browser renders it.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"><html> <head> <title>Adjacent Links Examples Using Ordered Lists</title> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-15" /> <style type="text/css">

ol.vertical LI { display: block; list-style-type: none; margin-top: 1em;

}

ol.horizontal LI { display: inline;

list-style: none; margin-right: 2em;}

</style> </head>

7

<body>

<ol class="vertical"> <li><a href="http://www.a.it/">A site</a></li> <li><a href="http://www.b.it/">B site</a></li> <li><a href="http://www.c.it/">C site</a></li> </ol>

<hr />

<ol class="horizontal" > <li><a href="http://www.u.it/">U site</a></li> <li><a href="http://www.v.it/">V site</a></li> <li><a href="http://www.z.it/">Z site</a></li> </ol>

</body> </html>

Listing 1 – vertical and horizontal adjacent links inside lists

Figure 1 – listing 1 rendered by a browser

8

In the home page of the ISTI Web site the solution above has been extensively used and figure “2” shows how a browser renders the vertical and horizontal links.

Figure 2 – adjacent links inside lists in the ISTI home page

9

VerticalOrdered

List

VerticalOrdered

List

HorizontalOrdered

List

Next figure shows the link list read by Jaws.

ISTI Home Page

Link help page alt+1

Graphic Institute of Information Science and Technologies logo

List of 11 itemsLink About ISTI alt+ALink Organization alt+OLink Research Units alt+RLink People alt+PLink Publications alt+ULink News/Events alt+NLink Job/Concorsi alt+JLink Library alt+LLink Intranet alt+ILink Miscellanea alt+MLink Emergency alt+Elist end

ISTI •Link Areadella RicercaLink CNR,via G. Moruzzi 1, 56124 PISA, Italy • tel +39 050 3152878, fax +39 050 3152811 • P.IVA 02118311006 • C.F. 80054330586

List of 2 items List of 2 items Link Level AAA conformance icon, W3C-WAI Web Content Accessibility Guidelines 1.0 Link Valid XHTML 1.0! List end Link RSSList end

Figure 3 – listing 1 rendered by a browser

10

4.2 Heading levels and hidden labelsAll the pages, apart the home one, have a common graphical layout that visually groups five main parts:

- a first row of heading containing the links to the main sections of the site;- a left column containing the links to the pages that are at the same level of the current one,

that are the siblings pages considering the site a tree with the home page as root;- a central part containing the specific content of the page;- a right column that contains the links to the previous level of the site tree and to the help

page;- a footer containing comments and links to various utilities.

We have thus been led to devise an alternative navigation method to look at a region of the screen and to move the mouse over it: the leading idea is to introduce a label that is not visible on the screen but that is detected by a screen reader, and that allows blind users to individuates simpler these five parts and skip from one to another.At this aim we have used a CSS stylesheet with a class selector we have called “hidden-label”: this class selector set an absolute position of 1000em on the left (that is out of the user’s sight) and assigns the lowest stack order (z-index) to the so-classified elements, so that they will be ever overlaid by other objects.

The following is an excerpt from the CSS stylesheet:

.hidden-label {position: absolute;left: -1000em;z-index: -1;

}

We had also tried to use the “display:none” CSS property, but this solution doesn’t work on some version of screen reader and the rule in this case should be that the screen reader have not to parse and report and the text classified in this way.We have then classified in this way a suitable number of headings usually identifying the beginning of important sections of a document, weighting the five functional parts, on the base of their task, using the XHTML headings hierarchy (h1, h2, h3, …). A hidden label has also been assigned to the search field to point out this possibility.

Our attention had also been attracted by the <div> element: this is certainly used to separate sections but its content is usually a big part of the document instead of a short description and can be found different times in a page to create sub-layouts as father of other <div> elements that can’t anyway express the level in the <div> hierarchy, as instead sublevel headers can do.

11

Listing “2” is an excerpt from the XHTML code of a page containing hidden labels.

<body> ... <h1 class=”hidden-label”>site main sections </h1> ... <h2 class=”hidden-label”>current level sections</h2> ... <h1 class=”hidden-label” id=”content”>content</h1> ... <h2 class=”hidden-label”>previous level section </h2> ... <h2 class=”hidden-label”>search</h2> ... <h3 class=”hidden-label”>footer</h3> ...</body>

Listing 2 – a page containing hidden labels

In figure “4”, showing the “About ISTI” Web page at the address http://www.isti.cnr.it/AboutISTI/, the five main parts and each relative weight discussed above have been highlighted.

Figure 4 – main sections and levels of the pages of ISTI Web site

12

1 site main sections1 site main sections

22current current level level

sectionssections

22previous previous

level level sectionssections

3 - footer3 - footer

1 content1 content

2 search2 search

As it is possible to notice in the previous listing the content header has an associated identifier (id=”content”). Immediately after the body start tag we have put a hidden link that allows a blind user to skip directly to the content of the page, without reading all the times information that is almost always the same (headers and navigation bars):

<p class="hidden-label"><a href="#content" tabindex="1">skip to content</a>

</p>

Different screen reader facilities are shown in figure “5”: • the left window shows (and, of course, pronouncing) the main sections of the page

individuated through the hidden labels• the right up windows shows the links list (note the skip to content is the first one)• the right bottom window shows the form field list

Figure 5 – screen reader facilities

Web developers could now think it is boring to add heading levels and hidden labels in all the pages, but using SSIs it is easy to write these once for all the site.

13

Listing 3 shows the template with SSIs directives we have used, things Web developers have to do are two: to add the levels in the title and insert the main content.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"><html> <head> <title>Home:: **** ADD LEVELS HERE **** </title>    

 <br />

<p class="corpoSmall"> <em>Last update  </em> </p>    

</body> </html>

Listing 3 – SSIs directives used to speed up the work

Similar approaches can be followed using a CGI or a scripting language: the XHTML pages of the “People” main section of our site are dynamically generated by a PHP procedure that collects information from a database and forward to the output also the prewritten files using the “fileoutput” command ( fileoutput("filename.html") ).

Heading levels and hidden labels have been written once; these are in the files automatically included by SSIs (CGI, PHP, etc...) as the listings excerpts 4, 5 and 6 show.

. . .<body onload="set_tabIndex()"> <p class="hidden-label"> <a href="#Content" tabindex="1">skip to content</a> </p>. . .

Listing 4 - an excerpt from pages_bar.html

14

. . .<span class="hidden-label"><a name="top"></a></span><h1 class="hidden-label" id="Content">content</h1>. . .

Listing 5 - an excerpt from page_bar.html

<h3 class="hidden-label">footer</h3><br /> <p>ISTI • <a href="http://www.area.pi.cnr.it/" title="CNR Area Pisa Web site">Area</a> della ricerca CNR, via G. Moruzzi 1, 56124 PISA, Italy • </p>. . .

Listing 6 - an excerpt from address_foot.html

As regard we have to signal that the last version of Internet Explorer on Macintosh OS X does not recognise the compact version of elements without content (<a name=”top” /> instead of <a name=”top”></a>) and this initially had erroneously caused the first element following the hidden label to be hidden too.

15

4.3 Automatic assignment of tabbing order

The use of hidden labels in combination with heading levels and a suitable index tabbing (to jumps among links) gives blind users a good means to access information they are interested to consult.A page often contains many links and assigning a tabindex value to each one requires time. Anyway links in a page are usually visited according to the reading flow and thus we have assigned tabindex values that depend on the place of the link respect to the five main parts of our site.At this aim we have assigned a tabindex to the links on the base of their relevance and of the section they are, starting from the most relevant, for us the “skip to content” link (tabindex=1), to the less ones that are contained in the footer area (tabindex=30).

Figure 6 – tabindex values

In reason of the graphic design that requires the links of the same section rendered in the same way we have assigned a class to the links in order to write a suitable CSS style. In this way we have easily obtained a method to associate automatically a tabindex using a javascript code starting at the body loading and checking the link classes (<body onload=”set_tabIndex()”> ).

16

2020

10101515

3030

5 (no hidden labels)5 (no hidden labels)

1818

1 (skip to content)1 (skip to content)

Listing 7 shows the javascript code used to assign a tabindex values to links:

<script type="text/javascript">//<![CDATA[function set_tabIndex() { var inputFields = document.getElementsByTagName('a'); pages=document.getElementsByTagName("a"); for (var i=0; i < pages.length; i++) { var curEl = document.getElementsByTagName('a').item(i); if (curEl.name == '') { curEl.setAttribute('tabIndex','5'); } if (curEl.className == 'skip_to_content') { curEl.setAttribute('tabIndex','1'); } else if (curEl.className == 'menuSx') { curEl.setAttribute('tabIndex','10'); } else if (curEl.className == 'search') { curEl.setAttribute('tabIndex','18'); } else if (curEl.className == 'menuDx') { curEl.setAttribute('tabIndex','15'); } else if ((curEl.className == 'menuOriz') ||

(curEl.className == 'menuOrizEmergency') || (curEl.className == 'logoisti')) {

curEl.setAttribute('tabIndex','20'); } else if ((curEl.className == 'menuFoot') ||

(curEl.className == 'logocnr')) { curEl.setAttribute('tabIndex','30'); } } } //]]></script>

Listing 7 – javascript assigning tabindex values

17

5. Discussion and conclusionsIn this article technical aspects regarding realisation of Web sites have been described taking into account accessibility and usability issues; in particular the work done to realise the ISTI-CNR Web site have been discussed and some new contributes to improve accessibility and usability have been proposed, in particular for blind people.Structuring pages into divided files, each one with its own task, not only helps to maintain pages homogeneity but also reduces the work needed to build sites and to apply accessibility and usability items.It is true that our work has been made easier by the fact that for the most part the pages of our sites are only composed of text and still images, and these does not contains elements like dynamic multimedia presentations and does not requires a continuous interaction.In this way the same techniques have also been used for pages containing data coming from a database, like those showing information about people afferent to our Institute, partially generated by a PHP procedure or by Java Servlets.Therefore, thanks to the good planning and to the structuring of information that have to be made before the implementation phase, a uniform and consistent level of the accessibility and usability in all the pages can be obtained, as well as the maintenance of the site and the subsequent modifications can be made easier. It is evident that simple attentions as alternative texts or tables’ summary have to be added manually by the content writer.Other usability aspects could be improved:

- the way opened by XML, DTD/XML Schema and XSL, that well separates the content from the structure from the style of a document, has been in some cases ignored by accessibility and usability issues: we think a new solution is required to avoid the excessive number of elements and attributes mixed inside the page content for accessibility and usability which compromise the above separation concept

- the use of sounds could improve browsing to blind people, for example a sound at the end of the page loading process, even if not active by default. The “Opera” browser allows setting up a configuration option to signal the end of the page loading. Waiting for the use of aural stylesheets provided by CSS2 on all the actual browsers, a temporary solution could be realised with a script procedure

- the dimension and colour of characters could be personalised with a procedure in order to improve browsing to visually impaired people. In fact, also WAI suggests such a kind of customization (See http://www.w3.org/WAI/changedesign.html).

6. Acknowledgements

The authors wish to thank Renzo Beltrame and Claudia Raviolo for their valuable contribution to this paper and to daily work.

18

7. References

1. Electronic and Information Technology Accessibility Standards section 508, Workforce

Rehabilitation Act, USA Federal Register,

http://www.access-board.gov/sec508/508standards.htm

2. HTML Kit, http://www.chami.com/html-kit/

3. Jaws for Windows, 2005. Freedom Scientific at http://www.freedomscientific.com

4. IBM, Web Design Guidelines, at http://www-3.ibm.com/ibm/easy/eou_ext.nsf/Publish/572

5. Italian accessibility Law, 2004, available at

http://www.pubbliaccesso.it/normative/law_20040109_n4.htm.

6. Lazar J., Dudley-Sponaugle A. and Greenidge K., 2004. Improving Web Accessibility: A

Study of Webmaster Perceptions. Computers and Human Behaviour (in press) 2004.

7. Leporini B., Paternò F., 2004. Increasing Usability when Interacting through Screen

Readers, International Journal Universal Access in the Information Society (UAIS),

Springer Verlag, Vol.3, N.1.

8. Leporini B., Andronico P., Buzzi M., 2004. Designing Search Engine User Interfaces for the

visually impaired. In The Proceedings of the ACM W4A International Cross-Disciplinary

Workshop on Web Accessibility 2004, at the Thirteenth International World Wide Web

Conference, 18th May 2004, New York (NY).

9. Ministerial Decree July 8th, 2005 at http://www.pubbliaccesso.it/normative/DM080705-

en.htm

10. Nielsen J., 2005. Alertbox: Jakob Nielsen's Newsletter on Web Usability,

http://www.useit.com/alertbox/

11. Nielsen J., Alertbox, November 2005, available at

http://www.useit.com/alertbox/accessibility.html

12. Pitt I., Edwards A., 2003. Design of Speech-Based Devices - a Practical Guide. Springer,

London, Great Britain, 2003.

13. Web Accessibility Initiative (WAI), W3C, http://www.w3.org/WAI/

14. W3C, Scalable Vector Graphics (SVG), at http://www.w3.org/SVG/

15. W3C, Synchronized Multimedia Integration Language (SMIL), at

http://www.w3.org/SMIL/

16. XHTML™ 1.0 The Extensible HyperText Markup Language (Second Edition) -

A Reformulation of HTML 4 in XML 1.0, at http://www.w3.org/TR/xhtml1/

17. W3C, Cascading Style Sheets, at http://www.w3.org/Style/CSS/

18. W3C, Markup Validation Service, at http://validator.w3.org/

19

19. Webxact online web content test service for quality, accessibility, and privacy issues, at

http://webxact.watchfire.com/

20. Zaphiris P., Zacharia G., 2001. Website Content Accessibility of 30,000 Cypriot Web Sites.

In Proceedings of the 8th Panhellenic Conference on Informatics, November 8-10

20

New Accessibility Models: the Web Site of a Research Institute

Documents

Transcript of New Accessibility Models: the Web Site of a Research Institute