LibGuides Standards and Best Practices

• Don't use color as a way to convey meaning or importance. Colorblind users and screen readers may not color emphasis.
• Don't mix different fonts. Stick to the default font of the rich text editor. 
• Avoid changing the font size unless you have good reason. If you need break up sections of content within a text box, use Heading 3 and Heading 4 in the rich text editor, or use <h3> and <h4> tags in the HTML code.
• Only hyperlinks should be underlined. No other text should be underlined except for very specific citation formatting.
• Use bold or italics in the rich text editor (or <strong> or <em> tags in HTML) to indicate emphasis. Use these tags sparingly. 
• When editing HTML code, avoid older-style bold <b> or italics <i> tags as they denote style rather than semantics.
• Avoid relying on non-HTML content that may not be accessible, like PDF or PowerPoint documents.
• Avoid unnecessary all-uppercase formatting.

Use rich text Headings as indicators for sections and sub-sections in your guide. This not only provides hierarchical organization and formatting but also makes it easy for screen readers to scan and jump to different content areas.

• Never use Heading 1 (<h1> tag in HTML) in your guide as this should only be used once for the entire page.
• LibGuides uses Heading 2 for box titles so only use Heading 3 (<h3> tag in HTML) and below in rich text boxes.
• Always nest headers based on their hierarchy: <h3> should contain <h4> tags and so forth.
• LibGuides has removed <h1> and <h2> tags in the rich text editor for WCAG2 compliance.

• Only use tables for tabular data that fits well into rows and columns.
• Don't use tables to arrange or position page elements like images. This hurts users that rely on screen readers.
• Use table headers to describe the contents of the table columns.
• Avoid spanned rows as screen readers may not properly parse them.
• Tables created with the rich text editor have special styling to make them work well with responsive design. No need to manually change the table's width or cell padding.

Here is an example default 2x2 table with a header created within the rich text editor.

• Make sure link and database assets display their description below the link. Don't hide the description behind a hover-over button as this breaks accessibility. 
• Break up long list of items into logical groups so that it can be skipped by screen readers.
• Make sure linked text makes sense out of context. Ambiguous phrasing obscures what the link is about.
  • Bad: Click here for directions.
  • Good: Directions to Boston College are available online.
  • Bad: Learn more about LibGuides here and here.
  • Good: Learn more about logging into LibGuides and how to create your first guide.

Take caution when copying & pasting content from any source. Many times hidden style code will also be copied along that could break with best practices and introduce inaccessible content.

There are a few ways to avoid hidden style code from being placed into your guide.

• The rich text editor has a Clear Formatting tool () that is helpful. This button will remove all formatting from selected text inside the rich text editor.
• Right-click and select "Paste and Match Style" or "Paste Without Formatting" depending on your browser to paste content without any styling.

This will generally solve strange formatting issues you may find from copied text.

• Almost all images should have Alternate text (ALT tags) included. If an image is purely for decoration then the ALT tag should be left empty.
• You can check an image's ALT text by double-clicking the image when in the rich text edit mode.
• If the image links to a resource make sure the image ALT tag also describes the destination. 
• ALT tags should be very brief and descriptive but not redundant. Don't repeat the same content from the image into the alt text.
• Avoid using "Image of..." since this is understood to be an image.
• WebAIM is a good starting resource for ALT tags principles.

Video and audio content are a great supplement to any guide, but great care must be used to make sure embedded content is accessible.

• Only use captioned videos.
  • There are workflows for captioning internally produced media. BC Library staff can search the internal wiki for instructions.
• Provide captioned text for spoken word audio.
  • A text file is preferable, but including the plain text in the guide adjacent to the embedded audio is acceptable. 
• Be mindful of linking to 3rd party sources that don't use captioning.
  • We're not liable for other's work, but we want to make sure we provide vetted and accessible resources.
• iFrame tags should contains a proper title attribute. 
  • Reach out to the WCC for details on how to check for this.

All non-HTML content should be accessible. If you can't find or create accessible non-HTML content then consider using HTML instead.

Here are some guides and utilities that can aid you in constructing accessible documents.