Skip to Main Content
Banner Image

Accessibility for LibGuides

Accessibility guidelines and tips for creating or modifying LibGuides

Why Accessibility?

Everyone is entitled to equal access to resources that UTA publishes online including those who:

  • Have visual impairments such as low vision, blindness, and color blindness.
  • Have reading impairments such as dyslexia.
  • Have difficulty using touch screens, a computer mouse, or keyboard due to tremors, paralysis, or other disorders affecting fine motor control.
  • Have hearing impairments including partial loss of hearing and deafness.
  • Have processing or memory impairments that impact the speed at which they are able to take in and understand information.

We can never predict when someone might be using assistive technologies to access our website.  However, we can create websites that anyone can access and interpret using such tools.  No one should have to come to us and ask for a website to be made accessible for them.  Requiring a person to first discover that something is not accessible, and then contact someone to make it accessible, is itself a barrier to access.

It's the law- Title II of the Americans with Disabilities Act requires state and local governments to make sure that their services, programs, and activities are accessible to people with disabilities.  This includes any services, programs, or activities offered online or through mobile apps.

As a public university, UTA is a state entity.  If we do not comply with ADA, we could be sued for not providing equal access under the law.  For more information visit this ADA requirements website from the US Department of Justice Civil Right Division.

Accessible design makes things easier for everyone.  Many of the principles of accessible design make websites easier to access and read period, regardless of whether someone has a hearing, vision, mobility, or other impairment.

Specific Guidelines

Creating Accessible Text

Choosing a Font:

Sans-serif fonts are recommended as the most accessible types of fonts. Sans-serif fonts lack the decorative strokes found with serif fonts, increasing readability with more block-like lettering. When typing directly in the LibGuide rich text editor it may be better to stick with the default Libuides font, which is a sans-serif font.

However, serif fonts are still valid. When selecting a font it is important to consider the availability and how widely used a font is. For example, Times New Roman font is a widely used and available serif font.

Recommended Fonts:

  • LibGuides Default Font (sans-serif)
  • Verdana (sans-serif)
  • Tahoma (sans-serif)
  • Arial (sans-serif)
  • Helvetica (sans-serif)
  • Times New Roman (serif)
  • Calibri (sans-serif)

Style:

  • Use the bold or italics buttons within the rich text editor to add emphasis, or the <strong> and <em> tags respectively in HTML. Use these effects sparingly.
    • Avoid using the older bold <b> or italics <i> tags as they are used more stylistically and less for emphasis.
  • Don't use underlines for emphasis. Underlined text can be confused for hyperlinked text.
  • Don't use all caps for emphasis. Some screen readers read a string of capitalized letters letter-by-letter.

Copy and Paste:

  • Text that is copied from an outside source and pasted in the rich text editor may include a lot of unnecessary code that can trip up screen readers and can overall make the text inaccessible.
  • If you do copy and paste text, be sure to use the remove formatting button found in the rich text editor.

How to Use Headings

Within LibGuides, headings are used to indicate sections and sub-sections. Headings provide a hierarchical structure to a page and range from Heading 1 (<h1> tag in HTML) being the most important, down to Heading 6. Heading 1 is never used other than to title the entire page, while Heading 2 is used for LibGuide box titles. Users should start with Heading 3. Headings are used in a hierarchical structure, meaning lower level headings should always be placed under higher level headings.

Example:

  • Heading 3 (<h3>)
    • Heading 4 (<h4>)

Headings are also an important feature for screen readers as they make it easier for the readers to scan and jump from section to section of different content areas within your guide.

Using an accessibility checker like the WAVE tool can reveal what text is labeled as heading text.  This is handy when a program or platform assigns heading text for you.  As previously mentioned, the LibGuide platform automatically marks the title of a page as h1 (heading 1) and each box title as h2 (heading 2).  This is why you will only be able to select heading 3 or below within your text boxes.

Screenshot showing h1 next to the title of this website and h2 next to the first subsection.

Embedding Accessible Video:

When embedding a video in your LibGuide there are two important factors to consider

  1. Videos should include accurate closed captions and/or transcript
  2. Ensure an accurate title attribute is included in your video embed code.

For closed captions and/or video transcripts, it is important that LibGuide creators watch the videos they embed to make sure that captions/transcripts accurately reflect what is being said in the video. Also, when embedding a video it is important to include a title attribute in the embed code because this allows screens readers to read out the videos assigned title instead of the video file name.

Example:

