Skip to Main Content

Creating Accessible LibGuides

This guide presents information about how to create and format content in LibGuides to reach as many students as possible, including those using assistive technologies.


For questions about using the Creating Accessible LibGuides resources or about web accessibility in general, contact


The majority of the criterion under coding relate to the overall setup of LibGuides, which is controlled by Admin. There are a few specific requirements for individual guide creation, which are listed in the checklist below.

Coding Checklist

Level A

  • Content can be operated through a keyboard or keyboard interface without requiring specific timings for individual keystrokes. If a function cannot be done with a keyboard (e.g. handwriting), an alternate option is provided (Success Criterion 2.1.1)
  • If the same information is found on several different pages within a website, it can be skipped through a programmed command (Success Criterion 2.4.1)
  • All code elements (ie. HTML) are accurate and complete (Success Criterion 4.1.1)

Level AA

  • Include HTML/ARIA cues when a section of text is in a different language than the primary language of the webpage (Success Criterion 3.1.2)

Level AAA

  • Use correct markup language to identify the purpose of buttons, links, fields, etc. so user can determine the purpose using assistive technology (Success Criterion 1.3.6)

Success Criterion 1.3.4: Orientation

Orientation (Level AA)

The orientation of content is not restricted to either portrait or landscape, unless the display orientation is essential.  

*Note - Examples of necessary orientation include bank checks, music scores or projector slides.


Success Criterion 1.3.5: Identify Input Purpose

Identify Input Purpose (Level AA)

The purpose of an input field (ie. on a form) can be determined using assistive technology. View a list of common Input Purposes for User Interface Components.

Success Criterion 1.3.6: Identify Purpose

Identify Purpose (Level AAA)

Use correct markup language to identify the purpose of buttons, links, fields, etc. so user can determine the purpose using assistive technology.


WCAG example:

Icons on a website use markup language so that users can substitute their own icon or vocabulary into the page.

Success Criterion 1.4.10: Reflow

Reflow (Level AA)

Content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions for: 

  • Vertical scrolling at a width of 320 CSS pixels;
  • Horizontal scrolling at a height of 256 CSS pixels;

Exceptions are for content which need two-dimensional layout for usage or meaning.

*Note - Excepted content that requires two-dimensional layout include video games, data tables, maps, diagrams.


WCAG example:

A site uses responsive design. When a person zooms in to over 300%, the layout is reflowed to one column. The user can read the content easily and does not have to scroll sideways to read.

Success Criterion 1.4.11: Non-text Contrast

Non-text Contrast (Level AA)

The contrast ratio for the following visual presentations must be 3:1 for neighbouring colors:

  • User Interface Components - These components should be quite distinct, except if it is not currently being used or the user can adjust the color settings themselves.
  • Graphical Objects - The graphics that represent important information should be distinct from one another.

Success Criterion 1.4.13: Content on Hover or Focus

Content on Hover or Focus (Level AA)

When hovering with the mouse or focusing the pointer over content makes additional material becomes visible (popup), it should be:

  • Dismissible - The additional content is easily removed without moving the mouse or keyboard focus, except when stating an error.
  • Hoverable - If the mouse/keyboard can uncover the additional content, it can also make it stay when the mouse moves again;
  • Stuck - The hovered text stays until the pointer is removed, the user dismisses it, or it no longer applies to where the pointer is focused.

Exception: The user agent can control these functions and not the author.

*Note - See examples of user agent control with the HTML title attribute.

*Note - Tool-tips, sub menus and non-modals are covered by this requirement.

Success Criterion 2.1.1: Keyboard

Keyboard (Level A)

Content can be operated through a keyboard or keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints (ie. things that cannot be reasonably controlled by a keyboard).  


*Note - There is a small class of input that is done with a pointing device that cannot be done from the keyboard in any known fashion without requiring an inordinate number of keystrokes (eg. handwriting). If a function cannot be done with a keyboard, the final input has an exception (eg. text input instead). 

*Note - This requirement should not forbid or discourage providing mouse input or other input devices in addition to keyboard.


WCAG example:

An application that uses drag and drop also supports "cut" and "paste" or form controls to move objects.


Success Criterion 2.1.2: No Keyboard Trap

No Keyboard Trap (Level A)**

Using the keyboard to focus on a part of the page can be also be undone with only the keyboard. If moving away requires more than normal keyboard input (unmodified arrow or tab keys or other standard exit methods), the way to move away is clearly identified.


WCAG example:

