Skip to Main Content
Chat With Us

LibGuides Standards and Best Practices



Why is web accessibility important?

The Web is fundamentally designed to work for all people, whatever their hardware, software, language, location, or ability. When the Web meets this goal, it is accessible to people with a diverse range of hearing, movement, sight, and cognitive ability.

Thus, the impact of disability is radically changed on the Web because the Web removes barriers to communication and interaction that many people face in the physical world. However, when websites, web technologies, or web tools are badly designed, they can create barriers that exclude people from using the Web.

Quote from the W3C.

Content styling

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


Screenshot of table properties menu in LibGuides.
  • 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.

Header A Header B
cell A1 cell B1
cell A2 cell B2


  • 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. Screenshot showing the Description Display option to choose, which is Display beneath item title.
  • 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.

Copying & Pasting

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 (Button to use for removing all formatting from selected text in the rich text editor.) 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.Screenshot of how to add alternative text to an image within the rich-text editor.
  • 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.

Embedded Media

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.

PDFs and other non-HTML content

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.