Getting Closer to Accessible Carousels

Carousels are a popular website feature because they allow one to fit extra information within the same footprint and provide visual interest on a page. But as you most likely know, there is wide disagreement about whether they should ever be used. Reasons include: they can be annoying, no one spends long enough on a page to ever see beyond the first item, people rarely click on them (even if they read the information) and they add bloat to pages (Michael Schofield has a very compelling set of slides on this topic). But by far the most compelling argument against them is that they are difficult if not impossible to make accessible, and accessibility issues exist for all types of users.

In reality, however, it’s not always possible to avoid carousels or other features that may be less than ideal. We all work within frameworks, both technical and political, and we need to figure out how to create the best case scenario within those frameworks. If you work in a university or college library, you may be constrained by a particular CMS you need to use, a particular set of brand requirements, and historical design choices that may be slower to go away in academia than elsewhere. This post is a description of how I made some small improvements to my library website’s carousel to increase accessibility, but I hope it can serve as a larger discussion of how we can always make small improvements within whatever frameworks we work.

What Makes an Accessible Carousel?

We’ve covered accessibility extensively on ACRL TechConnect before. Cynthia Ng wrote a three part series in 2013 on making your website accessible, and Lauren Magnuson wrote about accessibility testing LibGuides in 2015. I am not an expect by any means on web accessibility, and I encourage you to do additional research about the basics of accessibility. For this specific project I needed to understand what it is specifically about carousels that makes them particular inaccessible, and how to ameliorate that. When I was researching this specific project, I found the following resources the most helpful.

The basic issues with carousels are that they move at their own pace but in a way that may be difficult to predict, and are an inherently visual medium. For people with visual impairments the slideshow images are irrelevant unless they provide useful information, and their presence on the page causes difficulty for screen reading software. For people with motor or cognitive impairments (which covers nearly everyone at some point in their lives) a constantly shifting image may be distracting and even if the content is interesting it may not be possible to click on the image at the rate it is set to move.

You can increase accessibility of carousels by making it obvious and easy for users to stop the slideshow and view images at their own pace, make the role of the slideshow and the controls on the page obvious to screen reading software, to make it possible to control the slideshow without a mouse, and to make it still work without stylesheets. Alternative methods of accessing the content have to be available and useful.

I chose to work on the slideshow as part of a retheming of the library website to bring it up to current university branding standards and to make it responsive. The current slideshow lacked obvious controls or any instructions for screen readers, and was not possible to control without a mouse. My general plan in approaching this was to ensure that there were obvious controls to control the slideshow (and that it would pause quickly without a lot of work), have ARIA roles for screen readers, and be keyboard controllable. I had to work with the additional constraints of making this something that would work in Drupal, be responsive, and that would allow the marketing committee to post their own images without my intervention but would still require alt tags and other crucial items for accessibility.

My Approach

Because the library’s website uses Drupal, it made sense to look for a solution that was designed to work with Drupal. Many options exist, and everyone has a favorite or a more appropriate choice for a particular situation, so if you are looking for a good Drupal solution you’ll want to do your own research. I ended up choosing a Drupal module called Views Slideshow after looking at several options. It seemed to be customizable enough that I was pretty sure I could make it accessible even though it lacked some of the features out of the box. The important thing to me is that it would make it possible to give the keys to the slideshow operation to someone else. The way our slideshow traditionally worked required writing HTML into the middle of a hardcoded homepage and uploading the image to the server in a separate process. This meant that my department was a roadblock to updating the images, and required careful coordination before vacations or times away to ensure we could get the images changed. We all agreed that if the slideshow was going to stay, this process had to improve.

Why not just remove the slideshow entirely? That’s one option we definitely considered, but one important caveat I set early in the redesign process was to leave the site content and features alone and just update the look and feel of the site. Thus I wanted to leave every current piece of information that was an important part of the homepage as is, though slightly reorganized. I also didn’t want to change the size of the homepage slideshow images, since the PR committee already had a large stock of images they were using and I didn’t want them to have to redesign everything. In general, we are moving to a much more flexible and iterative process for changing website features and content, so nothing is ruled out for the future.

