Topics Map > Accessibility
Topics Map > UDOIT

UDOIT - Errors And Suggestions [UW-Madison]

A guide to the errors and suggestions that UDOIT provides when it detects accessibility barriers.

   

Errors vs. Suggestions

UDOIT classifies accessibility barriers in two different categories: errors and suggestions. The main difference is the confidence in which UDOIT can say that the barriers are present.

Errors

These are barriers that UDOIT can confidently determine need remediation to comply with accessibility standards.

Suggestions

These are barriers that likely should be addressed for accessibility, but require a human to review them. Based on how the content is supposed to be displayed, these might not actually be errors. If you decide the issue does not need to be corrected, you can resolve it using the Mark as Resolved checkbox.

In all cases, Errors and Suggestions that are presented by UDOIT are all Web Content Accessibility Guidelines (WCAG) 2.2 AA barriers and must be addressed. More information can be found on the Center for User Experience’s Website.

See our UDOIT / WCAG 2 Mappings spreadsheet for a full list of Errors and Suggestions that UDOIT detects, mapped to their WCAG standards.

Tips for Common Errors

Links should contain text

Because many users of screen readers use links to navigate the page, providing links with no text (or with images that have empty "alt" attributes and no other readable text) hinders these users. Please add descriptive text.

Base font tag should not be used.

The basefont tag is deprecated and should not be used. Investigate using stylesheets instead.

Blink tag should not be used.

The blink tag should not be used. Ever.

Insufficient text color contrast with the background. 

Text color should be easily viewable and should not be the only indicator of meaning or function. Color balance should have at least a 4.5:1 ratio for small text and 3:1 for large text. Warning: using UDOIT to fix one section of text may invalidate the contrast in nested sections of text that are not the same color.

Avoid using color alone for emphasis. 

When emphasizing text, you may use color with sufficient contrast as long as you also apply some other form of emphasis, such as bold or italics. This ensures that screen reader users are aware of the text's importance.

Document reading direction.

Changes in text direction in inline content should be indicated using any HTML element (for example, span) with a 'dir' attribute indicating left-to-right or right-to-left. For example, a Hebrew phrase within an English paragraph should have its own text direction indicated.

All ‘embed’ elements must have an associated ‘noembed’ element. 

Because some users cannot use the embed element, provide alternative content in a noembed element.

Font tag should not be used. 

The font tag is deprecated and should not be used. Investigate using stylesheets instead.

Headings should contain text.  

Sighted and screen reader users depend on headings to organize the content on the page. Headings should not be empty and should represent an accurate outline of the content.

Marquee tag should not be used.

The marquee element is difficult for users to read and is not a standard HTML element. Try to find another way to convey the importance of this text

No table headers found. 

Table headers provide a description of the table structure for sighted and screen reader users.

No row or column scopes declarations found in table headers.

Scope declarations in headers organize and define table data by row/column for sighted and screen reader users.

Connection to the Kaltura Service Failed

This issue does not prevent video playback—it’s just a limitation in UDOIT’s validation process. UDOIT (Universal Design Online Inspection Tool) cannot directly verify Kaltura video playback due to security constraints. The necessary API token would violate UW system security policies. If you encounter this issue in a UDOIT report, the solution would be to manually check Kaltura videos or set their publishing status to “Public”.

Tips for Alternative Text Errors

Many common errors refer to Alternative text (alt text). Alt text is an alternative (non-visual) way to describe the meaning of an image. Learn more at WebAIM.org: Alt Text Accessibility 

No alternative text found

Please provide a brief description of the image for a screen reader user. Note: alt text should be more than image file name.

Alternative Text should not be the image filename 

Simply repeating the image file name is not descriptive enough. Please provide a description.

Alternative Text is more than the maximum allowed characters

Although alt text should be descriptive, it should also be short, typically no longer than 80-125 characters.

Alt text for images within links should not be empty.

Please provide a brief description of the image for a screen reader user. Note: It should not be the image file name. 

