LibGuides and 508 compliance
Ensuring that LibGuides content is available to patrons with disabilities is very important to us, and we're always working to improve access to LibGuides pages. We are happy to report that the feedback we've received regarding the accessibility of our products has been overwhelmingly positive, including passing all tests from clients who requested that we comply with their ADA guidelines. It is also important to emphasize that the 508 compliance is a team effort, i.e. you (the guide authors) also need to ensure that content you put into the system is accessible as well.
Here are the steps we've taken with our code to make it accessible:
- Alternate pages for screen readers.
While our regular public pages are screen-reader friendly, we also have a parallel set of public pages created specifically for screen readers. This gives patrons using screen readers more options when viewing LibGuides content.
See the Accessible Versions of Pages tab to learn how to get to these alternate pages.
- Our standard pages have hidden links that can only be "seen" by those using adaptive technology, and not standard browsers.
In addition to the link for the alternate version of the page, there are also "skip to navigation" and "skip to content" links that people can use to bypass the entire top section of the page.
- We have gone through our code and made the HTML output accessible-technologies friendly, e.g. using ALT tags, etc.
Here are the things you (the content/guide creator) need to be mindful of, if you want to ensure 508 compliance of your guide:
- Make sure you add information to the ALT tags of your images, giving a short explanation of the image you're adding. You can do this by filling out the ALT TAG field on the Insert/edit Image screen.
- Use of iframes: frames in webpages can create accessibility issues. Please check out WebAIM's page on Creating Accessible Frames if you plan on including iframes in your guides.
- Copying & pasting content from outside sources can sometimes be problematic. If you use the remove formatting function (explained in the GuideFAQ), it will help remove some of the potentially problematic code. It might not get everything, but it will help.
- Use the WAVE tool, which was specifically designed for testing web documents for accessibility. Check out our page on the WAVE Tool in this guide.
W3C Validator Tool
It is important to note that the W3C validation tools do not check for accessibility, i.e. these tools do not tell you whether a page is section 508 compliant. The W3C tool checks the source code of a page to make sure it is XHTML compliant, which means that all the code and tags are formed in a very specific manner.
For example, the W3C tool will only accept <br /> as the proper way to display a line-break tag, even though all web browsers and readers also support line-breaks written as <br>, <BR>, <BR />, etc.
So when testing a page with the W3C tool you will likely get hundreds of warnings that have zero impact on the ability for a web browser or adaptive device to load that page.
The bottom line is that the W3C tool is not useful when testing a page for accessibility, which is why we recommend the WAVE tool located at http://wave.webaim.org. This tool was specifically designed for accessibility testing.