I won’t go into a lot of detail about the technical fixes I made, since this won’t be widely applicable. Views Slideshow uses a very standard Drupal module called Views to create a list of content. While it is a very popular module, I found it challenging to install correctly without a lot of help (I mainly used this site), since the settings are hard to figure out. In setting up the module, you are able to control things like whether alt text is required, the most basic type of accessibility feature, which allows users who cannot see images to understand their content through screen readers or other assistive technologies. Beyond that, you can set some things up in the templates for the modules. First I created a Drupal content type is called Featured Slideshow. It includes fields for title of the slide, image, and the link it should go to. The image has an alt and title field, which can be set automatically using tokens (text templates), or manually by the person entering data. The module uses jQuery Cycle to control which image is available. I then customized the templates (several PHP files) to include ARIA roles and to edit the controls to make them plain English rather than icons (I can think of downsides to this approach for sure, but at least it makes the point of them clear for many people).

ARIA role. This is frequently updated but non-essential page content. Its default ARIA live state is “off”, meaning unless the user is focused on it changes in state won’t be announced. You can change this to “polite” as well, which means a change in state will be announced at the next convenient opportunity. You would never want to use “assertive”, since that would interrupt the user for no reason.

Features I’m still working on are detailed in The Unbearable Inaccessibility of Slideshows, specifically keyboard focus order and improved performance with stylesheets unavailable. However with a few small changes I’ve improved accessibility of a feature on the site–and this technique can be applied to any feature on any site.

Making Small Improvements to Improve Accessibility.

While librarians who get the privilege of working on their own library’s website have the possibilities to guide the design choices, we are not always able to create exactly the ideal situation. Whether you are dealing with a carousel or any other feature that requires some work to improve accessibility, I would suggest the following strategy:

  • Review what the basic requirements are for making the feature work with your platform and situation. This means both technically and politically.
  • Research the approaches others have taken. You probably won’t be able to use someone else’s technique unless they are in a very similar situation, but you can at least use lessons learned.
  • Create a step by step plan to ensure you’re not missing anything, as well as a list of questions to answer as you are working through the development process.
  • Test the feature. You can use achecker or WAVE, which has a browser plugin to help you test sites in a local development environment.
  • Review errors and fix these. If you can’t fix everything, list the problems and plan for future development, or see if you can pick a new solution.
  • Test with actual users.

This may seem overwhelming, but taking it slow and only working on one feature at a time can be a good way to manage the process. And even better, you’ll improve your practices so that the next time you start a project you can do it correctly from the beginning.

 


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!

Method

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.

Findings

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">
<label>
<input type="radio" class="pad-left-med" name="s-lg-poll-option-13342416" 
id="s-lg-poll-option-13342416_1" value="83823" >Never
</label>
</div>

More accessible code might instead look like:

<div class="radio">
<label FOR=”never”>Never
</label>
<input type="radio" class="pad-left-med" name="s-lg-poll-option-13342416" 
id="s-lg-poll-option-13342416_1" value="83823" ID=”never”>
</div>
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="http://syndetics.com/index.aspx?isbn=9780133017854/LC.GIF&amp;
client=springshare" 
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" 
src="http://syndetics.com/index.aspx?isbn=9780133017854/LC.GIF&amp;
client=springshare" 
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" 
src="https://www.youtube.com/embed/rWDN64k977o" 
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" 
src="https://www.youtube.com/embed/rWDN64k977o" 
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="http://example.com" 
  title="Read about evaluating sources with the CRAP Test">
  The Crap Test
</a>

Link with aria-label attribute:

<a href="http://example.com" 
  aria-label="Read more about evaluating sources">
  The Crap Test
</a>
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.

Notes

  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.” http://www.csun.edu/universaldesigncenter
  2. For an excellent overview of web accessibility compliance, see Cynthia Ng’s articles on ACRL Tech Connect at http://acrl.ala.org/techconnect/post/making-your-website-accessible-part-1-understanding-wcag, http://acrl.ala.org/techconnect/post/making-your-website-accessible-part-2-implementing-wcag, and http://acrl.ala.org/techconnect/post/making-your-website-accessible-part-3-content-wcag-compliance.
  3. For a great example of the extensive customization that can be done in LibGuides 2.0’s Bootstrap framework, see http://acrl.ala.org/techconnect/post/migrating-to-libguides-2-0