Making Your Website Accessible Part 2: Implementing WCAG

In Part 1, I covered what web accessibility is, its importance, and the Web Content Accessibility Guidelines (WCAG). This post focuses on how to implement WCAG into the structure and layout of the website (including templates/themes, plugins, etc.). While I will be referring to WCAG, I have based this post on what I have found in terms of general best practices, so hopefully this post is applicable to any site.

Using a Template for Layout

First off, I’m going to assume that at the very least your website uses a template even if it doesn’t use a content management system (CMS). Whether your site is developed in-house or not, the points below should be true, otherwise you’re making your website inaccessible for everyone (not just those with accessibility needs).

A template will help you with:

  • consistent navigation (3.2.3)
  • consistent identification of the different parts of each page (3.2.4) – i.e. you assign ids consistently
  • avoiding tables for layout purposes
  • providing multiple ways to discover content (2.4.5)
  • meaningful order to content (1.3.2) – more details below
  • keyboard accessibility (2.1) by insert bypass blocks (2.4.1) – more details below

To provide multiple ways to content, I’m partial to providing links to related pages (local nav) and a search bar, but there are other options.

  • Ordering Content

A template layout is particularly important for the second to last point, ‘meaningful order to content’. Screenreaders, much like people, read top to bottom. However, people generally read in the order that they see text, but screenreaders read in code order (think when viewing ‘page source’). For example:

<body>
  <div>
    <!-- your main/primary content -->
  </div>
  <div>
    <!-- secondary content, this may be a number of things e.g. local nav -->
  </div>
</body>

If you want your secondary content to show up before your primary content, you can just use CSS to move the divs around visually.

  • Keyboard Navigation

Your site also needs to be accessible by keyboard, and to help screenreader users (and those that use text based browsers), you can allow bypass blocks by inserting an anchor link that would allow users to skip blocks of content that are repeated on the various pages of a website.

For example, you might have a link at the very top of the page to skip to the main menu (global nav) or the content. At the main menu , you again might have something similar. This is just one possible example:

<style type="text/css">
.assistive-text {
    position: absolute !important;
    clip: rect(1px 1px 1px 1px); /* IE6, IE7 */
    clip: rect(1px, 1px, 1px, 1px);
}
a.assistive-text:active,
a.assistive-text:focus {
    background: #eee;
    border-bottom: 1px solid #ddd;
    color: #1982d1;
    clip: auto !important;
    font-size: 12px;
    position: absolute;
    text-decoration: underline;
    top: 0;
    left: 7.6%;
}
</style> [...]
<body>
  <header>
    <a href="#access">Skip to main menu</a>
     <hgroup>
        <h1>Your Library</h1>
        <h2>Tagline</h2>
     </hgroup>
     <nav>
        <!-- Allow screen readers/text browsers to get right to the good stuff -->
        <h3>Main Menu</h3>
        <a href="#content">Skip to content</a>
        <a href="#secondary">Skip to page navigation</a>
        <!-- global nav -->
     </nav>
   </header>
   <!-- rest of page -->
</body>
Responsive Template

A responsive site allows all your users to access and view your site on any size device, screen resolution, and browser window size (within reason). For example, take a look at Grand Valley State Libraries’ website in the desktop and mobile views below.

screenshot

GVSU Libraries’ Website Desktop View

screenshot of GVSU Libraries' Website

Mobile view

If you’re unfamiliar with responsive web design, you may want to take a look at Lisa Kurt’s Responsive Web Design and Libraries post to become more familiar with the topic.

The basic technique to make a site responsive is by using media queries shift the look of the content depending on screen size. Making a site responsive already provides greater access to all your users, but you can take this farther with a simple difference to make your site even more accessible. If you use ‘em’ (instead of pixels) for your media queries (see Matthew Reidma’s Responsive Web Design for Libraries) in your responsive template, you should be able to resize your page up to 200%  without any problems (1.4.4).

As part of your responsive design, also consider that touch screens don’t have the highest precision, so links and any other interactive pieces should not be too small. In general, this also helps users who have difficulty with fine motor skills to navigate your site.

Valid & Proper Markup

Using valid markup is part of the guideline (4.1.1), but you can go further than that by using HTML5 structural tags to define the roles of the various sections of a webpage (4.1.2, 1.3.1). For example, the basic structure of your website might look something like this:

