ltr: Vol. 48 Issue 7: p. 29
Chapter 4: Web Accessibility and Universal Design : A Primer on Standards and Best Practices for Libraries
Debra A. Riley-Huff
Abstract

As library users access more services through the Web, the importance of providing usable and accessible websites and content has come to the forefront of library service concerns. While libraries do have some unique use cases, for the most part simply following established standards and best practices in usability, accessibility, and universal design will allow libraries to offer clear and consistent Web services and interfaces. This chapter touches on the most important aspects of Web usability and accessibility and offers a basic roadmap for both increasing awareness and accomplishing concrete Web usability goals and accessibility compliance. In chapter 4 of Library Technology Reports (vol. 48, no. 7) “Making Libraries Accessible: Adaptive Design and Assistive Technology” we will look at the basics of Web accessibility, learn how to create and upgrade static websites, and discuss accessibility best practices in modern content management systems such as Drupal or WordPress.
About the Author

Debra Riley-Huff is currently Web services librarian and associate professor at the University of Mississippi. She is the 2012–13 convener for the LITA Universal Accessibility Interest Group. Riley-Huff has written several articles related to Web services and is a strong advocate of universal design, open access, and open source technologies. She holds an MLIS and an MS in instructional design and technology from Emporia State University.

Library websites serve the information needs of extremely diverse populations. This fact challenges us to provide state-of-the-art Web services in terms of both usability and accessibility. Luckily, this challenge is surmountable. In this chapter, we will look at the basics of Web accessibility, learn how to create and upgrade static websites to achieve better usability, and discuss accessibility best practices in modern content management systems.

The Basics: What to Know and Why

Considering the core values of the profession, website accessibility in libraries should be, simply stated, a given. It is the right thing to do, not only for people with disabilities but for all users. It is well known among Web developers that websites that are accessible are also much more usable for everyone.1

We often hear Web accessibility come up in an organization’s discussions regarding liability and fear of exposure to litigious actions by individuals who are unable to access Web content. While this is certainly a valid concern, Section 508 of the Americans with Disabilities Act has resulted in a less-than-definitive legal landscape, which is difficult to interpret at best.

Camilla Fulton gives us an excellent overview of the tangled and regional legal scenarios surrounding Web accessibility for those interested.2 Rather than dwell on the fine details of what you need to be doing legally, you can leave that type of discussion to your organization’s legal counsel and focus on moving forward with the business of making your library’s website more usable and accessible. The result of your efforts will greatly ease any legal concerns.

Know the Standards

The first step on the path to an accessible website is becoming familiar with Web accessibility standards. Web standards in the areas of accessibility and usability have a fairly easy-to-follow path that should make accessibility on your website a reachable goal. Your main constraints will be the size of your site and the human resources you have available to get the work completed, but there are many resources listed throughout this chapter that will help you along the way. One such resource is the Web Accessibility Evaluation Tool (WAVE, see figure 4.1), a free site that allows you to plug in your library website’s URL and see specific accessibility problems in your code—give it a try and see what you find. This and other evaluation sites are listed in the Tools and Tests section later in the chapter.

WAVE: Web Accessibility Evaluation Tool

wave.webaim.org

The current standards for Web accessibility are known as the “guidelines” made available through W3C’s Web Accessibility Initiative, known as the Web Content Accessibility Guidelines, or WCAG 2.0. WCAG 2.0 is itself a lengthy set of standards that have been made more useable and easy to follow by the WAI companion website. The WAI website is an up-to-date, authoritative, and invaluable resource outlining Web accessibility standards.

Web Content Accessibility Guidelines (WCAG) 2.0

www.w3.org/TR/WCAG

Web Accessibility Initiative website

www.w3.org/WAI

Know the Community

To the extent that it is possible, know your user community. Too often, the user narrative and the importance of simplicity are overlooked in Web interface design. While a flashy, tricked-out website seems to be what everyone wants, in reality information seekers are on task and they appreciate simplicity, simple designs, and straightforward workflows. Move away from the approach of building separately for disabled users, and concern yourself with creating clean, beautiful, usable, and accessible websites.

Remember that the user is never the problem—the website is—and it is your job to create a great user experience. Help the rest of your library staff understand that Web accessibility is important, and have them let you know of any issues or problems they see users encountering on the website. Have an accessibility statement on your website, and provide a contact form for users with questions or problems. Being accessible to your users is a great way to bring enhanced understanding to your site building experience. A couple of examples of excellent accessibility statements are listed in the gray box.

