Making LibGuides

<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.

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>. 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)   

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.

General Tools

• WebAIM WCAG Checklist
• W3C Web Accessibility Initiative's How to Meet WCAG (Quick Reference)
• W3C Web Accessibility Evaluation Tools list of evaluative tools
• W3C’s Easy Checks: A First Review of Web Accessibility

Auditing Tools

• WebAIM’s Wave - Web Accessibility Evaluation Tool - includes website and browser extensions
• Tota11y illustrates how sites perform when used with assistive technologies
• Axe  - Accessibility Checker for Developers, Testers, and Designers in Chrome
• Pa11y is a command-line interface which loads web pages and highlights any accessibility issues it finds.
• Functional Accessibility Evaluator (FAE)
• Universal Design Online Content Inspection Tool - or UDOIT - audits course materials on Canvas by Instructure
• Multiguideline Accessibility and Usability Validation Environment considers international laws and standards of accessibility
• A11Y Bookmarklets - designed for evaluating web accessibility, but are not necessarily tools for web developers. 

Tutorials

• W3C’s Web Accessibility Initiative Web Accessibility Tutorials
• Mozilla Developers Network Accessibility tutorials