Please keep in mind these are only the most common problems and questions that prevent a web page from being accessible. See the complete guidelines for details.

Frequently asked questions

What are the most common accessibility issues?

During the Web Access Compliance Team's review process, they have discovered the following:

  • Over half of all official Missouri State pages that have been reviewed required at least some modifications to meet the accessibility guidelines.

  • By far the most common failure was missing or incorrect text equivalents for non-text elements. This is a requirement of Checkpoint (a).

  • The second most common failure is pages that contain at least one table that needs headers and scopes defined. This is a requirement of Checkpoint (g).

  • The third most comment failure is pages that have least one form field that does not have a label defined. This is a requirement of Checkpoint (n).

What are text equivalents for non-text elements?

A text equivalent is a method of assigning a text description to a image, or other non-text element. This is the single most frequent accessibility problem with web pages. Non-text elements include anything that is not text; however, the most common non-text elements lacking a text equivalent are:

  • Pictures and other images used as content

  • Banners and other images that are used to display text

  • Graphics used as hyperlinks to go to another page

For a detailed explanation and a example on how to fix these problems, see Checkpoint A.01

Why is flicker frequency important?

If any portion of a web page flickers between 4 and 59 frames per second the possibility exists of causing some individuals with photosensitive epilepsy to have a seizure triggered by the flicker, flash, or blink, particularly if the flash has a high intensity and is within certain frequency ranges. Since the rates of many animations depend on the speed of the computer and the severity of the effects, your safest way of approaching this topic is to avoid using any animations or flickering completely. The most common flicker problems include:

  • Animated clip art and pictures

  • Blinking text

  • Scripted image effects

For a detailed explanation and a example on how to fix these problems, see checkpoint J.

How do I make accessible electronic forms?

Forms on a web page require additional attributes for each field called a label to be accessible to users of assistive technology. Examples of form fields that require a label are:

  • Input boxes

  • Text boxes

  • Check boxes

  • Radio buttons or Option buttons

  • Drop down menu boxes

There are also many recommended attributes to make using forms easier to users of assistive technology such as logical tab indexes, field sets, and legends.

For a detailed explanation and a example on how to fix these problems, see Checkpoint N

What are table headers and scopes?

To understand the process of making tables accessible, it is easiest to cover the basic parts of a table first. Each cell in a table is defined by a <TD> tag. This cell conveys no relationship to any other cell in the table unless one is defined.

Making a <TD> cell into a table header <TH> means that cell describes other cells in the table, but does not say if it describes the cells below it, or to the side. Adding a scope to that header, such as scope="row" or scope="col", defines if the header is for a row header for describing cells to the right of the cell, or a column header which describes cells below it. Each time a header cell is defined, a scope should be used as well.

For a detailed explanation and an example on how to fix these problems, see Checkpoint G.

When do I need to use headers and scopes?

There are two types of tables. One type is used only for positioning and layout, which is used for looks only. The other type is a data table, which displays data in a logical layout. Data tables require additional markup to define cell associations to make accessible. To tell if your table is a data table or not, pick a few cells out of the table one at a time and cover up the rest or the document. If that cell makes complete sense without reading any other information, it is a layout table and does not require any additional markup.

Data tables require both headers and scopes defined or another method of relating cells to the other cells in the table.

For a detailed explanation and a example on how to fix these problems, see Checkpoint G.

Why shouldn't I save my PowerPoint presentations as web pages?

Microsoft PowerPoint is frequently used on campus, especially as course material. When a PowerPoint presentation is kept in the PPT file format, it is perfectly acceptable to have a link provided to that file on a web page. However, when the "Save as web page" feature in PowerPoint is used, the resulting web pages are highly non-accessible and there is currently no easy way of making them accessible. Note: providing both formats is acceptable so long as a link to both is provided on all pages that link to the web presentation.

If a presentation must be displayed as a web page, utilize the Save As, and choose Outline/RTF as the file type. Open the generated document and copy and paste the content into a web page editor. This will display a organized outline of almost all of the content in the presentation. Images, tables, and charts are not contained in the outline view and must be added separately and then made accessible.

Why shouldn't I use the FrontPage Hover button feature?

The FrontPage Hover button feature automatically creates an image rollover effect based on the text you provide, and the options you select. This is commonly used to provide a "mouse over" effect. There are two major accessibility problems with this feature. First, FrontPage does not automatically assign an alt tag to the images used in the rollover. Second, due to the way it is coded, the images which are commonly used as links can only be navigated by the mouse, and not the keyboard. 

What programs does the WACT use to check pages?

Since there is no program on the market that can catch all accessibility errors, the Web Access Compliance Team manually checks every single page for all accessibility problems. For developers there are a several programs which can provide a general guide in checking for accessibility. To see a list of these programs see the Accessibility Tools page. If you are looking for a tool to fit your needs, contact us and we'd be glad to assist in helping you chose the correct programs to fulfill your goals.

Is it considered bad for accessibility to use new or emerging web technology or formats?

No, actually we encourage users to implement technologies which can put additional useful content onto web pages. We just require that developers use these technologies in a responsible way. Macromedia Flash is a good example. A Flash site that has not been designed with accessibility in mind can be very frustrating or completely unusable to users of assistive technology. However, with a little forethought and a little extra effort these pages can be just as useful to users with different abilities.

Project resources