This is actually a repost of my guest post on the ACRL TechConnect Blog.
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:
[code language=”html” gutter=”false”]
<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
[/code]
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 as reading the title attribute on links (and images) is off by default.
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.
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)
[code language=”html” gutter=”false”]<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>[/code]
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:
[code language=”html” gutter=”false”]<img src="/6th-floorplan.jpg" alt="floor plan of the library’s 6th floor">[/code]
If decorative only:
[code language=”html” gutter=”false”]<img src="/example.jpg" alt="">[/code]
Title for Images
The title attribute 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.
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.
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) according to the guidelines. While the guidelines only stipulate having controls, autoplay can cause a lot of frustration for users and in particular, cause problems for users with autism (thanks to @zemkat for the tip).
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).
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).
(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. Adobe Flash accessibility design guidelines].) 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).
To fix the (above) problem, you can use tab index attribute.
For simplicity, I’ve left out some coding such as the form attributes.
[code language=”html” gutter=”false”]<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>[/code]
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.)
Since the default behaviour only covers the webkit browser, some simple CSS will do the trick.
[code language=”css” gutter=”false”]
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;
}
[/code]
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, Technique H44), 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:
[code language=”html” gutter=”false”]<input type="text" name="name" required>[/code]
The browser will automatically identify whether the field was left blank and inform the user.
Similarly, there are now more input types you can use for browser-based form validation, such as the email input type:
[code language=”html” gutter=”false”]<input type="email" id="user_email">[/code]
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:
- The Paciello Group Blog – a lot of great articles focused on web accessibility
- Web Accessibility Checklist – site also has a number of easy to digest articles
- Part 2 of this series – includes tools to check accessibility and a (partial) list of accessible UI libraries