Accessibility Testing LibGuides 2.0

Over the summer my library began investigating potentially migrating to the LibGuides content management system from our current, Drupal-based subject guide system.  As part of our investigation, and with resources from our campus’ Universal Design Center 1, I began an initial review to determine the extent to which LibGuides 2.0 was accessible to all users, including users with disabilities or those using assistive technologies.  Our campus, like other California State University campuses, has a strong commitment to ensuring technology is accessible to all users.  The campus has a fairly extensive process for acquiring new technologies that require all departments to review the accessibility of any technology or web-based product purchased, and the Universal Design Center assists all departments on campus with these evaluations.  While evaluating technology for accessibility is not typically my area of responsibility (in fact, I rarely have involvement in end-user facing technology, let alone testing for usability and accessibility), in this case I was interested in using LibGuides as an opportunity to learn more about accessibility for my own knowledge.  Ensuring that web content is accessible requires a blend of skills related to using web markup, understanding user behavior, and knowledge of assistive technologies, and as a librarian I know I can benefit from a solid understanding of all of these areas.

While I am by no means an expert on accessibility, I am familiar with basic guidelines of accessibility for content creation and markup. 2  Of course, accessibility and usability in a content management system depend, in large part, on the practices followed by content creators.  LibGuides authors have a significant amount of control over the accessibility of the content they create.  For example, using the HTML source code editing features of LibGuides, any guide author can ensure their own markup is compliant with accessibility guidelines, and manually add elements such as alternative text, titled iFrames, or ARIA attributes.  However, I was especially interested in identifying any issues that LibGuides guide authors could not easily modify themselves.  While many features can be overridden via the extensive CSS customization available in LibGuides 2.0’s Bootstrap Framework3, I wanted to identify those ‘out-of-the-box’ elements that posed accessibility problems.

The following issues identified below have been reported to SpringShare, and I was told by SpringShare support that all of these issues are being investigated and already ‘on the list’ for future development.  As this is my first attempt to really deep-dive into web accessibility, I’m really interested in feedback about the issues identified below.  I am hoping that I’ve interpreted the standards correctly, but I definitely welcome any feedback or corrections!


A sample guide was created in a LibGuides demo instance to evaluate all built-in LibGuides box types, content types, and various multimedia elements to determine Section 508 compliance.  The following features were included on the guide that was used for testing:

LibGuides Box Types:

  • Tabbed
  • Gallery
  • Profile

LibGuides Content Types:

  • Rich Text/HTML
  • Database
  • Link
  • Media/Widget
  • Book from the Catalog
  • Document/File
  • RSS Feed
  • Guide List
  • Poll
  • Google Search

Free tools used to evaluate LibGuides accessibility include:

  • W3C Markup Validator :  Valid markup is usually much more accessible markup.  Unclosed tags or nesting problems can often cause problems with screen readers, keyboard navigation, or other assistive technologies.
  • WebAIM WAVE Accessibility Tool – Enter the URL of your page, and the WAVE Tool will examine the page and automatically identify accessibility errors (elements, such as form labels, that are required for accessibility that are absent or problematically implemented), alerts (potential issues that could be improved) and features (good accessibility practices).
  • CynthiaSays – Similar to the WAVE tool, CynthiaSays automatically reads through the markup of a URL you provide and generates a comprehensive report of problems and potential issues.
  • Mozilla Firefox with the following extensions (there are likely Chrome alternatives to these):
    • Fangs – A screen reader emulator that enables you to view a text-only version of a page the way a screen-reader would read it.  Ensuring that your page is read by a screen reader the way you intend is essential for accessibility, and Fangs enables you to review the screen-readability of your page without downloading a full screen-reading desktop client such as JAWS.
    • WCAG Color Contrast Checker – A handy tool to quickly view the color contrast of your page in the browser.  Low contrast elements, such as yellow text on a white background, can be very different to see for a variety of users.   
  • Colour Contrast Analyser – A helpful desktop client that enables automated checking to ensure that web page elements or images contain high enough contrast to be viewed and read easily by a wide variety of users.
  • JAWS – JAWS is a very popular screen reading application that enables web pages to be navigated and read aloud to users.  While this software has a cost, a free trial can be downloaded temporarily to preview the software’s functionality.

Guidelines from the US Federal Government’s Section 508 Accessibility Program, W3C’s WCAG 2.0, and CSU Northridge’s Web Accessibility Criteria were used in this evaluation.


These features do not conform to Section 508 and/or WCAG 2.0 compliance, and their implementation in LibGuides does not enable guide authors to easily override code to improve accessibility manually.  

Polls: Lack clear labeling of form elements (Section 508 1194.22(n))

In our testing, Poll elements lack “FOR” attributes in tag labels and “ID” attributes in associated form elements.  Poll forms also make use of ‘implicit labels’, where the form element and its associated label are contained within opening and closing label tags.  For example, radio button code from a  poll element is generated by LibGuides as:

<div class="radio">
<input type="radio" class="pad-left-med" name="s-lg-poll-option-13342416" 
id="s-lg-poll-option-13342416_1" value="83823" >Never

More accessible code might instead look like:

<div class="radio">
<label FOR=”never”>Never
<input type="radio" class="pad-left-med" name="s-lg-poll-option-13342416" 
id="s-lg-poll-option-13342416_1" value="83823" ID=”never”>
Cover images from ‘Books from the Catalog’:  Lack textual description (Section 508 1194.22(a))

In testing, whether covers were retrieved from Syndetics, Amazon, or whether default (blue or white) covers were used, all resultant “Books from the Catalog” elements lacked ALT attributes.  Images do, however, have title elements.  It could be interpreted that these elements are decorative and therefore do not require alternative text elements.  However, the default title elements (derived from the title of the book) is not especially descriptive to help the user understand the role of the image on the page.

