Accessibility Recommendations for UF Web Sites
The following guidelines are strongly recommended for implementation on all UF Web sites.
- Include Site Information & University Affiliation
- Include “Alt” Tags on All Images and Buttons
- Don’t Rely on Colors to Convey Information
- Identify Changes in Language
- Don’t Rely on Style Sheets to Convey Information
- Update Content on Non-Dynamic-Content Sites
- Don’t Use Flickering, Blinking, or Scrolling Text
- Use Simple Language
- Make Any Time Restraints Flexible
Applets & Scripts
If, after best efforts, you cannot create an accessible page, provide a link to an alternative page that uses W3C technologies, is accessible, has equivalent information (or functionality), and is updated as often as the inaccessible (original) page (WAI 11.4).
Traits of Font Accessibility
For online reading, sans-serif fonts (e.g. Arial, Verdana) are generally considered more legible than serif fonts (Times New Roman), narrow fonts or decorative fonts. Decorative and narrow fonts in particular should be reserved for headlines and decorative texts only. (See WebAIM for best practice) http://webaim.org/techniques/fonts/
There are several different traits of your website’s text that all qualify as parts of font accessibility.
- Font popularity
- Font color
- Background color
- Contrast between font and background
- Text size
- Text serifs (or lack thereof)
Include the name of the unit or group represented by the page, a means of contacting the person(s) responsible for maintaining the page content, the date of last revision, the university wordmark, and an active link to the UF home page, as per the UF Acceptable Use Policy.
Users may need to contact you with questions about the content of your site or to notify you of problems with site usability. The date of last revision will help users determine if the site contains up-to-date information.
UF WebAdmin provides wordmarks for Web Managers to use on their sites. Right click (or control-click on Mac) on the wordmark you choose to download and save it.
Provide a text equivalent for every non-text element (e.g., via “alt”, “longdesc”, or in element content). This includes: images, graphical representations of text (including symbols), image map regions, animations (e.g., animated GIFs), applets and programmatic objects, ascii art, frames, scripts, images used as list bullets, spacers, graphical buttons, sounds (played with or without user interaction), stand-alone audio files, audio tracks of video, and video (WAI 1.1).
Screen readers for the visually impaired will skip over images, image maps, buttons, bullets, etc. “Alt” tags give a written description of the image.
Provide alt tags or alternative text for all bullets, images, and buttons. For “spacer” images or unimportant graphics, use alt=” ” as your tag.
<dd><img src=”bullet.gif” alt=”* “>John
<dd><img src=”bullet.gif” alt=”* ” >Joseph
<dd><img src=”bullet.gif” alt=”* “>Jeremy
<img src=”topo.jpg” alt=”current routes at Boulders Climbing Gym”>
<img src=”button.gif” alt=”go to calendar”>
Ensure that all information conveyed with color is also available without color, for example from context or markup (WAI 2.1).
Visually impaired and color-blind users won’t be able to access that information
Choose colors that vary in saturation, not just hue. Avoid using red and green together. Ensure that information is not conveyed through color alone. For example, when asking for input from users, do not write “Please select an item from those listed in green.” Instead, ensure that information is available through other style effects (e.g., a font effect) and through context (e.g,. comprehensive text links).
To test whether your document still works without colors, examine it with a monochrome monitor or browser colors turned off. To test whether color contrast is sufficient to be read by people with color deficiencies or by those with low resolution monitors, print pages on a black and white printer (with backgrounds and colors appearing in grayscale)
Clearly identify changes in the natural language of a document’s text and any text equivalents (e.g., captions) (WAI 4.1).
Screen readers will read foreign words as english unless otherwise coded.
Identifying changes in language are important for a number of reasons:
- Users who are reading the document in braille will be able to substitute the appropriate control codes (markup) where language changes occur to ensure that the braille translation software will generate the correct characters (accented characters, for instance). These control codes also prevent braille contractions from being generated, which could further confuse the user. Braille contractions combine commonly used groups of characters that usually appear in multiple cells into a single cell. For example, “ing” which usually takes up three cells (one for each character) can be contracted into a single cell.
- Similarly, speech synthesizers that “speak” multiple languages will be able to generate the text in the appropriate accent with proper pronunciation. If changes are not marked, the synthesizer will try its best to speak the words in the primary language it works in. Thus, the French word for car, “voiture” would be pronounced “voter” by a speech synthesizer that uses English as its primary language.
- Users who are unable to translate between languages themselves, will be able to have unfamiliar languages translated by machine translators.
If you use a number of different languages on a page, make sure that any changes in language are clearly identified by using the “lang” attribute.
<p>and with a certain <span lang=”fr”>je ne sais quoi</span>, she entered both the room and his life, forever. <p>My name is Natasha,</p> she said. <p lang=”it”>Piacere,</p> he replied in impeccable Italian, locking the door.
Organize documents so they may be read without style sheets. For example, when an HTML document is rendered without associated style sheets, it must still be possible to read the document (WAI 6.1).
Text generated by style sheets is not part of the document source and will not be available to assistive technologies. Although content developers are encouraged to use new technologies that solve problems raised by existing technologies, they should know how to make their pages still work with older browsers and people who choose to turn off features.
Provide a text equivalent for any important image or text generated by style sheets (e.g., via the ‘background-image’, ‘list-style’, or ‘content’ properties). Ensure that important content appears in the document object.
Ensure that equivalents for dynamic content are updated when the dynamic content changes (WAI 6.2).
Until user agents allow users to control flickering, avoid causing the screen to flicker (WAI 7.1).
Epileptic seizures can be caused by blinking and flickering. Scrolling text will lock up screen readers.
Use the clearest and simplest language appropriate for a site’s content (WAI 14.1).
Translators and screen readers will translate simple language more accurately than complex text.
Strive for clear and accurate headings and link descriptions. Avoid slang, jargon, and specialized meanings of familiar words, unless defined within your document. Favor words that are commonly used. For example, use “begin” rather than “commence” or use “try” rather than “endeavor.” Use active rather than passive verbs. Avoid complex sentence structures.
When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required (1194.22(p)).
Provide redundant text links for each active region of a server-side image map (WAI 1.2).
Screen readers for the visually impaired will skip over image maps. Alternative text will give a written description of the image and links.
Text is considered accessible to almost all users since it may be handled by screen readers, non-visual browsers, and braille readers. It may be displayed visually, magnified, synchronized with a video to create a caption, etc. As you design a document containing non-textual information (images, applets, sounds, multimedia presentations, etc.), supplement that information with textual equivalents wherever possible.
When a server-side image map must be used, content developers should provide an alternative list of image map choices. There are three techniques:
- Include the alternative links within the body of an OBJECT element (refer to the previous example illustrating links in the OBJECT element).
- If IMG is used to insert the image, provide an alternative list of links after it and indicate the existence and location of the alternative list (e.g., via that “alt” attribute).
- If other approaches don’t make the image map accessible, create an alternative page that is accessible.
<img src=”welcome.gif alt=”Welcome (text links follow)” ismap>
Provide client-side image maps instead of server-side image maps except where the regions cannot be defined with an available geometric shape (WAI 9.1).
For data tables, identify row and column headers (WAI 5.1).
Screen readers read tables line-by-line. Identifiers will organize the data.
For example, if a table is rendered like this on the screen:
|There is a 30% chance of
rain showers this morning, but they
should stop before the weekend.
|Classes at UF
will resume on August 28th
This might be read by a screen reader as: There is a 30% chance of Classes at UF rain showers this morning, but they will resume on August 28th. should stop before the weekend.
How-to / Example
|Name||Cups||Type of Coffee||Sugar?|
<table border=”1″ summary=”This table charts the number of cups of coffee consumed by each senator, the type of coffee (decaf or regular), and whether taken with sugar.”>
<caption>Cups of coffee consumed by each senator</caption>
<th id=”header3″ abbr=”Type”>Type of Coffee</th>
<td headers=”header1″>T. Sexton</td>
<td headers=”header1″>J. Dinnen</td>
A speech synthesizer might render this tables as follows:
Caption: Cups of coffee consumed by each senator
Summary: This table charts the number of cups of coffee consumed by each senator, the type of coffee (decaf or regular), and whether taken with sugar.
Name: T. Sexton, Cups: 10, Type: Espresso, Sugar: No
Name: J. Dinnen, Cups: 5, Type: Decaf, Sugar: Yes
For data tables that have two or more logical levels of row or column headers, use markup to associate data cells and header cells (WAI 5.2).
Title each frame to facilitate frame identification and navigation (WAI 12.1).
Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page (WAI 6.3).
Until user agents can automatically read aloud the text equivalent of a visual track, provide an auditory description of the important information of the visual track of a multimedia presentation (WAI 1.3).
For any time-based multimedia presentation (e.g., a movie or animation), synchronize equivalent alternatives (e.g., captions or auditory descriptions of the visual track) with the presentation (WAI 1.4).