Making Your Website Accessible Part 3: Content WCAG Compliance

Welcome to part 3 of the web accessibility series. While part 1 explained a bit about web accessibility and the web consortium accessibility guidelines (WCAG) and part 2 covered implementing WCAG on the development side, part 3 will cover the content side of things.

The main goal is that you walk away with a set of guidelines you can give to staff. I’ll start with the easier stuff that apply to all staff that have access to editing content, and then I’ll move on to more complicated content, namely media and forms, where the guidelines may be for technical staff either for content creation or for evaluating add-ons/plugins.

Headers

Use headings 1-6 to structure information so people using assistive technologies can navigate web pages easier (2.4.6). If your page were displayed with only headers or with headers and content indented, would it make sense? Will your headers be in the right place? Many screen readers and tools use an “Outline View”, which shows only the headings of a page.

Header 1 is the Title of the Webpage
Header 2 is a Subtopic of the Webpage
Header 3 is a Specific Sub-topic of Header 2 (and 1)
Another Header 2 would be a Subtopic of Header 1
(but separate from the  first Header 2)

Example:

<h1>E-Resources in Engineering</h1> = title of your page.
  <h2>Standards and Codes</h2> = topic 1
    <h3>International Standards Organization</h3> = 1st subtopic of topic 1
    <h3>Canadian Standards Association</h3> = 2nd subtopic of h2 topic 1
  <h2>Journal Databases</h2> = topic 2
    <h3>Compendex</h3> = subtopic of topic 2

Enter your HTML or the URL of your page into HTML5 Outliner to see an outline view.

Links

The text for every link should be descriptive (2.4.4) and unique (within a single page). Imagine there was no other text around it (except the title of the page). Would you understand what that link is for? Many assistive technologies have a “links only” option for viewing.

While many CMS provide the option to add additional text to a link through the title attribute (and is described as a sufficient technique, H33), the title attribute is generally not read by screen readers 1 as reading the title attribute on links (and images) is off by default. 2

Text in a Foreign Language

While each page should already be marked with a ‘default’ language (3.1.1), chunks of text (e.g. quotes, titles) in another language should be marked (3.1.2) with the ‘lang’ attribute and the appropriate language code, which can be applied to any HTML element. 3

Tables

Only use tables for information and data that should be presented in a tabular format. For example, a calendar, a list of contact information, or data sets should be presented in a table (1.3.1). Tables should not be used for layout, such as presenting content in columns.

If you need to use a table, then the information must be presented in a way that is accessible to users with disabilities and allows the table information to still be understood by the user even if they can’t see the table’s layout.

Elements

<table> : This element defines an HTML table
<tr> : This element defines a table row
<th> : This element defines a table header and should have the appropriate scope
<td> : This element defines a table cell
<caption> : This element identifies the table and acts as a title for the table. A caption is shown to all.

Example using Code for a Simple Table (Technique H63)

<table>
  <caption>Overdue Fines for Library Materials On Loan</caption>
  <tr>
    <th scope="col">Type of Item</th>
    <th scope="col">Amount per Day</th>
  </tr>
  <tr>
    <td>Books</td>
    <td>$0.50</td>
  </tr>
  <tr>
    <td>DVDs</td>
    <td>$1.00</td>
  </tr>
</table>

For examples of more complex tables, take a look at Technique H43.

Images
  • Alternate Text

When you include image elements on your website, you also need to include alternate or alt text, which allows you to include descriptive information about the image. While the text is not visible to most users, assistive technologies will read the alternate text as a description of the image, so write concisely, while still providing an accurate description of the image.

However, if your image has been included for purely decorative purposes, leave the alternate text empty. Assistive technology will ignore the image completely.

For example:

<img src="/6th-floorplan.jpg" alt="floor plan of the library's 6th floor">

If decorative only:

<img src="/example.jpg" alt="">
  • Title for Images

The title field allows you to provide additional information about an image in addition to the alternate text (meaning the title should not repeat alternate text). The title will also typically appear if users hover over an image with a title. However, as already noted, the title is typically not seen or read, so the use of title is discouraged 4.

  • Use Text Whenever Possible

Basically, don’t use an image of text instead of just text – use CSS instead (1.4.5). The one exception is for logos.

The logo of this website is an image, but all other text you see in this screenshot is just text

The logo of this website is an image, but all other text you see in this screenshot is just text

  • Meaning through Text

In a similar vein, understanding information and instructions should not be dependent on any sensory characteristics, such as sound, colour, or shape (1.3.3, 1.4.1). Think about it as: your message should be understood in text-only mode.

Audio/Video, Animations & Interactions
  • Autoplay

