Accessibility Recommendations

Website Accessibility Tips

Click the links below to find accessibility tips for several types of web content.

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


Image Maps



Applets & Scripts



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)

There are several different traits of your website’s text that all qualify as parts of font accessibility.

These include:

  • Font popularity
  • Font color
  • Background color
  • Contrast between font and background
  • Text size
  • Text serifs (or lack thereof)

Include Site Information & University Affiliation

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.

Include “Alt” Tags on All Images and Buttons

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.

  • Bullet
        <dd><img src=”bullet.gif” alt=”* “>John
        <dd><img src=”bullet.gif” alt=”* ” >Joseph
        <dd><img src=”bullet.gif” alt=”* “>Jeremy
  • Image
    <img src=”topo.jpg” alt=”current routes at Boulders Climbing Gym”>
  • Button
    <a href=”calendar.html”>
        <img src=”button.gif” alt=”go to calendar”>

Don’t Rely on Colors to Convey Information

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)

Identify Changes in Language

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:

  1. 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.
  2. 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.
  3. 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.

Don’t Rely on Style Sheets to Convey Information

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.

Update Content

Ensure that equivalents for dynamic content are updated when the dynamic content changes (WAI 6.2).

Don’t Use Flickering, Blinking, or Scrolling Text

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 Simple Language

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.

Make Time Restraints Flexible

When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required (1194.22(p)).

Image Maps – Provide Duplicate Links in Text Form

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:

  1. Include the alternative links within the body of an OBJECT element (refer to the previous example illustrating links in the OBJECT element).
  2. 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).
  3. If other approaches don’t make the image map accessible, create an alternative page that is accessible.
<a href=””>
    <img src=”welcome.gif alt=”Welcome (text links follow)” ismap>
<p>[<a href="reference.html">Reference</a>]
[<a href="syllabus.html">Syllabus</a>]<p>

Don’t Use Server-Side Image Maps

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

Label Data Tables

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
Cups of coffee consumed by each senator
Name Cups Type of Coffee Sugar?
T. Sexton 10 Espresso No
J. Dinnen 5 Decaf Yes
<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=”header1″>Name</th>
        <th id=”header2″>Cups</th>
        <th id=”header3″ abbr=”Type”>Type of Coffee</th>
        <th id=”header4″>Sugar?</th>
        <td headers=”header1″>T. Sexton</td>
        <td headers=”header2″>10</td>
        <td headers=”header3″>Espresso</td>
        <td headers=”header4″>No</td>
        <td headers=”header1″>J. Dinnen</td>
        <td headers=”header2″>5</td>
        <td headers=”header3″>Decaf</td>
        <td headers=”header4″>Yes</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

Organize data table labels

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

Avoid Using Frames or Title Each Frame

Title each frame to facilitate frame identification and navigation (WAI 12.1).

Make Pages Usable Without Applets & Scripts

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

Provide a Description of the Presentation

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

Use Captions

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