A Web application brings up a dialog box. At the bottom of the dialog are two buttons, Cancel and OK. When the dialog has been opened, focus is trapped within the dialog; tabbing from the last control in the dialog takes focus to the first control in the dialog. The dialog is dismissed by activating the Cancel button or the OK button.

**This is a non-interference requirement. See Conformance Requirement 5: Non-Interference

Success Criterion 2.1.3: Keyboard (No Exception)

Keyboard (No Exception) (Level AAA)

The user can operate the entire website and all functions through the keyboard without requiring timings for individual keystrokes.

Success Criterion 2.1.4: Character Key Shortcuts

Character Key Shortcuts (Level A)

If keyboard shortcuts are used with letters, numbers, punctuation or symbols, then:

  • Turn off -  Users can turn off the shortcut;
  • Remap - Remapping allows users to create key combinations as shortcuts. Any shortcuts that have been included should be able to be remapped by the user;
  • Active only on focus - The keyboard shortcut only works when the part of the webpage that requires it is being actively used.


WCAG example:

A mechanism is provided to allow users to disable character-key shortcuts. The character key shortcuts are not the only way to carry out these commands. A speech user disables the shortcuts and can prevent words that are picked up by the microphone from triggering single-key shortcuts.

Success Criterion 2.4.1: Bypass Blocks

Bypass Blocks (Level A)

If the same information is repeated on several different pages within a website, it can be skipped through a programmed command.

Success Criterion 2.4.5: Multiple Ways

Multiple Ways (Level AA)

There is more than one way to locate a page within a website, unless the web page is the next step in a process.


Example: A menu and a search box. 


Success Criterion 2.4.7: Focus Visible

Focus Visible (Level A) [Changed for WCAG 2.2]

A user using a keyboard for navigation has the option to see the keyboard focus indicator.


WCAG example:

When text fields receive focus, a vertical bar is displayed in the field, indicating that the user can insert text, OR all of the text is highlighted, indicating that the user can type over the text.

Success Criterion 2.4.8: Location

Location (Level AAA)

The user can always figure out where they are located within a website (eg. breadcrumbs).

Success Criterion 2.4.11: Focus Appearance (Minimum)

Focus Appearance (Minimum) (Level AA) [New for WCAG 2.2]

When the user has a keyboard focus indicator, the following must occur:

  • Minimum area - The focus indication area is greater than or equal to a 1 CSS pixel border or has a thickness of 8 CSS Pixels on the short side;
  • Change of contrast - The focus area colour compared to the non-indicated area colour must have a 3:1 ratio;
  • Adjacent contrast - The focus indication area has a contrast ratio of at least 3:1 against all adjacent colors for the minimum area or greater, or has a thickness of at least 2 CSS pixels;
  • Unobscured - The item with focus is not entirely hidden by author-created content.

*Note - The 3:1 contrast ratio may not always apply to a pattern or gradient, as long as the minimum maintains this contrast.

*Note - The size of the visible boundary is used to measure if the control has a smaller boundary.


WCAG example:

When links receive focus, an outline is displayed around the link that contrasts with the background adjacent to the link.

Success Criterion 2.4.12: Focus Appearance (Enhanced)

Focus Appearance (Enhanced) (Level AAA) [New to WCAG 2.2]

The keyboard focus indicator must have/be:

  • Minimum area - Focus indication area >2 CSS pixels
  • Change of contrast - Color contrast marking changes must have a ratio of 4.5:1
  • Unobscured - The focus area is not covered by author content.


WCAG example:

When text fields receive focus, an outline is displayed around the field, indicating that the input has focus.

Success Criterion 2.5.1: Pointer Gestures

Pointer Gestures (Level A)

All functions that use multipoint or path-based gestures for operation (eg. two finger pinch to zoom) can be operated with a single pointer without a path-based gesture, unless a multipoint or path-based gesture is essential.
*Note - This only applies to the web page itself and not related to the use of assistive technology.


WCAG example:

A web site includes a map view that supports the pinch gesture to zoom into the map content. User interface controls offer the operation using plus and minus buttons to zoom in and out.

Success Criterion 2.5.2: Pointer Cancellation

Pointer Cancellation (Level A)

 If a single pointer can be used, at least one of the following are true:

  • No down-event - When the pointer is pressed down (down-event), it does not execute any function.
  • Abort or Undo - The function is executed when the pointer is released (up-event) and there is a way to undo or abort the function after it's complete.
  • Up-Reversal - The up-event reverses the down-event;
  • Essential - Ending the function on a down event is necessary.