In general, audio and visual content should not play automatically. Instead, users should be able to hit a play button when they are ready for the content. Audio that autoplays for more than 3 seconds must have a pause/stop control or independent volume control (1.4.2).

  • Alternatives to Media

All non-text content, including audio and visual materials should have an alternate (1.1.1), typically a text transcript and/or descriptive audio (1.2.1, 1.2.3). At the AA level, WCAG requires audio descriptions for all videos as well (1.2.5), but the Ontario legislation (AODA) excludes it.

Example of Audio Description in a Movie

Much like images, if the audio/video is actually an alternate to text, such as in a tutorial where an explanation is already fully explained in text form, then no alternate is required.

  • Captions

All audio/video should have captions (aka subtitles) again unless the actual audio/video is an alternative to text (1.2.2). At the AA level, WCAG requires captions for live (streaming) audio/video as well (1.2.4), but this is the one other exception to the AODA.

  • Timing

Timing issues are particularly important in media and interactive elements, although it applies to any session based activity, such as bookings and forms. The basic idea is that anything that is on a timer can be extended and in some cases, users have to be warned (2.2.1). The exceptions are when it’s in real time (e.g. auction) or it’s essential (e.g. timed quiz).

Toronto Public Library gives this session time out warning to users

Toronto Public Library gives this session time out warning to users

  • Moving, Blinking, & Flashing

While this applies to websites in general, particularly for interactive elements or animations, the simplified version is that anything that starts automatically should have an accessible mechanism to pause, stop, or hide it (2.2.2). Additionally, nothing on the website should flash more than 3 times within 1 second so as not to cause seizures (2.3.1).