<iframe width="560" height="315" src="https://www.youtube.com/embed/kpd-YihCDXU?si=aPbaXtIELIzw5NhJ" title="UTA Libraries" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>

What is alt text?

Most images should have alternative text (alt text) to provide a text description of the information conveyed by an image.  This is especially helpful for someone using a screen reader, a program that reads the content of websites out loud to a user.  However, this text will also show if an image fails to load, and search engines use alt text to provide relevant search results.

Good alt text:

  • Provides the same information that a sighted viewer would gain from looking at the image.
  • Does not repeat information found in the caption or nearby text.
  • Does not include phrases like "Image of...".  A screen reader will announce "image" or "graphic" before reading the ALT text.

Screenshots

The most common alt text challenges in subject guides involve screenshots.  You should never ONLY use screenshots to illustrate a process or task.  This would exclude anyone who cannot see or visually interpret the screenshot.

The easiest way to deal with screenshots is to describe the process fully in text and use the screenshots only as a secondary way to convey information.  Remember to describe where buttons, boxes, and other features are on the screen in your written instructions (to the left of the screen, below the search box, etc.). Then your alt text would be something like "screenshot showing the steps written below."

For a more detailed discussion of screenshots, please see the screenshots tab.

Other graphics and contrast

Infographics, flowcharts, and other graphics can also be challenging.  Again, ask yourself "what information am I getting from this?"  Then make sure that information is included in alt text, a caption, or in text form nearby.  Consider whether you can provide the same information in a table, list, or some other format.  For example, "If the situation is X, Y, and Z then you use tool A to conduct your research" might convey the same information as a decision flowchart.

If an image has text included, remember that a screen reader will not read the text within that image.  Additionally, someone who has color blindness or low vision may not use a screen reader, but may rely on the contrast between the text color and the background color.  Images with embedded text should have sufficient contrast so that the text can be easily read.  The alt text should also describe the text within the image if it is not provided somewhere else nearby.

If a graphic is purely decorative you can leave the alt text blank, but decorative images should be rare in subject guides.

QR Codes

Though QR codes are rarely used in LibGuides it's important to be aware that screen readers may not read QR codes correctly, and these same guidelines apply wherever QR codes are used.  Your alt text should indicate that the image is a QR code, and an additional link to the same target should always be provided above or below the QR code as an alternative form of access.

Screenshots

The most common alt text challenges in subject guides involve screenshots.  You should never ONLY use screenshots to illustrate a process or task.  This would exclude anyone who cannot see or visually interpret the screenshot.

The easiest way to deal with screenshots is to describe the process fully in text and use the screenshots only as a secondary way to convey information.  Remember to describe where buttons, boxes, and other features are on the screen in your written instructions (to the left of the screen, below the search box, etc.). Then your alt text would be something like "screenshot showing the steps written below."

When and How to Use a Table:

Tables should not be used simply to organize information in a visually pleasing way.  Tables should primarily be used to display data or other information that makes sense to display in a table. 

Tables require special HTML markup to make the columns and rows read properly for a screen reader.  The LibGuide platform will do this for you if you use the table creator within the "Add Rich Text/HTML" screen.  The icon looks like a small table and falls between the "image" and "insert horizontal line" option in the lower tool bar.

Screenshot showing table icon as described above.

Once you click on the table icon a box called "table properties" will appear.  Indicate the number of rows and columns that your table should be using the labeled boxes.  Next, selected which row or column (or both) are your headers.  It is required that you indicate headers so that the table will be read properly by screen reading tools.  Next, create a caption for your table- this is like the title.  Then fill out the summary- this is like alt text for images, it tells someone using a screen reader what general information the table is conveying so they can choose whether or not they want to read each cell individually using their screen reader.  The final option is "class" and allows you to choose different display styles.

Screenshot showing the table properties box described above.

 

Links, Buttons, and Other Clickable Features:

There are two types of disabilities to keep in mind when it comes to links and clickable features- vision impairments and mobility impairments.  Though these accessibility adjustments may be helpful for other types of impairments as well.

Someone who is blind or has vision loss/low vision may use a screen reader to quickly scan through a page for links.  If the link itself does not have enough context embedded in it, the reader may not understand where the link goes without laboriously going through the text to find out.  Context is provided by the display text of the link.

Examples:

  • To read more about accessibility "click here." - The click here, if read independent from the text, does not give any indication of where the link will go.
  • You can "read more about accessibility here." - This tells someone using a screen reader that the link is sending them somewhere to read more about accessibility.

