Aleph - Web Opac Accessibility. Accessibility in Aleph500 Web OPAC

Size: px

Start display at page:

Download "Aleph - Web Opac Accessibility. Accessibility in Aleph500 Web OPAC"

Marcia Fowler
6 years ago
Views:

1 Accessibility in Aleph500 Web OPAC 1

2 CHANGE CONTROL Version Date Author Description Initial draft - v Version for release - v Updates v18 initial draft Updates v18 draft 2

3 CONTENTS 1. Introduction 2. Usability 3. Accessibility 4. Additional general points (Janet Arth) 5. Notes about International standards 6. Links 3

4 1. INTRODUCTION The analysis of accessibility in Aleph Web OPAC has to be developed in different ways, in order to meet users needs. Users needs concern: the accessibility of the layout (according to W3C -WAI recommendations, Section 508 of the Rehabilitation Act (29 U.S.C. 794d), International legislation); the usability of the layout and the contents (keywords: simplicity, clarity and easiness); the compatibility of the interface with any browser (e.g. old browsers, text-only browsers), any operating system and any PC (e.g. old 14" monitors and 12" monitors of the newest notebooks, slow internet connections). Accessibility and compatibility can be evaluated with many tools and software (for instance W3C validators or AnyBrowser.com tools), but usability can be verified only by human beings, so it is the most difficult goal to reach. The first step is an analysis of usability, in order to create a new layout; the second step is to make the new layout accessible. 2. USABILITY In human-computer interaction and computer science, usability usually refers to the elegance and clarity with which the interaction with a computer program or a web site is designed. From Wikipedia, the free encyclopedia The default layout of Aleph Web OPAC of both v16 and v18 is based on tables and horizontal bars which contain heterogeneous information. We decided to split the screen in main areas: different arguments in the same area could be a bit confusing. The result is the following layout: TITLE FEEDBACK BAR (warnings, announcements, ) MENU BODY The default page was a login form: the most part of our users wants to browse the catalogue first, they log in only when they place hold requests or renew loans. We decided to show as 4

