Making your website accessible.
However, many sites, including those for libraries, fall far short of meeting the minimum web accessibility standards. Whether the guidelines are from WebAIM, a project of Utah State University's Center for Persons With Disabilities (webaim.org); from Section 508 of the U.S. Rehabilitation Act of 1998, which mandates accessibility for government websites (section508.gov); from the W3C Web Accessibility Initiative with its policies from 19 countries (w3.org); or somewhere else, even some of the best designed and well-crafted library websites have barriers to access.
In a presentation at the Computers in Libraries 2013 conference, Casey Schacher, Paige Mano, and Tony Aponte reported on their usability study of U.S. library websites in a session titled Seven Deadly Sins of Websites. All the sites examined had issues with web accessibility from the smallest to the largest ones. If you're skeptical about these findings and think that libraries are doing a better job, take a couple of minutes to check a few library websites with an online accessibility evaluation tool such as Wave (wave.webaim.org). Keep in mind that tools such as this can spot many but not all types of accessibility issues.
While the task of creating an accessible site is not an onerous one, it also does not happen automatically. It requires thoughtful design, awareness of the issues, appropriate techniques and methods, and employment of these techniques consistently over time. Before leaping into suggestions on how to improve your sites, useful assessment tools, techniques, and methods, I'll take a moment to consider why current web practices are not working as well as they need to be.
Library websites come up short because they lack robust policies, have little knowledge about how people with disabilities use the technology, and don't know web development techniques and methods for building accessible sites.
First, determine if your library has a policy. Although many libraries have a policy, they often do little more than emphasize the importance of the standards. They do not state a specific level to be achieved, substituting, for example, the phrase "as accessible as possible." The policies do not define a measurable goal to compare a website against, and they allow the web team to determine if the standard has been reached.
To improve a policy, it must be official and indicate that compliance is required. It's not optional. The policy may also need to designate timelines. For new rollouts or major redesigns (50% of the pages are revised), compliance is required. All new content will comply on posting. For legacy content, there is a deadline in place for bringing it up to standards. Spelling out compliance requirements goes a long way toward making the policy real and actionable, but it can be strengthened by designating a system for monitoring, evaluating, and reporting the level of compliance over time. This is actually a critical step. The website can have dozens if not hundreds of contributors who are updating on a frequent basis. Ongoing compliance is necessary.
A policy helps drive action. When recruiting web team members, job descriptions should include requirements for skills and experience in developing accessible websites. Accessibility requirements should be part of project plans. Training and development should offer ways to gain knowledge and skills. When purchasing or licensing new software for website delivery of content or content management, require compliance with web accessibility standards.
RECRUITMENT AND TRAINING
Recruiting the right people is a key component. But most of us have a web team in place already. What can we do then? It's enough of a challenge designing a great site for users with whom you are familiar. When it comes to an audience relying on assistive devices, you have to take the time to learn how the users approach tasks on websites. If you don't know the needs of a particular user group, creating a site for those users is like driving down the highway at night with your headlights off and hoping you make it home. Make sure that all web team members have the opportunity to learn about accessible design.
Training and development of existing web development staff and all web content providers is a crucial step to creating an accessible site. For developers, this will focus on code, website structure, display, interactivity, and form-design techniques. Web authors will concentrate on content development and document/media structure. Team members also need time to observe and talk to device users. Find out what websites they like the best and why. Learn how they approach looking for information. Many libraries have assistive technology devices available for the public to use, giving you an opportunity right in your own library for firsthand learning. Make sure your website usability or beta testing also includes participants with disabilities.
IMPROVING WEBSITE ACCESSIBILITY
To improve website accessibility, label everything graphical that adds meaning. Almost all web teams know this rule but may forget to employ it. Providing an "alt" tag for an image helps someone using a screen reader to know what the image conveys. Otherwise, the graphic of your library logo might appear as a mystery image called "small.jpg."
So, you're confident that your website has all of its alt tags in place. What about content added since the last redesign? If those are in place, great, but don't assume that's the case. Check to make sure. Next, how well are the alt tags crafted? Do they focus on the function of the image, especially if it's a link? For example, use "Search the catalog" instead of "Image of magnifying glass" or "Search button." Are your labels brief? Short labels are better, a lot better. Reading more syllables takes more time. If you have an image that is a content-rich graphic, such as a bar chart or schematic, an explanation of the image is needed. Prior to using HTML5, the longdesc attribute for the img element was one way to include the longer description. This attribute is obsolete with HTML5. For infographics, make use of another HTML element to provide the explanation, such as a hyperlink.
If the image is meaningless or already explained by the surrounding context, simply use a space character in the alt tag rather than a "green spacer image." Extraneous image descriptions can interrupt the train of thought of someone listening to a screen reader. If you include the name of person in the alt tag for a photograph, such as Abraham Lincoln, for example, and that photo is immediately followed by a sentence starting with the same name, the screen reader would say, "Abraham Lincoln Abraham Lincoln, the 16th president of the United States ... "
MARKUP FOR ACCESSIBILILTY
Use HTML5 and ARIA (described in the next section) for markup. Make sure your team is creating standards-compliant code that uses semantic markup. If you mark up page headings semantically using h1 through h6, someone using a screen reader can skip through the headings on the page and find the useful section. Using bold, color, or font face to designate headings render these attributes invisible to a screen reader. WebAIM has a useful guide called Creating Semantic Structure (webaim.org/techniques/semanticstructure).
HTML5 adds some options that will improve image captions. You can make the relationship between an image and its caption explicit and not just dependent on proximity. I hope that more browsers will start supporting these new elements: <figure> and <figcaption>. They allow for the captioning of multiple images in a figure and improve readability. They will also make it possible to show computer program code blocks more effectively.
Using HTML5 and cascading style sheets (CSS) for page layout can add a tremendous boost to accessibility. Using tableless layout to structure the content is a major win. The key is to start with HTML5 and CSS, but realize that this does not automatically address all the needs of disabled users.
Keep in mind that web browser software developers implement HTML5 features at their own pace, so make sure the elements that you wish to use are implemented widely. The website on HTML5 accessibility is a great resource to see what browsers support which parts of HTML5 (html5accessibility.com).
Users of screen readers in particular have a better way to navigate sites that use ARIA landmark roles to designate areas of a page. By adding a role such as Banner, Navigation, or Main to semantically meaningful tags such as <header> and <footer> or semantically neutral tags such as <div>, screen readers can provide this information to users.
While semantically meaningful elements are ideal, it's possible to assign roles to generic elements such as <div> tags and indicate the beginning of a navigation area. Being able to traverse the page by jumping from section to section saves hours of time. ARIA roles are also defined for many interface widgets such as menuitem, menuitemcheckbox, progressbar, scrollbar, and sliders.
Here's an example of a document header using ARIA and Semantic HTML markup. In HTML5, the introduction to the page that includes logo, top heading, and navigation is enclosed in the <header> element. With ARIA you can designate this part of the page with role="banner." The following is an example of the two used in combination:
<header role="banner"> ... </header>
Although WAI-ARIA has not received final approval, there are many benefits to start using it now for web development. As more websites use dynamic controls and AJAX, ARIA offers a way to ensure that content is accessible. ARIA landmark roles are supported by NVDA and JAWS, VoiceOver, some web browsers, and other screen readers. Sites such as Yahoo!, BBC, and Google Search have implemented landmark roles.
Accessibility is not just a technical consideration. Everyone who contributes content to the website has a part in ensuring the site is accessible to a person with visual, cognitive, or other disabilities.
Here are a few key areas to start with when reviewing content. Look at the structure of pages on the site you create. Take a look at your LibGuide homepage. Ask yourself about the top tasks users wish to accomplish on a page. Focus on their goals as you structure the page, and surface the most important tasks first.
Consider how well the page hierarchy is constructed. Is the content chunked into meaningful easy-to-understand groupings? Can the user spot the signposts provided by headers and links and move quickly and nimbly through the page. Assuming the website template is well-implemented, someone can simply jump to where the webpage content starts and dive in. If you think this isn't important, imagine having to listen to your screen reader repeat the same 3 minutes of header information, navigation, or introductory information as each page loads.
VISUAL ELEMENTS OF SITE STRUCTURE
While you're looking at site structure, consider if you've used visual elements as the cues for headings rather than semantic markup. Are you using the position of the content to convey meaning that is not directly addressed by the content? For example, have you placed content in three columns, indicating a progression and relationships--a series of steps--but with the actual text not indicating this?
Make a list of labels, headings, and terms used in your site, not just on one page. Group the list by topic. Then scan your headings and navigational labels to check for redundancy and overlap. Clean up those that are too similar, unclear, or inconsistent.
Watch the use of jargon and acronyms. Remember there are new users to your library, city, college, and workplace. Newcomers have no idea what the cute name for your catalog is or the acronym for information resource, service, or library. By now, it's clear that many of the practices for making content accessible also are core components of making it usable.
Readability is a key part of accessibility. Concise, plain language works best. Does your website have a guideline for writing to a particular reading or grade level? Randomly testing a handful of public library sites' readability scores in the U.S. and Canada showed reading levels from grades 10.5 to 12. This is definitely a higher reading score than the average reading level for many members of the communities the libraries serve. Take a few minutes and find out the reading level of some of the key pages on your website using The Readability Test Tool (read-able.com).
There are dozens more techniques, tips, and tools that can help assess and improve your site's accessibility. I've touched on a few and included another half dozen in the sidebar. However, designing an accessible site requires the right mindset. It's more than just the tools, techniques, and policies. It means being inclusive from the very beginning. Every step you take in the process, you need to be mindful of universal access.
Library web teams have an opportunity to provide excellent accessible sites with online content and services for users with disabilities. For many years, users with screen readers would single out sites such as the BBC's (bbc.co.uk) as an example of a great site. Let's make sure our libraries are singled out as great sites to visit and use. Keep talking and thinking about inclusive design. Designing for accessibility helps all site users by improving the usability and ease of use of your site.
Tools to Help Make Your Website Accessible
Web Content Accessibility Guidelines (WCAG)
Fangs Screen Reader Emulator addons.mozilla.org/en-US/firefox/addon/fangs screen-reader-emulator
This Firefox extension simulates visiting websites with a screen reader. It helps sighted users to better understand what the experience is like.
NVDA (NonVisual Desktop Access) community.nvda-project.org NVDA is an open source screen reader for Windows operating system used in the visually impaired community.
Color Contrast Checkers
Juicy Studio Luminosity Colour Contrast Ratio Analyser juicystudio.com/services/luminositycontrastratio.php
Check My Colours
Color Blindness Simulator
Etre Ltd.'s Colour Blindness Simulator etre.com/tools/colourblindsimulator Here, you can upload an image or a screen shot of your page.
University of Saskatchewan
Darlene Fichter (email@example.com) is librarian, University of Sas-A katchewan Library.
Comments? Email the editor-in-chief (firstname.lastname@example.org).
|Printer friendly Cite/link Email Feedback|
|Date:||Jul 1, 2013|
|Previous Article:||What librarians need to know about EPUB3.|
|Next Article:||The Ebook Revolution: A Primer for Librarians on the Front Lines.|