Making Your Website Accessible Part 2: Implementing WCAG into the Structure & Layout

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).

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:

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.

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.

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

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:

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.