Images should not have a placeholder as alternative text.

Any image that is not used decoratively or which is purely for layout purposes cannot have an 'alt' attribute that consists solely of placeholders. Placeholders include: nbsp ,   , spacer , image , img , and photo.

Image elements should have an “alt” attribute.

This means the image is missing alternative text. Please provide a brief description of the image for a screen reader user.

Decorative images should have empty alternative text. 

This image was marked as decorative in the Rich Content Editor, but the ALT attribute contains text. Please remove the alternative text or the decorative marking.

Image description is too long.

Any image that has an 'alt' attribute that does not fully convey the meaning of the image should have a 'longdesc' attribute.

Input images should have an “alt” attribute 

Every form image button which has text within the image (say, a picture of the word 'Search' in a special font), should have the same text within the 'alt' attribute.

Tips for Captioning Errors

Closed captions do not match course language.

While this video has captions, there are no captions available for your course language. While not imperative to fix, you have options:

  • If the video is in Kaltura, you can add and edit captions.

  • Contact the creator of the video and request captions in your course language be added.

  • Create captions yourself using a service like Amara (http://amara.org/).

  • Find a different video that has closed captioning for your course language.

Closed captions cannot be checked 

Videos used on online courses are required to have closed captioning. Unfortunately, some video services do not provide an API for checking captions and will need to be manually verified.

Multimedia objects should have a text equivalent

Videos used on online courses are required to have closed captioning. Unfortunately, automatic captioning (such as on YouTube or Kaltura videos) is not accurate enough for educational use. You have options:

No closed captions found.

Captions should be included in the video to provide dialogue to users who are hearing impaired. Please note that videos that have been removed, deleted, or are Unlisted will also cause this error, and will need to be manually verified.

Closed captions were auto-generated.

Captions that are machine-generated by a service like YouTube or Kaltura are rarely if ever fully accurate and should not be relied upon for educational use. If the captions were created through Kaltura, the video owner can edit them to improve accuracy

Tips for Common Suggestions

Links to multimedia require transcripts. 

Multimedia objects should be accompanied by a link to a transcript of the content.

Links to sound files need transcripts. 

Links to a sound file should be followed by a link to a transcript of the file.

Link has nondescript text. 

Links should be descriptive of the content they're linking to, such as 'Class Schedule' rather than 'schedule.html' or 'click here'.

Content length should not exceed 3000 words. 

For content longer than 3000 words, consider splitting it up into multiple documents. This makes it easier for students to process and retain the information. 

Input images should have an “alt” attribute 

Every form image button which has text within the image (say, a picture of the word 'Search' in a special font), should have the same text within the 'alt' attribute.

Headings should be used in content 

If appropriate, add headings to the page to organize the content for sighted and screen reader users. The headings should represent an accurate outline of the content.

Object interface must be accessible 

Object content should be assessed for accessibility. This object cannot be checked using automated tools, so it should be reviewed manually.

Object should have long description 

Objects might require a long description, especially if their content is complicated.

Object tag detected 

Multimedia embedded using the 'Object' tag may require the user to install a plugin for their web browser. This can create support and access issues for some users. Additionally, users on mobile devices may not be able to view the multimedia content at all. Consider using an alternative format that the user's browser can display natively.

Avoid using styles for document structure. 

Bold and Italics are used to emphasize text, whereas headings are used to define the structure of the document. Headings like h1-h6 are extremely useful for non-sighted users to navigate the structure of the page and formatting a paragraph to just be big or bold, while it might visually look like a heading, does not make it one.

“Pre” elements should not be used for tabular data 

If a preformatted text element is used for tabular data, change the data to use a well-formed table.

External Resources



Keywords:
accessibility barriers corrections course checker 
Doc ID:
148291
Owned by:
Learn@UW Madison in Learn@UW-Madison
Created:
2025-02-12
Updated:
2025-02-13
Sites:
DoIT Help Desk, Learn@UW-Madison