5 home page the basic search, that is the most visited page. We added descriptions about some functions: firstly in the alt attribute of HTML tag link, then in Help & FAQ or in a special page: for example we added a page in which we explain the meaning of the available searches: some users don t know what CCL search is and in this page they can find a short description. Our aim was to make the web OPAC as clear as possible: information are important but if too much information are given at the same time they could be lost. 3. ACCESSIBILITY Accessibility is a general term used to describe the degree to which a system is usable by as many people as possible. In other words, it is the degree of ease with which it is possible to reach a certain location from other locations. It is not to be confused with usability which is used to describe how easily an entity (e.g., device, service, environment) can be used by any type of user. From Wikipedia, the free encyclopedia The documentation of both v16 and v18 says that Aleph Web OPAC now meets level A of WAI, but there is no mention about technical solution or accessibility standards: W3C recommendations, WAI, WCAG and US legislation (section 508). It would be useful if Ex Libris could provide customers with some documentation about the compliance of the web OPAC with Section 508 and WAI Guidelines. In v18 the documentation says that the doctype declaration has to be inserted in a list of pages: in fact the doctype declaration (HTML 4.01 transitional) has already been inserted in the file listed. The conclusion is that many but not all pages are using HTML 4.01 transitional Non standard HTML and CSS code The OPAC structure has been radically changed in Aleph v16 in comparison with v14, but it is not fully standard yet. From v16 to v18 some new functionalities and new pages has been added, but the layout is the same as v16. The layout in both v16 and v18 is defined using Cascading Style Sheets, but it is not standard too. Online HTML and CSS validators fail because of some errors in the code. The critical errors are: No doctype declaration (without doctype the page cannot be validated) this has been fixed in v18 (HTML 4.01 transitional); Tag nesting errors (some old browsers and textual browsers could not display the page correctly); Use of deprecated or obsolete tags (e.g. font ) and attributes (e.g. attribute border in tag img ); this has been partially fixed in v18 Use of non standard attributes (proprietary attributes?), e.g. topmargin in tag body (some old browsers and text-only browsers could not display the page correctly); this has not been fixed in v18 Some CSS classes simulate tag attributes (e.g. #bold: {font-weight:bold} instead of tag b or em ); 5

6 this has not been fixed in v18 Some attributes should be defined in CSS not in the code (attribute border in tag img ). this has not been fixed in v18 Other errors: Mistakes in the definition of JavaScript; this has not been fixed in v18: attribute type is still missing In both v16 and v18 there are many javascripts which create the correct screen to be displayed: some browsers could not display the page correctly; Typos in html code; Some mistakes about quotation marks and capital letters in HTML code; this has not been fixed in v18 Web OPAC functions such as func=file&file_name=login could not be processed by validation parser. The problem can partially solved using the code & instead of ampersands, but system-created code cannot be fixed; this has not been fixed in v18: ampersands are still like & 3.2. Files and variables Every screen is composed by a number of files that fit into place automatically when they are called by Web OPAC functions. An interface like this is very complex to manipulate: the most important question concerns the includes : they are not standard Apache SSI includes, although they work in a similar way. Their behaviour depends on some programs in which are also defined functions and variables. Many screens are composed by variables only and the code is created automatically: it is locked and cannot be modified. Because of that XHTML is not suitable for web OPAC (both in v16 and in v18): XHTML, even if you choose the Transitional DTD, the code must be clean and must respect all the W3C standards. XHTML takes some rules from XML: tag nesting and the closures are very different from HTML, so you risk to have a mix of two codes in the same page. Old browsers or textonly browser could misinterpret the code Tables Web OPAC structure of both v16 and v18 is made up with tables. This usage of tables is not recommended by W3C: tables should not be used to format pages or forms, they should be used to present tabular data. Using tables to format pages often implies changing the span of cells and/or columns: in this case rendering may vary according to the browser in use. Tables could give some problems with text-only browsers and screen readers: these tools parse tables as a set of data, so, for example, text-only browsers could show hidden borders changing the global appearance of the page. Tables can help to keep the layout tidy, but we reached the same goal using divpositioning, fieldset, lists and boxes. Boxes can be positioned in a simply way using CSS and HTML tag div, and the page can be clearly viewed by text-only browsers or by the people who replace the CSS of the OPAC with a customized one Access Keys Some accessibility features, such as Access Keys, are not implemented in the default version of the web OPAC of both v16 and v18 and have to be added by the webmaster. It is a heavy duty to add and maintain them, it would be very useful if Ex Libris could add Access Keys in the default version, as they did with Aleph GUI. 6

7 4. ADDITIONAL GENERAL POINTS (Janet Arth) 4.1. Use of mouse It should be possible to navigate without the use of a mouse, i.e., solely with the use of single keystrokes. Limited testing indicated that this is at least partly true in ALEPH. But this should be a part of testing of the user interface for the OPAC Test with screen readers This should be a part of testing of the user interface Screen readers and header links The OPAC should provide a way to skip over all the header links to get to the core page content, e.g., a hidden link near the top of the page that lets users with screen readers quickly get to the search box or results (to some anchor down the page). If one test with a screen reader, it is quickly apparent that rehearing all the head-* information again and again is very monotonous Browser back button The "Back" button should work consistently and should be available on all windows where "back" is relevant Pop-ups The OPAC should minimize use of pop-ups (legitimate uses of pop-ups is to provide information that needs the context of the originating page, e.g. help, links to e-resources), and provide a close button/link larger than the red X/red circle Horizontal scrolling The OPAC should try to eliminate horizontal scrolling: Users really don't like horizontal scrolling and pages that require both vertical and horizontal scroll is problematic for users with poor visual/spatial skills). Avoid "frozen layout", aka fixed width, no matter what is displayed this means that large monitors using full screen are underutilized; and those with smaller monitors or using large monitors to have multiple windows open, have to do the horizontal scroll. The biggest horizontal scrolling problem in ALEPH that we have seen is when there are long URLs and the user is using Firefox 4.7. Hand held devices Jakob Nielsen suggests a different interface is needed for cell phones and other handhelds, as they are so different. The time has probably come for this to happen. 5. NOTES ABOUT INTERNATIONAL STANDARDS World Wide Web standards are defined by W3C (World Wide Web Consortium), an independent organisation which develops technologies to made web accessible. W3C defines the specifications for different web programming languages (such as HTML, XHTML, XML, CSS, etc.) and develops accessibility softwares and tools (e.g. X/HTML and CSS validators). W3C supports WAI, Web Accessibility Initiative, which develops WCAG Guidelines (Web 7

8 Content Accessibility Guidelines) and other resources to make web accessible. W3C - WAI work is still on progress: standards, documentation and guidelines are constantly updated to follow the latest technologies (e.g. new versions of browsers, web navigation with mobile phones and PDAs, etc.). Recent updates: HTML has reached version 4.01 (stable version). It has been reformulated in XML to obtain XHTML; XHTML has reached version 2.0 (working draft); CSS has reached version 2 revision 1 (2.1, working draft) and version 3, an extension of version 2 about text manipulation, is now under development; WCAG Guidelines have reached version 2.0 (working draft, may be completed in 2007); 5.1. Italian legislation In 2004 Italian government published a law called Legge Stanca to support the access to information technologies for disabled people. Legge Stanca describes accessibility obligations and lists some web accessibility guidelines about doctype, colours, images and other technical requirements based on International standards such as W3C recommendations, WAI, WCAG and US legislation (section 508). 6. LINKS Web OPAC Bicocca Insubria: W3C World wide Web Consortium: WAI Web Accessibility Initiative: W3C Validators and other tools: US Legislation (Section 508): English translation of Italian Legislation: 8

Accessibility of EPiServer s Sample Templates

Accessibility of EPiServer s Templates An evaluation of the accessibility of EPiServer s sample according to current recommendations and guidelines elaborated by the World Wide Web Consortium s (W3C) Web