Randolph Township Free Public Library Accessibility Statement

www.randolphnj.org/library/accessibility_statement

University of New Brunswick Libraries Web Accessibility Statement

www.lib.unb.ca/help/accessibility.php

Know the Tools Your Community May Be Using

As Chris Guder points out in chapter 2, the assistive technology tools that people with disabilities use to access Web content are varied and can be complicated to learn. People have a wide range of disabilities, and almost everyone will have some type of accessibility issue at some point in their lives. Be aware that your users, depending on their situation, may be in the process of learning their own tools—this reality only serves to emphasize the need for Web standards for all.

The most prominent Web accessibility tool is the screen reader, software that interprets the screen display in audio or braille format. Doing some research on the various types of screen readers and how they work is worthwhile, as is testing your site in a screen reader (again, refer to chapter 2 for specific examples of assistive technology). In addition to screen readers, the visually impaired often use magnification tools.

Most primary and secondary schools, municipal governments, and higher education institutions have some type of office of disability services. Familiarize yourself with the resources available to disabled users in your community. Often, these offices will be more than happy to show you how the assistive technology works and even allow you to do some testing. Understanding how disabled users are actually accessing your website is a great way to have a broad workable understanding of how to maximize your website accessibility.

Where to Start
Usability and Accessibility Start with Your Content

Writing for the Web is an art, and the style is minimalism. This is an area where you may have problems, particularly if you do not have the authority to control, monitor, or intervene in bad content creation. Being succinct, chunking content, using headers, and writing in absolutely clear language on the Web are much more important than they may be in other contexts. As a rule, avoid the use of idioms, nuanced language, and double meanings. Your goal should literally be understandability.

Jakob Nielsen, an expert on Web usability, offers the useit.com website to those who care about website usability and writing for the Web. Taking some time to understand the concepts of information transfer on the Web is very worthwhile, and it would be advisable to offer workshops or instruction to your Web content creators in order to ensure that your content is usable and accessible. Web content also provides tools for accomplishing tasks. Studies have shown that users who have difficulty accomplishing a task, such as using a form, are unlikely to use your website again.3

useit.com

www.useit.com

The Nuts and Bolts: Markup and Code Compliance

The way your website is built ultimately determines if it is accessible. Before we go into the nitty-gritty of cleaning up or building accessible websites, there are a few salient points to cover right away:

  • Building accessible websites or rebuilding inaccessible ones takes time and effort. How big the project will be depends on many factors, including skills, tools, and human resources available. Try to get full administrative support in this area.
  • Identify problems. If you need to evaluate the accessibility of an older website, you will first need to identify your problem areas. The Tools and Tests section of this chapter provides more information for evaluation.
  • Flash websites are for the most part inaccessible. There are ways to make Flash websites accessible, but they are expensive and difficult. In addition, Flash is heavy to load, and the code is of poor quality. Whenever possible avoid Flash for your content as well. If you have legacy materials in Flash, think about converting them to a more accessible format soon. Don’t purchase Flash-based content from vendors that do not have an accessible counterpart.
  • Know HTML and CSS. If you are building websites using the “design mode” of an editor because you are not comfortable with HTML and CSS, stop and learn them (or bring someone who knows them well into the project). You cannot possibly build quality, accessible websites in design mode, regardless of what a product evangelist tells you. In order to create accessible websites, you must be able to separate presentation from content, and you need to know what is going on in your markup and how to identify problems.

Two very good and free beginner HTML and CSS learning sites are listed in the box below.

W3Schools

www.w3schools.com

HTML.net

www.html.net

  • JavaScript is not our enemy. JavaScript does not render pages inaccessible, and both JavaScript and its lighter cousin jQuery are wonderful ways to add interactivity to a website. The simple rule is, don’t require JavaScript for anything on your website. JavaScript should enhance your website, not run it. If a user cannot access something or complete a task with JavaScript turned off, then you are not using JavaScript appropriately or in an accessible way.
Follow a Proper Document Model and Create Semantic Structure

Following a proper document model is the cornerstone of accessible website building. The document model is simply the proper structure of a Web document. It is the HTML element skeleton of the site. Following the correct document model hierarchy of elements is so important because that is what screen readers are relying on when they traverse your webpages for content. Imagine reading a book where the pages are out of order or misnumbered or the chapters are out of place.