WARNING: Epilepsy inducing website(please don't ever do anything like this, ever)

WARNING: Epilepsy inducing website
(please don’t ever do anything like this, ever)

  • Keyboard Accessible

Again, this applies to the website as a whole, but particularly with more interactive elements, everything on a website should have the ability to be used through a keyboard (2.1.1).

One of the major issues with web based media is that they tend to live in a Flash-based container, which is not usually accessible. (This may shortly prove to be less of a problem with accessible controls in Flash videos by default built into Flash CS6 5.) YouTube videos are a prime example.

One alternative is to provide a link to an accessible player. For YouTube videos, you can create a link that will load a video (or playlist) into an online accessible player, such as Easy YouTube Player or the Accessible Interface to YouTube.

The other common method is to wrap the Flash object with accessible controls (see Keyboard Accessible YouTube Controls for example). However, wrapping an embedded video may remove existing functionality, such as full screen or volume control.

If you host your own videos, consider having accessible controls load for all your videos, such as using the JW Player Controls.

I also emphasize that you should be careful to never have a keyboard trap (2.1.2) though this is uncommon these days. See the following section for more on keyboard accessibility.

Forms

Keyboard accessibility along with many guidelines talked about here may apply to any similar element in a website, but the rest of the guidelines are covered here as they are commonly related or encountered with form elements.

  • Tab Order

Not surprisingly, users should be tabbing through fields in the meaningful order, which is not always the same as the default browser order (2.4.3).

annotated screenshot of an incorrect tab order on a form

Default order based on the code, which is obviously confusing to a user.

To fix the (above) problem, you can use tab index attribute.

For simplicity, I’ve left out some coding such as the form attributes.

<form>
  <label for="realname">name: <input id="realname" tabindex=1>
  <label for="comments">comments
  <textarea id="comments" cols=25 rows=5 tabindex=4></textarea>
  <label for="email">email: <input id="email" tabindex=2>
  <label for="dep">department: <select id="dep" tabindex=3>
  <option value="">...</select>
</form>
  • On Focus & Input Behaviour

Whenever an element can take input or interaction from the user, the current focus should be visible (2.4.7). The most basic example is the border/shadow effect when your cursor is in a text box, which is already built into the latest webkit browsers. (Some of the other browsers do show a minimal effect, but nothing that would pass the colour contract guidelines.)

screenshot of default field focus styling in Chrome and Safari

Source: http://monstertut.com/2012/04/remove-outline-input-forms-chrome-onfocus/

Since the default behaviour only covers the webkit browser, some simple CSS will do the trick.6

input:focus, textarea:focus, select:focus {
  border: 2px solid #8AADE1;
  box-shadow: 0 0 3px #8AADE1; /* not supported pre-IE9, but border still applies */
  outline: medium none;
}

Putting focus on or entering something into an element should also not change the context (3.2.1, 3.2.2). Finally, submission should be manual, not automatic (though I’ve never encountered an automatic one).

  • Avoiding and Correcting Mistakes

Appropriate labels (and possibly instructions) should always go along with user input (3.3.2). Form elements in particular should generally each have a label element attached (though not used for buttons 7), such as in the basic code example above.

Any errors in input should always be identified and described (3.3.1), with corrections suggested whenever possible (3.3.3). For business transactions, particularly related financial or legal transactions, all data should be given to the user to be reviewed first (3.3.4).

With HTML5, marking required elements is now simpler than ever with the required attribute, such as:

<input type="text" name="name" required>

The browser will automatically identify whether the field was left blank and inform the user.

screenshot of popup when field required in chrome, firefox, and opera

Similarly, there are now more input types you can use for browser-based form validation, such as the email input type:

<input type="email" id="user_email">
Captcha

Do not use recaptcha. It irks me to no ends that recaptcha claims it is accessible, because they provide an audio alternative. While that’s true, next time you encounter one, try listening to it.

The alternative is to use a captcha that is more accessible. The wikipedia article on captcha can give you some ideas and example. Personally, I like the simple questions, such as ‘If you write 5 followed directly by 2, what number did you write?’

HTML5 Accessibility Support

Unfortunately, accessibility support for HTML5 is only partially there. Even basic elements, such as header and footer, are not supported across browsers. Based on various sources that I have read, for assistive technology purposes, your website should be accessible through the latest IE and Firefox on Windows, and Safari on OSX. Check out the HTML5 Accessibility website to see which HTML5 elements and attributes have accessibility support in the various browsers.

In the mean time, while in part 2, I mentioned that WAI-ARIA should only be used for custom interfaces, since not all browsers support all the new HTML5 elements and attributes, it has been suggested to use ARIA roles during this transitional phase. If you find something you’re using isn’t supported in the recommended browsers, check out Using WAI-ARIA in HTML, which talks about which ARIA role you should use.

Conclusion

This is the last of the series. I’ve made sure to cover all the guidelines, and while I haven’t specifically covered scripting, there’s almost no difference. Flash, Silverlight, and PDF are fairly different things, so I point you to the WCAG guidelines and other resources (see the next section).

Awareness of web accessibility has increased, but we can do more, a lot more, and there is no better place to start than with our own institution’s website. While web technologies are forging ahead and making it easier for people to interact with the web, adaptive or assistive technologies are frequently playing catch up, so we need to be aware of what works for everyone and what doesn’t. Make the web friendlier, for everyone.

Resources & More Information

If you want more information and resources, check out:

Notes

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.


Making Your Website Accessible Part 1: understanding WCAG

With more and more services and resources becoming digital, web accessibility has become an ever increasingly important topic. As a result, I thought a summary of my findings would be useful to others that are involved with web services.

What is Web Accessibility?

Some define web accessibility to mean making the web accessible to those with disabilities (including visual, auditory, motor, and cognitive) 1. However, I prefer the more general meaning of making the web accessible equally to everyone, including those with disabilities 2. To take this further, regardless of whether someone has a disability, they should be able to access information in their preferred manner including using any browser, operating system, or device.

A quick (but common) example of a problem is how a user is expected to control a video if they cannot use a mouse to click on buttons (they may depend on a keyboard or be visually impaired), especially when most videos still use some form of Flash. Try it sometime, and see what happens. Web accessibility guidelines, such as WCAG, attempt to address these issues.

What is WCAG?

The Web Content Accessibility Guidelines are just that, a set of guidelines, written by the Web Accessibility Initiative (WAI) group of the W3C. Currently, it’s at version 2.0, but many organizations still use version 1.0 (usually with modifications to make it more current).

  • The Breakdown of WCAG

Many (myself included) find WCAG to be difficult to navigate and comprehend. To get a better idea of ideas behind the guidelines, reading a summary can be of great help. The WCAG part of the Web Accessibility Initiative (WAI) site provides a good summary of the guidelines:

Perceivable

Operable

Understandable

Robust

-WCAG 2.0 at a Glance

Even if you don’t follow the specifics of WCAG, these are good general guidelines for web accessibility. While many of these might seem like common sense, the average person will not be detrimentally affected by not following guidelines. Also, some actually can have grave consequences (I always like to point out that content should not cause seizures).

WCAG 2.0 as a Mind Map by Avoka

The specific guidelines expand on these ideas and provide more detail on how each guideline might be met. To wade through the specifics, I suggest using the quick reference, How to Meet WCAG 2.0, and use the customization based on your current technologies and focus. By unchecking everything, except the level(s) you expect to meet, it also provides a good checklist.

  • A Note on Techniques

In most cases, the sufficient techniques and failures listed under each guideline are quite useful as examples of how you might meet (or fail) each guideline. On the other hand, the techniques are “informative” and are not necessarily the best method in fulfilling a given guideline. (See my critcism below.) You might also give advisory techniques a glance if you’re keen on knowing how to further enhance accessibility, but then my view is that there is enough to deal with without getting into even more detail.

Criticisms & Lessons Learned

WCAG is not without criticism. The wikipedia article on web accessibility gives a nice short blurb and links to articles of interest. From what I’ve read, the three most compelling arguments against WCAG2.0 specifically are that:

  • Level AAA is impractical to meet,
  • even at Level AAA, meeting WCAG2.0 does not make your website accessible, and
  • the documentation is difficult to navigate/understand.

To briefly explain the second point, as I mentioned, part of web accessibility is to make your website easily accessible on any device, but WCAG does not directly address this issue (which you could address for example through responsive design, as explained by Lisa in the last TechConnect post).

My biggest criticism though of WCAG2.0 is that the documentation (in particular, the techniques) is not current.

For example, under Sufficient Techniques for 1.3.1, Technique H73 tells you to use the summary attribute in table elements to provide an overview of what a given table is about. However, the summary attribute in HTML5 is deprecated (which I didn’t discover until I put a page with a table through the W3C validator).

Why Should You Care?

Despite its shortcomings, WCAG provides an excellent (base) set of guidelines to follow. Even if you choose not follow WCAG, consider customizing it to fit your organization’s needs.

  • Increased Access

If you’re reading this, you’re more than likely working at a public institution of some sort. Public institutions serve a very diverse group of people, and while persons with disabilities is a minority, we’re to serve one minority as well as any other and the majority as well (at least ideally).

Improving web accessibility helps a diverse audience in and of itself. Everything from mild to more extreme cases, the guidelines help to serve:

  • blind users, who will use screen readers
  • low vision users, who may use screen readers or magnifying tools
  • colourblind users
  • mobility impaired users, who might only use a keyboard
  • users with cognitive or learning disabilities
  • and more…

While in many cases serving one minority can mean taking away from another, that’s not the case here. You can easily improve your site to meet web accessibility requirements without negatively impacting the rest of your audience in any way (it simply might not make any difference).

  • Legislation: AODA Regulations

Legislation and regulations are additional reasons to adhere to a set of web accessibility guidelines. Even if it’s not legislated, most institutions (public and private) will have policies and/or mandates that require or promote equal/equivalent access to all users.

In Ontario, Canada we have the Accessibility for Ontarians with Disabilities Act (AODA), which states that under Section 14, subsection 4:

  • By January 1, 2014, new internet websites and web content on [public sector] sites must conform with WCAG 2.0 Level A.
  • By January 1, 2021, all internet websites and web content must conform with WCAG 2.0 Level AA, other than,
    • success criteria 1.2.4 Captions (Live), and
    • success criteria 1.2.5 Audio Descriptions (Pre-recorded).

Different countries and provinces/states obviously have different regulations, and I’m not really familiar with others, but I know that many of them use WCAG as well.

If you’re in the US, check out the Section 508 Government website. It focuses on the government regulations for their own departments, but includes lots of resources.

In academic libraries, I would also highly recommend contacting the equivalent disabilities support office (frequently called Access Centre), as they will provide support for staff dealing with accessibility issues.

  • Better for Everyone

While web accessibility generally focuses on providing and improving access for persons with disabilities, making sure your site follow a set of guidelines can also improve the experience of your other users as well.

Even something as simple as providing alternative text for images can help ‘regular’ users. What if their internet or your site is slow? What if they blocked (larger) images because they’re on a data plan? What if they’re using a text only browser? (While rare nowadays, not completely unheard of.) Much like when using a screen reader, having alternative text for images means a user would know what they’re missing and if it’s important.

Provided the ideal circumstances, some guidelines can still provide a better user experience.

Make text readable and understandable. -Guideline 3.1

Who wouldn’t want their user to be able to read and understand their site? Making content consistent across the site also improves navigation and browsability of a site.

We all access the web differently. Heck, I have a script blocker, flash blocker, and ad blocker all installed on every browser I regularly use. I really like sites that allow me to use them without unblocking any of those, because I believe that users should be able to do at least the basic things of any given website without ads, scripts, and flash. Web accessibility guidelines can help you make your site more accessible for everyone, and provide a better user experience.

The One-Liner

Basically, WCAG is a good source of information and a good set of guidelines to follow. While you need to be cautious of some of the finer details, making your site meet web accessibility guidelines can improve your site not only for those with special needs, but for your regular users as well.

 

About our Guest Author: Cynthia Ng is currently the Innovative Technologies Librarian (and also filling in for 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 user. 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.