Making LibGuides

Making LibGuides accessible benefits all users. Review our recommendations to improve accessibility in your guides.
 

We can use heading styles in the LibGuides Rich Text Editor. Headings are not just for aesthetics! 

They provide structure to the website and users with screen readers often navigate web pages by jumping back and forth between headings and sub-headings. Headings are denoted in html as <h1>, <h2> and so on. Fortunately, Springshare turns off <h1> and <h2> headings by default. This is because your guide name is <h1> and your boxes are <h2>.  

If you’re using floating boxes, apply H2 using the HTML source editor for any second-tier headings within your box. For subsequent headings, continue to apply corresponding heading levels (H3, H4, etc.) as needed. 

When chunking out your content in the text editor, be sure to use heading 3 styles <h3>. This will keep the proper page structure. Review the LibGuide's Paragraph Formats guide for more information.

EXAMPLE:

h1 (What the page is about-- the title of your LibGuide)

• h2 (subdivision of page content--a box in LibGuides)
  • h3 (subdivision of subdivision-- the headings inside your Rich Text Boxes)   

Avoid using serif fonts, as they can be more difficult to read.

Similarly, avoid text that is too small or too large. Instead, use headings as needed to visually organize your content. 

Use bold, color, italics, and ALL CAPITAL LETTERS with caution.

Avoid using underlined text for emphasis. In a web medium, users will likely think underlined text is a hyperlink.

Watch out for inconsistent text formatting when you copy and paste from outside sources. This can sometimes create color contrast or accessibility issues. If content does not appear consistent with the Pratt Style, open the Rich Text Editor, highlight the content, and click the Remove Format button--it looks like this:   

Use links often, but be sure to link to stable sources and use descriptive language. When adding library databases to your guide, use the LibGuide Databases Asset tool. This will ensure that the link is stable. Similarly, when linking resources from our discovery layer, use EBSCO Permalinks. When determining what text to use for linking, avoid vague words like "here,"  "link," or "this." Use descriptive and active phrases whenever possible.  For example, if you're linking to an article, use the the title of the article as the hyperlinked text. See Writing Hyperlinks.

Linking to a new tab vs. same tab

In general, your links should open in the same window. It is possible set your links to open in a new tab, but this should only be done in scenarios where we would expect the user to need both tabs open (such as filling out a form and referring to a guide). Many assistive tools like screen readers do not announce to users when links open to a new tab and this experience can be jarring for them. Additionally, it should be noted that all links can be voluntarily opened in a new tab by CTRL+clicking or right-clicking>open in a new tab. However, if you force a link to open a new tab, you take that choice away from the user. That said, if you need to, you can link to a new tab by clicking clicking the "Target" tab and select the New Window "_blank" option. For more information about this, read Linking to a New Tab vs Same Tab.

Link Checker

LibGuides has a tool to check for broken links. It's a good practice to check your guides at least once a semester. Learn how to use the tool with Springshare's Link Checker Guide.

Avoid using tables unless you need to show data mapped to columns and rows. Please don't use tables for content formatting. If you need to use tables, please consult WebAim's Guide to Making Accessible Tables.

<img alt="Pratt Institute Libraries" src="//libapps.s3.amazonaws.com/accounts/151514/images/PIL_Logo_Black_Background.jpg/>

When non-sighted users visit our website, screen reader software reads the content aloud which helps them accomplish two tasks: navigate the website and comprehend the site's content. If an image is on the page, associated alternative text will be read to the user, but only if the content editor has included it. If there is no alternative text, the user misses out on important content. This can be confusing or provide an incomplete experience of the web page. 

We need to provide alt-text to all non-decorative images so that non-sighted users can access all of the content on the page. For tips on how to phrase your alt-text and when to use it, I recommend that you read the Webaim guide to alternative text.

When you insert an image with the LibGuides Text editor, you will see the Alternative Text field beneath the image URL. This is where you insert text to describe the item.

Per WebAIM, alternative text (or Alt text):

• Be accurate and equivalent in presenting the same content and function of the image.
• Be succinct. This means the correct content (if there is content) and function (if there is a function) of the image should be presented as concisely as is appropriate. Typically, no more than a few words are necessary, though in rare cases, a short sentence or two may be appropriate.
• Don't be redundant or provide the same information as text within the context of the image.
• Don't use phrases like "image of ..." or "graphic of ..." to describe the image. It's usually apparent to the user that it is an image. And if the image is conveying content, it is typically not necessary that the user knows that it is an image that is conveying the content, as opposed to text. If the fact that an image is a photograph or illustration, etc. is important content, it may be useful to include this in alternative text.