It is important to understand firsthand how users with print disabilities interact with Web content. S. G. Ranti Junus, the author of the previous chapter, conducted a large-scale accessibility assessment of e-resources at the Michigan State University Libraries. She has provided two captioned, split-screen video examples of a blind user encountering e-resources features on the MSU Libraries website using a screen reader (see URLs in the gray box; figure 4.2 is a still from Video 1). You can watch these brief videos to gain perspective on how screen readers work, as well as the frustrations improper semantic structure and other accessibility issues can create for users with disabilities.

  • Video 1. In this video, the user tries to type a keyword search into a search box. While the coding of the form is apparently correct, something goes wrong between the form and the screen reader, and she is stuck with an unworkable form. Fortunately, she manages to discover a workaround by reloading the search form.
  • Video 2. In this clip, a user types a keyword search on the MSU Libraries’ Electronic Resources page and receives a Not Found result. Because of the way the page is labeled, she has a difficult time determining its context. Design note: The way the search box is shown on the Search Result page is apparently different from her expectation. In other pages, the search box (or what she and JAWS call the Edit Box) is displayed first, followed by the Submit button. On this Not Found result page, it’s the other way around.

Video 1

http://tinyurl.com/screenreader1

Video 2

http://tinyurl.com/screenreader2

These two videos provide some insight into how browsers and screen readers “see” your website and the issues this can create when you don’t follow the correct document model. Not everyone can use a mouse, and some users will be depending upon your proper use of headings, paragraphs, and other HTML elements to navigate your site. Research has reported that the proper use of header elements on a website can decrease “lostness” and speed screen reader users on to find needed content by as much as 50 percent.4 Other parts of your document include links, which should always describe themselves; for example, “Click here” is meaningless, but a link that says “Learn how to create a proper link” tells the user what the content will be at the target destination.

HTML5 is a new document standard that is preferable because it is inherently more accessible. There are more HTML elements, and they are named in ways that both make sense and are machine-readable for modern browsers. If you are building a new website or Web application, it would be best practice to use HTML5.

Piece by Piece: The Things That Make Up Your Web-Delivered Content

While it is not within the scope of this chapter to cover every aspect of a website in great depth, we can briefly discuss the main areas where accessibility problems occur and techniques for making these elements accessible.

  • Navigation and menus
    • Start your pages by including a link that can take screen reader users directly into the content of the page. While Skip Navigation links have traditionally been hidden, Web developers are moving towards viewable skip links because they are also handy for sighted users and those with dexterity problems. Here is an example of skip navigation markup that is usable by everyone:
      • <a href=“#content”>Skip to Content</a>
      • <a name=“content” tabindex=“-1“></a>
    • When creating site menus, all users prefer shallow, broad menus.5 Drop-down and flyout menus (see figure 4.3) can cause usability problems for several reasons, including an inability to maintain the cursor in the target area.
    • Don’t create navigation structures in JavaScript without graceful fallback behaviors, such as having accordion lists default to open when JavaScript is disabled.
  • Text and fonts
    • Text presentation should be “chunked” with no more than one idea per paragraph.
    • Bulleted and numbered lists are a very good way to present list content and set points apart.
    • Font sizes on the Web should never be less than the equivalent of 12 pixels, should be presented in relative units, and should always consist of easily readable fonts.
    • Have only a few font types on your website.
    • Refrain from inappropriate use of bold and italic fonts, and remember that all-caps fonts are almost never appropriate and are very hard for some people to read.
    • Text presented in an image is not accessible and must be described; hence, it is not a good practice.
    • Moving, wavy, and blinking text is certainly to be avoided.
    • Make certain that you have good contrast on your website. Contrast is the difference in color or density between the background and foreground. Black on white is an example of good contrast, while purple on dark blue would surely result in poor contrast.
  • Color
    • Many people are color-blind, especially in the areas of blue, green, and red. Do not use color to convey meaning. For example, a website warning in red should properly read, “Warning: This content will make you laugh.”
  • Images
    • Images must always be described though the use of descriptive “alt attribute” tags that use words to convey the meaning of a visual. Alt tags are contained within images and appear as the following in code:
      • <img src=”ballon.png” alt=”an orange balloon floating in the sky”>
    • Try to create a meaningful alt tag, and remember that while what is in the image is important, so is the context. If there is something important about the image that tells a story, you must convey that.
      • For example, rather than describing an actionable image as “a woman and a boy,” you would say, “a distraught woman crying with a sympathetic young boy in the background looking at her.” A group of blind users from the REACH Center for the Blind in Tupelo, Mississippi, evaluated a particular website and reported, “We really appreciated the rich descriptions in the alt tags, it gave the site so much more meaning and felt really friendly to us.”6
  • Documents
    • The documents you deliver from your website should be accessible. This includes PDF, Text, and Slide formats.
    • Each format has its own accessibility methods and tools built in, and they must be used properly.
      • For example, in PDF documents, text scanned as an image is not accessible, but it can be transcribed or put through optical character recognition software, such as Readiris or ABBYY FineReader.
    • Microsoft Word and PowerPoint have accessibility features; you can learn about those and implement the use of them at your organization.

