Accessible LibGuides

Alternative text or alt text is a text replacement for an image and is used to explain what the image is and what the image is trying to convey to the user. It requires populating the Alt Text field in the Image Editor in the LibGuides Rich Text Editor or in the Image Manager in LibApps. 

• All images need alt text, except purely decorative images or images with the text description clearly associated with it within the page's content, like book covers.
• Use null alt text on decorative graphics (alt= "") that don't convey meaning.
• Don't use screenshots of text or images of text.
• Don't use icons without alt text.

Writing Good Alt Text:

• Be precise. Alt text should accurately describe the content and function of the image, except when the image functions as a link. In that case, the alt text should describe the link destination, not the image.
• Be brief. The alt text of an image should be short and to the point. Listening to long alt text can be burdensome for assistive technology users. Longer alt text might also be a problem because it may provide more information to assistive technology users giving a disadvantage to sighted users. Try to keep it to less than 140 characters.
• DON'T repeat information.  
  • If the caption describes the image the way alt text would, then use null alt text (alt= "").
  • Starting with "image of ..." or "graphic of ..." is redundant. Screen readers announce the presence of an image to the user.
• DON'T use the same alt text for different images (e.g., "cover art" for all book images on a page).

Functional Images:

• Images, including icons and logos, that are hyperlinks or that perform an action upon input (e.g. clicking) are functional images.
• Alt text for functional images that are hyperlinks must name the link destination and describe it if necessary, but it shouldn't describe the image. 

References: WCAG 2.2, SC 1.1.1 (Level A): Non-text Content and WCAG 2.2, SC 1.4.5: Images of Text, Web Accessibility Initiative (WAI) functional images tutorial. WAI writes WCAG.

• Always make a data table, not a layout table, to convey meaning to screen readers.
• Layout tables are used for presentation purposes. Without headers or data cells, they frequently yield chaotic, disorganized reading order for individuals using assistive technologies. You could change this in the CSS (Divs) to provide more control over the visual display without compromising the structure, but you can't because it's locked down.
• To make a data table, set table headers when using the table builder in the Rich Text / HTML Editor. In most cases, this will be the first row, but the editor also provides options for the first column and for both the first row and column. If you want to add a more complicated table, you will have to edit the HTML source code directly.
• Use the caption field in the table builder to add the table's title. The caption with the title will appear above the table.
• Anything in the Summary field will only be provided to screen reader users. If there is any important information about the table that blind or low-vision users are unlikely to get, this is a good place to provide that, but keep it relatively short.
• Keep the default class. The table styles have been modified for accessibility, so changing the class should not actually change anything.
• If you change any colors, remember to check the contrast of the background color and font to see if they pass accessibility guidelines using a tool like Web AIM's Contrast Checker.

References: WCAG Success Criterion 1.3.1 (Level A): Info and Relationships, WCAG 2.2, SC 1.3.2 (Level A): Meaningful Sequence

Resources: Web AIM's Creating Accessible Tables