For example:

<img alt="" src=";
title="Getting It Right for Young Children from Diverse Backgrounds" 
class="pull-left s-lg-book-cover-img-0">

This code could be made more accessible with the following:

<img alt="Getting it Right for Young Children from Diverse Backgrounds 
Cover Image" 
title="Getting It Right for Young Children from Diverse Backgrounds" 
class="pull-left s-lg-book-cover-img-0">
Gallery Keyboard Accessibility and Tab Navigation Section 508 1194.21 (a)

In testing, it was not possible to navigate through gallery images using keyboard tab navigation alone.  While it was possible with tab navigation to bypass the gallery (tab into and out of it into the next page element) the user would not be able to control the movement of the gallery or tab through the gallery images to access the descriptions or captions of the gallery.

Gallery Default Label and Caption Color: Insufficient contrast and readability

FireFox’s WCAG Color Contrast Checker identified the white label and caption color of the “Gallery” box type as having insufficient contrast with many images that could be used in the gallery.  Because the label and captions appear directly overlaid upon gallery images, with no outline or background color to enhance the contrast of the text, these labels and captions can be difficult to read.  There does not appear to be a way in LibGuides administrative settings to adjust the default caption, though custom scripting might be used to override the style.

A screenshot of an example "Gallery" image in LibGuides. The example screenshot is of a cityscape in Israel.

Figure 1:  LibGuides gallery feature showing white label and caption that can be difficult to read against the gallery image.

Accessible Practices for Guide Authors:  A few tips

The issues identified above cannot easily be resolved through LibGuides administrative options or author controls, but there are several other important practices for guide authors to be aware of.  The tips below are by no means a comprehensive guide to accessibility; there are many more aspects to ensuring content is accessible (especially concerning the use of media, tables, and other types of content), but this list provides a few examples of things content creators can be aware of when creating guides.

Media/Widget Embed Codes:  Manually add title attributes to iframe elements

When embedding iframe media (such as a YouTube video, SoundCloud file, or Google Form) it is essential that Guide authors manually add a TITLE attribute to media embed codes.

Here is an example of a YouTube video’s embed code:

<iframe width="548" height="315" 
frameborder="0" allowfullscreen></iframe>

When adding code like this to a LibGuides Media/Widget feature, guide authors should manually add in a descriptive title element to briefly describe the contents of the embedded media:

<iframe title=”Video tutorial on finding a book at the Oviatt Library” 
width="548" height="315" 
frameborder="0" allowfullscreen></iframe>

Embedded media should also always include captions for visual media and transcripts for audio and visual media.

Rich Text/HTML Content: Add alternative text to all images

When manually adding images to RichText/HTML content, guide authors should be sure to add descriptive Alternative Text in the image dialogue box:

The LibGuides image upload dialogue menu, with a black box highlighting the input field for alternative text.

Figure 2:  LibGuides Image Properties Dialogue Box used to add images.  The Alternative Text field is highlighted.

Links:  Add title and aria-label attributes

When manually adding links to resources in LibGuides, ensure the purpose of the link is clear, either with title attributes or aria-label attributes.  Avoid, where possible, vague link text such as ‘Read More’ or ‘Click Here’. If link text is vague or there is no descriptive information about the link visible on the page, use a title attribute or aria-label attribute:

Link with title attribute:

<a href="" 
  title="Read about evaluating sources with the CRAP Test">
  The Crap Test

Link with aria-label attribute:

<a href="" 
  aria-label="Read more about evaluating sources">
  The Crap Test
Look and Feel:  Ensure text is visually distinct from background colors

When designing the look and feel of LibGuides, where possible, ensure a high level of contrast between text and background colors for readability.  For example, consider enhancing the text contrast on box labels, which by default have somewhat low contrast (dark grey text on light grey background).  

A screenshot of a default LibGuides tab heading reading "Profile Box", with dark grey text over light grey text.

Figure 3:  LibGuides default box header, showing low contrast between text in box and background.

A LibGuides box header with text reading "Profile Box" where the text contrast has been enhanced by making it black against a light grey background.

Figure 4:  LibGuides box header with font color set to #000000 in administrative Look and Feel settings.

For any element on the page, avoid using colors that do not have high contrast with background color features.

More Resources

Many LibGuides authors have created excellent guides to accessibility for guide authors at their institution, and SpringShare also provides an useful  guide for best practices for LibGuides content creators that covers some accessibility practices.  Here are a few resources from the LibGuides community that helped me enormously when doing this evaluation:

The ACRL Universal Accessibility Interest Group (UAIG) is currently exploring the formation of a subcommittee to review LibGuides accessibility and potentially create a more comprehensive guide to best practices for LibGuides accessibility.  You can join the UAIG through your ALA / ACRL membership to learn more about this initiative.

I would also love to hear from other who have done this kind of testing and found other issues.  Do you have a guide to best practices that covers accessibility?  Are you aware of other features in LibGuides that are not accessible to all users?  Comment here or tweet me @lpmagnuson.


  1. The mission of the Universal Design Center is “to assist the campus community in creating pathways for individuals to learn, communicate, and share via information technology.  Part of the mission is to help the campus community design-in interoperability, usability, and accessibility into information technology so that individual learning and processing styles, or physical characteristics are not barriers to accessing information.”
  2. For an excellent overview of web accessibility compliance, see Cynthia Ng’s articles on ACRL Tech Connect at,, and
  3. For a great example of the extensive customization that can be done in LibGuides 2.0’s Bootstrap framework, see