Readiris

www.irislink.com/c2-2115-189/Readiris-14--OCR-Software--Scan--Convert---Manage-your-Documents-.aspx

ABBYY FineReader

http://finereader.abbyy.com/professional

  • Rich media applications
    • Rich media such as audio, video, and mixed-media presentation materials are best dealt with on a case-by-case basis.
    • Video should always be captioned, and all multimedia should have a fully described transcription when appropriate. YouTube’s video captioning service announced in early 2012 that it has made big improvements by supporting more caption file formats and is now allowing you to modify your automated captions. 7
Tools and Tests
Resources to Help Your Organization Achieve Compliance

There are many free resources to assist you with your quest for website accessibility in your library. A few important ones are listed here.

  • The Web Accessibility Initiative website. This is a comprehensive resource on Web accessibility, offering guidelines, techniques, project planning, presentations, and tutorials.
  • WebAIM. The Web Accessibility in Mind (WebAIM) website, sponsored by Utah State University, offers extensive resources including in-depth articles on specific Web accessibility objectives and on-site training opportunities.
  • useit.com. This is usability expert Jakob Nielsen’s website, offering a plethora of usability articles, reports, and news.
  • iCITA. The Illinois Center for Information Technology and Web Accessibility offers useful guidelines and extensive information, roadmaps, and implementation samples for WAI-ARIA (see overview below).

Web Accessibility Initiative website

www.w3.org/WAI

WebAIM

http://webaim.org

useit.com

www.useit.com

iCITA Testing Resources

http://test.cita.illinois.edu

Testing Tools and Services

When testing your website, if you have followed best practices, you do not need to test all of it, but you do need to test much more than just the home page.8 It is important to test at least one page in each area of significantly different content on your site. Testing tools range from do-it-yourself testing sites to browser plugins and toolbars to professional evaluation services. A few important resources are listed here.

  • WAVE. Provided by WebAIM, WAVE is an online accessibility tool that allows you to enter the URL of any website you would like to evaluate. WAVE also offers a Firefox toolbar and Dreamweaver extensions.
  • FAE. The Functional Accessibility Evaluator is an advanced Web-crawling evaluator sponsored by the University of Illinois.
  • Browser plugins. There are numerous browser plugins available to monitor your website’s accessibility.9 The best of these include Fangs for Firefox and ChromeShades for Google Chrome.

WAVE

http://wave.webaim.org

FAE

http://fae.cita.uiuc.edu

Fangs Screen Reader Emulator

https://addons.mozilla.org/en-us/firefox/addon/fangs-screen-reader-emulator

ChromeShades

https://chrome.google.com/webstore/detail/hlklboladblmgfpkenhlgbhoojdlfoao

Beyond the Basics
What Mobile Means for Accessibility

The increasing importance of developing websites for mobile devices has had an extremely positive impact on accessibility.10 Everything about designing for mobile works for accessibility, and this includes minimalism, touch accuracy, speed, HTML5, semantic markup, and graceful fallback solutions. Having your website be mobile-first or mobile-ready is an excellent goal and will greatly increase its accessibility.

Accessibility Concerns in Modern CMS Applications and Frameworks

Many libraries now have some or all of their websites contained in content management systems (CMSs). If you are using a proprietary CMS, such as ExpressionEngine, check with your vendor and test it yourself for accessibility compliance. If you are using an open source CMS, such as Drupal, WordPress, or Joomla!, the best way to achieve accessibility is to use the most accessible version and then choose an accessible, responsive HTML5 barebones theme for your site. Often, Googling the name of your CMS plus “accessible theme HTML” will bring up a list of accessible themes, often accompanied by a chart showing exactly what is offered, as well as pros and cons. You can use the theme as is, or you can subtheme that theme in order to customize it for your own website. This requires advanced Web development skills, so you may need to have your custom theme built by an open source shop that specializes in theming for your particular CMS, or better yet, partner with other libraries or open source Web developers that are working on the same problem. E-mail lists like Web4Lib, Code4Lib, Drupal4Lib, and WP4Lib are useful sources of information, inspiration, and assistance.