<!DOCTYPE html>
<html lang="en"><!-- every page should specify the language of the page (3.1.1) -->
  <head>
    <title>Every Page Should Have a Title (2.4.2)</title>
  </head>
  <body>
    <header>
      <hgroup>
        <h1>site name</h1>
        <h2>tagline</h2>
      </hgroup>
      <nav>
        <a href='#'>Global Nav Link</a>
        <a href='#'>Second Nav Link</a>
        <a href='#'>More Nav Link</a>
      </nav>
    </header>
      <section>
        <article>
          <!-- your content, a blog post for example -->
          <aside>
            <!-- might have something like quick facts -->
          </aside>
        </article>
        <article>
          <!-- another standalone piece -->
        </article>
      </section>
    <footer>copyright and other info</footer>
  </body>
</html>

You may optionally include more metadata, not only for the benefit of screen readers, but also for indexing purposes.

Presentation

A number of guidelines deal with presentation aspects.

At the very basic level, presentation and layout should be separate from content. So layout control (such as sizes, floats, padding, etc.), colours, fonts, and practically anything you would put in ‘style’ should be done in CSS, separating it from the HTML (1.3.1). Screen readers (and other tools) can override CSS rules or turn CSS off completely, allowing the user to customize the font, colour, link colour, etc.

As the basic colour scheme is determined through the site’s general style sheet, you will also need to make sure that you fulfill the colour specific guidelines. Colour contrast needs to be at least 4.5:1, except logos and large text (18+pt, 14+pt bold), which require a minimum 3:1 ratio (1.4.3). I recommend using the WCAG Contrast Checker Firefox add-on. Here’s an example:

ColorChecker screenshot

It will highlight errors in red, and you can click on any line which will highlight the related element. The only problem is when you have multiple elements layered on top of each other. As you can see in the example, it’s checking the colour of the text ‘Research Help’ against the yellow you see bordering the menu (global navigation), rather than the element right behind the text. So, you do have to vet the results, but it’s a great little tool to help you quickly check the contrast of your text colours, and for images, you can enter numbers manually yourself to easily check the ratio.

Additional Tools

For more tools, like the colour contrast checker, check out the W3C Web Accessibility Tools list. My picks are WAVE (gives you different views, such as text-only) and Fangs (screen reader emulator).

Other Techniques & Reference

There are a lot more techniques that I haven’t covered in the WCAG Quick Reference, but be cautioned that some of these techniques are already obsolete. Follow the guidelines as those are the requirements; the techniques are ways that do fulfill the guidelines, but not the required way to do so.

Scripting & Custom User Interfaces

As this post focuses on HTML/CSS, it does not cover scripts, Flash, or PDF. The WCAG Quick Reference covers these and more.

For custom interfaces, WAI-ARIA should be used in conjunction with WCAG. There are some UI modules that are web accessible already, so I encourage you to use these:

If you’re using plugins, then at least make it a feature request, and consider contributing to the plugin to make it accessible.

Expectations

Libraries in particular use a multitude of tools and services. No one can expect your organization to make all your tools and services web accessible, especially when you likely don’t have full control over all of them. Nevertheless, do what you can, and request/advocate for web accessibility to companies that you have dealings with when it’s not controlled in-house. Even asking whether web accessibility guidelines have been considered or met can start the conversation going, as the developers may have simply not thought about accessibility. There are also some workarounds, such as providing an overlay (which I will cover in the next post in regards to video), but most workarounds I have seen take away functionality for some users, while making it more accessible for others. Always best to have accessibility built-in to a product or site.

The Bottom Line

While there are a few techniques that are specially to make sites accessible for people with disabilities, good, solid design principles will go a long way in making an accessible site for all your users. You also don’t need to redesign your whole site. Consider using the agile development idea and implementing one technique at a time to improve your site over time.

Next Time

In this post, I have focused on the structure and layout of the website, i.e. the elements that you would typically have in themes or templates. I have purposely left out guidelines that deal with the content of a website as many organizations rely on various staff members to populate the site with content (usually through a CMS), including content that might be done  either by IT or non-IT staff, such as forms and audio/visual content. However, all the content related guidelines also apply to any template or generated content (links, images, forms e.g. search bar), which is what I will cover in the third and final post.

About our Guest Author: Cynthia Ng is currently the Web Services Librarian at Ryerson University Library and Archives. While she is especially interested in web development and services, her focus is on integrating technology into the library in a holistic manner to best serve its users. She is a recent MLIS graduate from the University of British Columbia, and also holds a BEd from UBC. She can be found blogging at Learning (Lib)Tech and on Twitter as @TheRealArty.


One Comment on “Making Your Website Accessible Part 2: Implementing WCAG”

  1. [...] » Making Your Website Accessible Part 2: Implementing WCAG ACRL TechConnect Blog [...]


Leave a Reply