Someone who has a mobility impairment may be using an alternative mouse device, touch screen, or other tool to click on features.  Imagine someone who has a tremor or other fine motor control impairment- would that person be able to click on a feature without accidentally clicking on something else they weren't interested in?  Is the clickable feature or link large enough for that person to target it accurately? 

Ideally, links should not follow one another side by side or line over line.  There should be some space between clickable features or links and they should be large enough that someone is not in danger of accidentally clicking on something else by mistake.  They should also be large enough so that the user does not have to struggle to target a feature accurately.  This is one of the reasons we discourage the use of the carousel feature in LibGuides.

Carousels, slideshows, and similar features:

In general we advise against using carousels, although the carousel feature built into LibGuides should, in theory, be accessible. 

Carousels should be set to not auto-advance or users must be able to pause the movement of the carousel.  The underlying structure should also be such that a screen reader can navigate the controls properly.  This should be automatic in LibGuides.

Carousel features often have clickable features that are too small and/or too close together for those with mobility impairments to use them easily.  The movement may also be distracting or unpleasant for some people.  A carousel that auto-advances may move too quickly for some people to process what they are seeing.  This is why we advise against using them, even the ones built into the LibGuides platform.

Errors that Cannot Be Fixed

At this time, there are some alerts that WAVE and other accessibility tools will flag on each of our guides that guide owners cannot fix. This is because sections like the header and footer are not customizable to us. We have met with marketing and are hopeful that these issues will be fixed soon but, for now, please note that the following errors and alerts will show up, but you are unable to address them.

Suspicious alternative text: Banner image

We are unable to edit the UTA Libraries logo that appears at the top of each guide, and therefore cannot replace the inadequate alt text.

Redundant link

The links in the headers and footers of each guide trigger the “redundant link” alert but, again, cannot be removed or edited by guide users. However, pay attention to the alerts to ensure they are not referring to a section that is not in the header or footer.

Very small text

Several elements of the footer, including tags, date edited, and the URL, will be flagged as having very small text, but we are currently unable to enlarge this text. Again, be sure that these alerts are referring to only these elements and not other sections of your guides.

 

Tools for Checking

Accessibility at UTA:

UTA EIR Accessibility Training- Sign up for training in making accessible electronic documents, PDFs, and PowerPoints

UTA EIR Best Practices- Learn best practices for multiple types of electronic media from e-mail to podcasts and much more.

Resources from Springshare:

Springshare is the parent company of the LibApps suite.  They have many resources to help you use LibGuides more effectively.

Springshare Blog- Search for articles with accessibility tips and updates.

Springshare Training Calendar- This page also has a link to recorded sessions.

Accessibility Checker:

WAVE (Web Accessibility Evaluation Tool)- Using the WAVE website to check a webpage's accessibility is quick and easy. You simply enter the URL of the page into web address box to get an accessibility report. There is also a WAVE browser extension for ChromeFirefox, and Edge that allows for accessibility testing directly from your browser.

WAVE Help- This page describes what the different icons from the WAVE tool mean and other tips for WAVE effectively.

Site Improve- You can access Site Improve from your UTA My Apps page, however only administrators can actually use the tool to run a report that checks for accessibility issues.  In practice we have found that using the WAVE tool above is more helpful than Site Improve.

Color Checker:

WebAIM- Color contrast is an important measure of the accessibility of a page. Correct levels of color contrast make it easier for everyone, especially those with impaired vision, to read and understand web text. The optimal color contrast ratio for body text is 4.5:1 and 3:1 for images. Use this WebAIM color contrast tool to check if your text meet that optimal ratio

Contrast Checker from Acart- Another contrast checker that also allows you to check at what font size something becomes inaccessible and allows you to switch to grayscale.

Testing for Color Blindness Accessibility- Describes different types of color blindness and recommends tools for checking if your images are accessible to someone with colorblindness.

Coblis- Color Blindness Simulator- Tool that attempts to simulate what images look like to people with different types of colorblindness.

Screen Reader:

JAWS- One of the more common screen readers.  The license is free, but it must be renewed every year.  It is recommended that you install the screen reader and use it to check things like websites, PDF documents, and PowerPoint slides.  It also gives you an idea of why certain elements might be a problem.

Other Screen Readers from the American Foundation for the Blind- Describes many other screen readers and tools that those with blindness or vision impairment might use and the different features that are offered with each tool.