WAI-ARIA: A Quick Overview

Anyone getting involved in Web accessibility will encounter W3C’s Web Accessibility Initiative resource known as Accessible Rich Internet Applications Suite (WAI-ARIA), mentioned already in the Tools and Tests section of this chapter. WAI-ARIA essentially defines a way to make dynamic content more accessible through the use of semantic Web technologies that specifically target assistive technology. Many browsers and assistive technologies are beginning to implement WAI-ARIA, and while the discussion is ongoing and implementation is not complete,11 many advanced Web developers are beginning to use the technology successfully.

WAI-ARIA Overview

www.w3.org/WAI/intro/aria

Conclusion and Further Thoughts

This chapter has provided a primer and basic understanding of the myriad factors that go into website accessibility. By starting with a good project plan, gathering administrative support, and moving through the steps I have outlined to achieve compliance with the aid of the multitude of resources that are available, you will make your website not only accessible, but faster, more discoverable, and more usable by all.

Recommended Resources
Notes
1. Eyadat, Mohammad; Lew, Jeff. “Web Accessibility Factor a Key Focus for Serving Students,”Review of Business Research March 2011;11(no. 2):80.
2. Fulton, Camilla. “Web Accessibility, Libraries, and the Law,”Information Technology and Libraries March 2011;30(no. 1):34–43.retrieved from http://0-search.ebscohost.com.umiss.lib.olemiss.edu/login.aspx?direct=true&db=lxh&AN=58478965&site=ehost-live&scope=site
3. Lee, Sangwon; Koubek, Richard J. “The Effects of Usability and Web Design Attributes on User Preference for E-commerce Web Sites,”Computers in Industry May 2010;61(no. 4):329–341.doi:10.1016/j.compind.2009.12.004
4. Hochheiser, Harry; Lazar, Jonathan. “Revisiting Breadth vs. Depth in Menu Structures for Blind Users of Screen Readers,”Interacting with Computers September 2010;22(no. 5):389–398.doi:10.1016/j.intcom.2010.02.003
5. Ibid.
6. Malinda L. Wimbs, Debra Riley-Huff, and James Kelleway, live in-person website evaluation conversation at REACH Center for the Blind in Tupelo, Mississippi, July 13, 2010.
7. Harrenstien, Ken. , “YouTube Blog: Captions for All,”. retrieved from http://youtube-global.blogspot.com/2012/02/captions-for-all-more-options-for-your.html
8. Hackett, Stephanie; Parmanto, Bambang. “Homepage Not Enough When Evaluating Web Site Accessibility,”Internet Research 2009;19(no. 1):78–87.doi:10.1108/10662240910927830
9. McHale, Nina. “Browser-Based Accessibility Evaluation Tools for Beginners,”Journal of Web Librarianship 2011;5(no 4):334–343.doi:10.1080/19322909.2011.623646
10. Gajos, Krzysztof; Hurst, Amy; Findlater, Leah. “Personalized Dynamic Accessibility,”Interactions March/April 2012;19(no. 2):69.
11. Linaje, Marino; Lozano-Tello, Adolfo; Perez-Toledano, Miguel A.; Carlos Preciado, Juan; Rodriguez-Echeverria, Roberto; Sanchez-Figueroa, Fernando. “Providing RIA User Interfaces with Accessibility Properties,”Journal of Symbolic Computation February 2011;46(no. 2):207–217.doi:10.1016/j.jsc.2010.08.008
Figures

[Figure ID: fig1] 		Figure 4.1 

The Web Accessibility Evaluation Tool (WAVE).

[Figure ID: fig2] 		Figure 4.2 

Still image from MSU Libraries screen reader usability-testing video.

[Figure ID: fig3] 		Figure 4.3 

Example of problematic “drop-down flyout” menu. Image from SuggestSoft.com, “jQuery Drop Down Menu Style 2 1.5,” accessed May 21, 2012, www.suggestsoft.com/soft/apycom-jquery/jquery-drop-down-menu-style-2.
Article Categories:
  • Information Science
  • Library Science

Refbacks

  • There are currently no refbacks.


Published by ALA TechSource, an imprint of the American Library Association.
Copyright Statement | ALA Privacy Policy