This is a repost of my blog post, which was originally posted on the ACRL TechConnect, but with a couple of small updates.
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 (i.e. do not use) 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:
[sourcecode language=”html”]
<body>
<div>
<!– your main/primary content –></div>
<div>
<!– secondary content, this may be a number of things e.g. local nav –></div>
</body>
[/sourcecode]
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:
[sourcecode language=”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%;
}
[/sourcecode]
[sourcecode language=”html”]
<body>
<header>
<a href="#access" class="assistive-text">Skip to main menu</a>
<hgroup>
<h1>Your Library</h1>
<h2>Tagline</h2>
</hgroup>
<nav name="access">
<!– Allow screen readers/text browsers to get right to the good stuff. –>
<h3 class="assistive-text">Main Menu</h3>
<a href="#content" class="assistive-text">Skip to content</a>
<a href="#secondary" class="assistive-text">Skip to page navigation</a>
<!– global nav –>
</nav>
</header>
<!– rest of page –>
</body>
[/sourcecode]
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.
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% (and higher) 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 section tags to define the roles of the various sections of a webpage (4.1.2, 1.3.1) along with the appropriate recommended ARIA roles (normally ARIA roles are only defined for custom elements, but due to varying support by browsers, currently it is recommended to add them). For example, the basic structure of your website might look something like this:
[sourcecode language=”html”]
<!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 role="banner">
<h1>site name</h1>
<h2>tagline</h2>
<nav role="navigation">
<a href=’#’>Global Nav Link</a>
<a href=’#’>Second Nav Link</a>
<a href=’#’>More Nav Link</a>
</nav>
</header>
<div id="content" role="main">
<article role="article">
<!– your content, a blog post for example –>
</article>
<article role="article">
<!– another standalone piece –>
</article></div>
<div id="secondary" role="complementary">
<!– your sidebar –></div>
<footer role="contentinfo">copyright and other info</footer>
</body>
</html>
[/sourcecode]
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 presentation aspects.
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:
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 & Resources
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).
My favourite though is the HTML Codesniffer. You can copy/paste code or grab the bookmarklet to audit any page you’re viewing. It also supports both WCAG and Section 508.
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:
- jQuery UI
- Dijit (Dojo Toolkit)
- YUI Library
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.