*Note - Functions that act like a keyboard or numeric keypad are essential.
*Note - This applies to web pages that present pointer actions (no assistive technology required).


WCAG example:

For interface elements that have a single tap or long press as input, the corresponding event is triggered when the finger is lifted inside that element.

Success Criterion 2.5.4: Motion Actuation

Motion Actuation (Level A)

Functions triggered by moving a device (eg. shaking or tilting) or by gesturing towards the device (so that sensors like a camera can pick up and interpret the gesturing), can also be operated by more conventional user interface components, except when:

  • Supported interface - The motion is part of an accessibility supported usage;
  • Essential - The motion is absolutely necessary for the function.


WCAG example:

A user can choose an application setting which turns off Shake to Undo and other motion-activated features.

Success Criterion 2.5.5: Target Size

Target Size (Level AAA)

The size of the target for pointer inputs is at least 44 by 44 CSS pixels, except when:

  • Equivalent - There is another link on the same page that is at least 44x44 CSS pixels;
  • Inline - The target is part of a sentence or block of text;
  • User Agent Control - The user can change the size of the target;
  • Essential - It is absolutely necessary for the content.


WCAG example:

Three buttons are on-screen and the touch target area of each button is 44 by 44 CSS pixels.

Success Criterion 2.5.8: Pointer Target Spacing

Pointer Target Spacing (Level AA) [New to WCAG 2.2]

For each target, there is an area with a width and height of at least 44 CSS pixels that includes it, and no other targets, except when:

  • Enlarge - An option to change the size of an individual target to 44x44 CSS pixels;
  • Inline - The target is within text;
  • User agent - The user can control the size of the target;
  • Essential - It is necessary to function.


WCAG example:

Three buttons are on-screen and the target area of each button is 24 by 24 CSS pixels. Since the target size itself is 24 by 24 CSS pixels, no additional spacing is required, the Success Criterion passes.

Success Criterion 3.1.1: Language of Page

Language of Page (Level A)

The human language of a webpage can be determined through assistive technology.


WCAG example:

A Web page produced in Germany and written in HTML includes content in both German and English, but most of the content is in German. The default human language is identified as German (de) by the lang attribute on the HTML element.

Success Criterion 3.1.2: Language of Parts

Language of Parts (Level AA)

If a passage or phrase is in a different language than the webpage's language, this can be programmatically determined. It is not necessary to label different language for: proper names, technical terms, words of indeterminate language and vernacular. For example: when adding a passage in French on a page where English is the primary language, use HTML/ARIA to identify the portion that is in a different language.


WCAG example:

In the sentence, "He maintained that the DDR (German Democratic Republic) was just a 'Treppenwitz der Weltgeschichte'," the German phrase 'Treppenwitz der Weltgeschichte' is marked as German. Depending on the markup language, English may either be marked as the language for the entire document except where specified, or marked at the paragraph level. When a screen reader encounters the German phrase, it changes pronunciation rules from English to German to pronounce the word correctly.

Success Criterion 3.2.2: On Input

On Input (Level A)

If the user interacts with content it does not change the context unless the user is warned beforehand. The intent of this Success Criterion is to ensure that entering data or selecting a form control has predictable effects.

Changes of context are appropriate only when it is clear that such a change will happen in response to the user's action (eg. a link is labeled as 'opens in new window').


WCAG example:

Individuals who are blind or have low vision may have difficulty knowing when a visual context change has occurred, such as a new window popping up. In this case, warning users of context changes in advance minimizes confusion when the user discovers that the back button no longer behaves as expected.

Success Criterion 3.2.1: On Focus

On Focus (Level A)

When any user interface component receives focus, it does not initiate a change of context.


WCAG example:

Examples of changing context when a component receives focus include, but are not limited to:

  • forms submitted automatically when a component receives focus;
  • new windows launched when a component receives focus;
  • focus is changed to another component when that component receives focus;

Success Criterion 4.1.1: Parsing

Parsing (Level A)

In the code, all the commands are completely written with no missing tags, they are located within the correct nest structure, are not duplicated and have unique IDs, except in certain arts that allow this.

*Note - If the command tags are written incorrectly or are missing characters (I.e. closing angle bracket), they are not complete.


"Copyright © 2020 W3C® (MIT, ERCIM, Keio, Beihang). This software or document includes material copied from or derived from Web Content Accessibility Guidelines (WCAG) 2.2."