Accessibility - Details
As a public institution we are required to provide equal access to programs and services for our entire community. See more about Legal Standards for Web Accessibility.
In the paragraphs below we present some common issues that will affect most WWU web developers.
- Alt Attributes On All Images
- Multimedia Accessibility
- Relative Font Sizes
- Meaningful Link Names
- Tabindexes on Forms
- Skip Navigation
- Color and Contrast
- Accessible Tables
- Accessible File Formats
This page includes several common examples of web accessibility issues that effect WWU web developers.
Every image in your site should have an ALT attribute that explains what the image is for. This is essential for screen readers for the vision-impaired as well as for those that have turned off graphics or are browsing with a phone or PDA. This is the ALT attribute for the IMG tag in HTML, but you can also put these in using your WYSIWYG editor like Dreamweaver.
<img src="dept_logo.gif" alt="Philosophy Department Logo">
If the picture is merely fluff, or a spacer graphic that is not meant to be seen, use a null alt attribute (nothing between the quote marks) so that the screen reader ignores it:
<img src="pretty_picture.gif" alt="">
<img src="spacer.gif" alt="">
For alt attributes and captions provide as complete a summary as possible. For example, if it's a picture showing population growth, don't just say "Population Growth", sum up the meaning of the graphic as in "Whatcom County Population Growth of 50% expected by year 2020". If you need a longer description, use the longdesc attribute which links to a separate web page on which a detailed description of the graph is provided:
<img alt="Whatcom County Population Growth of 50% expected by year 2020" longdesc="chart1description.html">
Just as graphics must be labeled, other types of multimedia must also be captioned for those that can't hear it or audio-captioned for those that cannot see it. There are a variety of tools available to help with this (google "web captioning") and we hope to have more information on this in the future. Some ideas to start with:
- YouTube has decent captioning for videos.
- You can also provide a written script of your videos
Absolute font sizes, such as 12px or 24px cannot be resized in Internet Explorer browsers. This prevents people from finding a comfortable font size for their vision level and the monitor they're using. So use relative font sizes, either "ems" or "%" or the keywords such as "small". And since you're using good design techniques, nothing that affects how the page looks is in the html file, but rather in a css file.
There are several relative font sizing mechanisms, the simplest of which is "xx-small", through "medium" through "xx-large", giving seven levels of font sizes. Note that "small" is rendered as about 12px in most browsers, but IE uses "x-small" to represent 12px.
EMS and percentage are also relative font-sizing schemes, but note that they compound - i.e. If you have a section at font-size: 90% and then inside that another font-size: 90% then the resulting font-size will be smaller than the rest of the text, i.e. 90% of 90% or about 80%. A font-size:small inside another font-size:small does not get smaller. So use em and percentage with caution.
The Western Template takes care of this for you, but for your own pages, define the size for all your body and p and h text in your css file similar to this for vision-friendly resizable text:
font-family: verdana, arial, helvetica, san serif;
The link name must be meaningful all by itself. Screen readers have functionality that allows users to access links on a web page independently of their context, e.g., in a list of links. Links like "click here" and others don't make sense in this context. Likewise if someone is using speech recognition, the link names must be different for each link.
Don't do generic link names like these:
Do use explicitly helpful link names like these:
If you have form fields on your webpage, allow the user to use keyboard only to move through the form with Tabindex tags. That means that for each <Input> on your page, provide a tabindex set to sequentially higher values. For example:
<input type="text" id="name" tabindex="1" >
<input type="text" id="email" tabindex="2" >
If your template, like ours, starts with navigation on the top / left, then users who are navigating by keyboard rather than mouse must use an outrageous number of keystrokes to get past your navigation so they can access the main content. This is not very friendly. Use Skip to Main Content link to take care of this. First put an anchor on the beginning of the main page content:
<a name="startcontent" id="startcontent">
Then add a link just under the Body tag to jump to this anchor in your main content:
<a class="skipnav" id="startcontent">Skip to main content</a>
Then add an attribute to your css file to make this link off-page:
You can test how your users see this by making these changes and bringing up your page (or this page for that matter) in Firefox. Then turn off the CSS by selecting View, Page Style, No Style and use your tab key to navigate.
The general rule about color is: Don't use color alone to convey information. Screen readers don't indicate text color and some vision impairments mask color differences. A common mistake is the following:
(Required fields are red)
Only those who can see red can see the distinctions here. But starred works for all readers:
(*Required fields are red and starred)
The general rule for contrast is that more is better. Readability is increased if there is adequate contrast between the background color and the foreground text color. That's why black text on white background is a good standard. If you're not sure, there are color contrast checking tools to test this on your site.
But the subject becomes more complex when you consider those who see color differently, and there are tools that show you how your page looks to someone with color-blindness. To anticipate these difficulties, imagine your site in shades of gray - it should be the contrast (light, dark) of the the colors that distinguishes them, not just the color values (red, green) themselves.
Again - don't convey information with color alone and when you use colors for effect consider their contrast and value.
Screen readers read tables from left to right starting at the top. As users get deep into the table, it can be difficult for them to appreciate where they are in the table and which headers apply to which cells. The table below looks standard:
but a screen reader could read this as:
Parking at WWU
Winter, Spring, Summer, Fall;
2005, 3500, 2900, 650, 3000;
2000, 3300, 2400, 390, 2000.
This reading would completely confuse the meaning of "2000" as a year and "2000" as a number of cars parked. So how can this table be improved?
An improved caption would help: "Parking increases at WWU between 2000 and 2005". Your captions should always sum up the meaning of the table - it helps everyone understand the table.
Also, labeling can be more specific - label the years fields to more clearly differentiate them from the parking counts, e.g. yr 2005.
But to provide specific assistance to screen readers without modifying what you see on the screen, use the summary attribute and the scope attribute to make this table easier to understand. The summary attribute provides additional information about the table as a whole while the scope tells the screen reader which fields name columns and which fields name rows as in this code excerpt:
<table border="1" summary="The average number of cars per day parking at Western each term now and 5 years ago.">
<td scope="row">2005</td> <td>3000</td>
Using the attributes in this way enables the screen reader to read the above chart as
The average number of cars per day parking at Western each term now and 5 years ago.
2005: Winter, 3500; Spring, 2900; Summer, 650; Fall 3000.
2000: Winter, 3300; Spring, 2400; Summer, 390; Fall 2000.
For more complex tables comprised of nested tables use these guidelines:
- Be sure that all row and column headers are marked up as <th>
- Include an id="name" attribute for all <th> elements
- Include a headers="th1 th2..." attribute for all <td> elements, the value being a space-delimited list of id's representing each <th> element that applies to that cell.
Web pages are the most accessible files - no matter the operating system, browser / screen reader or device, the user is fairly certain to be able to get to your content. However other file formats are not so universal. Word, Powerpoint and Excel types require a Microsoft reader; PDF requires an Adobe reader; although these formats are very prevalent they are not as accessible as HTML and frequently the issues are harder to remedy.
So your content should be in HTML.
That said there are times that other formats are an acceptable compromise:
- The document is distributed in another medium, such as print, and it is important that the on-line version be the same
- A large repository of documents exists and are not yet converted or are prohibitively expensive to convert
These are real-word reasons - just remember that you are potentially compromising some users' accessibility to these documents. Also see notes on Linking to non HTML documents
Creating accessible PDF files
Special care must be taken with Adobe PDF (portable document format) files to ensure that they are accessibility-compliant. A common issue with PDF files is that they do not contain information about structure by default (such as heading elements and paragraph elements which can be parsed by a screen reader.) Fortunately, there are solutions in place which address these issues by "tagging" the document to enable compatibility with assistive technologies.
Please review the following documents for assistance with creation and formatting of accessible PDFs: