Below is a list of Priority A and AA Guidelines added to WCAG 2.1 Web Content Accessibility Guidelines. Please note that all guidelines from WCAG 2.0 are still in effect.

Page Content

  1. Guideline 1.3
  2. Guideline 1.4
  3. Guideline 2.1
  4. Guideline 2.5 (NEW)
  5. Guideline 4.1

 

Guideline 1.3: Adaptable

Create content that can be presented in different ways (for example simpler layout) without losing information or structure.

Guideline 1.3.1 to 1.3.3 information

 

New Guideline 1.3.4: Orientation (AA)

Guideline Text (1.3.4)

Content does not restrict its view and operation to a single display orientation, such as portrait or landscape, unless a specific display orientation is essential.

How to Implement 1.3.4

  • Make sure content can be viewed in horizontal or vertical orientation on a mobile device or other display.
  • Exceptions can be made if orientation is crucial to the operation of interface.
  • See additional information on Understanding Guideline 1.3.4

 

New Guideline 1.3.5: Identify Input Purpose (AA)

Guideline Text (1.3.5)

The purpose of each input field collecting information about the user can be programmatically determined when:

How to Implement 1.3.5

"The intent of this Success Criterion is to ensure that the purpose of a form input collecting information about the user can be programmatically determined, so that user agents can extract and present this purpose to users using different modalities. The ability to programmatically declare the specific kind of data expected in a particular field makes filling out forms easier, especially for people with cognitive disabilities." (Understanding Success Criterion 1.3.5)

  • Leverage form field autocomplete technologies such as HTML 5.2 Autofill when possible.
  • Match INPUT field types to the data being collected. Examples from HTML 5 Input Types include password, url, number, time, image and others.
  • Use form field technologies to facilitate data entry including clear labeling with LABEL tags or ARIA.

 

Guideline 1.4: Distinguishable

Make it easier for users to see and hear content including separating foreground from background.

Guideline 1.4.1-1.4.9 information

 

New Guideline 1.4.10: Reflow (AA)

Guideline Text (1.4.10)

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

  • Vertical scrolling content at a width equivalent to 320 CSS pixels;
  • Horizontal scrolling content at a height equivalent to 256 CSS pixels;

Except for parts of the content which require two-dimensional layout for usage or meaning.

How to Implement 1.4.10

  • Ensure that document does not require horizontal scrolling when
    • The screen viewport is shrunk down to 320 pixels wide by 256 pixels tall OR
    • When a viewer magnifies text up to 400% or more
      Note: When a person views content at 400%, the equivalent minimum size would be 1280 by 1024 pixels (i.e. 4 × 320 by 4 × 256).
  • There are exceptions when content (e.g. a diagram, chart or some data tables) must be larger dimensions specified above to be understood.
  • Many documents with fixed layouts such as older PDFs may not comply with this guidelines.

Responsive design and other "fluid" or "liquid" design techniques can help ensure that content reflows optimally at different screen sizes.

These include avoiding specifying fixed widths, line heights and font sizes with fixed pixel values. Relative measurements such as percentages or ems should be used instead.

See also Understanding Guideline 1.4.10.

 

New Guideline 1.4.11: Non-Text Contrast (AA)

Guideline Text (1.4.11)

The visual presentation of the following have a contrast ratio of at least 3:1 against adjacent color(s):

User Interface Components
Visual information required to identify user interface components and states, except for inactive components or where the appearance of the component is determined by the user agent and not modified by the author;
Graphical Objects
Parts of graphics required to understand the content, except when a particular presentation of graphics is essential to the information being conveyed.

How to Implement 1.4.11

  • Colors used for non-text elements must comply with contrast guidelines with the background corresponding to the 3:1 contrast guidelines for large text.
  • These non-text elements include:
    • Clickable icons including logos and social media icons
    • Colors used in informational charts
    • Borders or background colors used to distinguish elements such as buttons, form fields, interface components or data table divisions
    • Text embedded in an image when it is the image is the only source of that information
  • Exceptions are possible for decorative graphics or for cases when the color used is essential to understanding the content.

See also Understanding Guideline 1.4.11.

 

New Guideline 1.4.12: Text Spacing (AA)

Guideline Text (1.4.12)

In content implemented using markup languages that support the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property:

  • Line height (line spacing) to at least 1.5 times the font size;
  • Spacing following paragraphs to at least 2 times the font size;
  • Letter spacing (tracking) to at least 0.12 times the font size;
  • Word spacing to at least 0.16 times the font size.

Exception: Human languages and scripts that do not make use of one or more of these text style properties in written text can conform using only the properties that exist for that combination of language and script.

How to Implement 1.4.12

  • Use of relative sizes such as percentages or ems in specifying line height, spacing after paragraphs, letter spacing or word spacing should ensure that this guideline is reached.
  • The ability of a user to implement their own styles should not be blocked.
  • Many documents with fixed layouts such as older PDFs may not comply with this guidelines.
  • Exceptions are possible for selected non-Western scripts.

See also Understanding Guideline 1.4.12.

 

New Guideline 1.4.13: Content on Hover or Focus (AA)

Guideline Text (1.4.13)

Where receiving and then removing pointer hover or keyboard focus triggers additional content to become visible and then hidden, the following are true:

Dismissable
A mechanism is available to dismiss the additional content without moving pointer hover or keyboard focus, unless the additional content communicates an input error or does not obscure or replace other content;
Hoverable
If pointer hover can trigger the additional content, then the pointer can be moved over the additional content without the additional content disappearing;
Persistent
The additional content remains visible until the hover or focus trigger is removed, the user dismisses it, or its information is no longer valid.

Exception: The visual presentation of the additional content is controlled by the user agent and is not modified by the author.

How to Implement 1.4.13

If an interface uses a dropdown menu, pop up window or modal then ensure the following behaviors are possible.

  • The content does not block other content even when the user magnifies the document.
  • The user can close the content with a mechanism such as using the ESC key or other mechanism independent of the mouse or moving beyond the content.
  • The content does not close until the user chooses to close it (i.e. it does not disappear automatically after a certain time).
  • If mouse hover is one of the triggering events to open content, it remains open even if the mouse moves away from the content unless the user chooses to close the content.
  • Some exceptions exist for error messages.

See also Understanding Guideline 1.4.13

 

Guideline 2.1: Keyboard Accessible

Make all functionality available from a keyboard.

Guideline 2.1.1-2.1.3 details

 

New Guideline 2.1.4: Character Key Shortcuts (A)

Guideline Text (2.1.4)

If a keyboard shortcut is implemented in content using only letter (including upper- and lower-case letters), punctuation, number, or symbol characters, then at least one of the following is true:

Turn off
A mechanism is available to turn the shortcut off;
Remap
A mechanism is available to remap the shortcut to use one or more non-printable keyboard characters (e.g. Ctrl, Alt, etc).
Active only on focus
The keyboard shortcut for a user interface component is only active when that component has focus.

How to Implement 2.1.4

  • If keyboard shortcuts consisting of a single printable character (e.g.letters, numbers, symbols) are implemented, they must comply with the behaviors listed above.
  • Implementing keyboard shortcuts which include a non printable character (e.g. CONTROL, ALT, ENTER) will ensure compliance with this guideline.

See also Understanding Guideline 2.1.4

 

New Guideline 2.5: Input Modalities

Make it easier for users to operate functionality through various inputs beyond keyboard.

Note: This section of the WCAG guidelines is new to WCAG 2.1.

 

New Guideline 2.5.1: Pointer Gestures (A)

Guideline Text (2.5.1)

All functionality that uses multipoint or path-based gestures for operation can be operated with a single pointer without a path-based gesture, unless a multipoint or path-based gesture is essential.

How to Implement 2.5.1

  • Include alternatives (e.g. buttons, simplified gestures or keyboard shortcuts) for complex gestures used on mobile devices or touchpads.
  • Exceptions are made when the complex gesture is essential to the functionality of the tool.

See also Understanding Guideline 2.5.1

 

New Guideline 2.5.2: Pointer Cancellation (A)

Guideline Text (2.5.2)

For functionality that can be operated using a single pointer, at least one of the following is true:

No Down-Event
The down-event of the pointer is not used to execute any part of the function;
Abort or Undo
Completion of the function is on the up-event, and a mechanism is available to abort the function before completion or to undo the function after completion;
Up Reversal
The up-event reverses any outcome of the preceding down-event;
Essential
Completing the function on the down-event is essential.

How to Implement 2.5.2

"The intent of this success criterion is to make it easier for users to prevent accidental or erroneous pointer input. People with various disabilities can inadvertently initiate touch or mouse events with unwanted results. Each of the following subsections roughly aligns with the bullets of this Success Criterion, and outlines a means of allowing users to cancel pointer operations. (Understanding Success Criterion for Guideline 2.5.2)"

  • In other words, ensure that some mechanisms exist to allow users to cancel the action for a button or link the person may have accidentally clicked following the guidelines above.

See also Understanding Guideline 2.5.2

 

New Guideline 2.5.3: Label in Name (A)

Guideline Text (2.5.3)

For user interface components with labels that include text or images of text, the name contains the text that is presented visually.

How to Implement 2.5.3

  • Make sure the underlying interface element name matches the visual label particularly in buttons.
  • When images are interactive or used as labels for commands, the ALT text describes the function, not the actual image (e.g. for a search form with a magnifying glass icon, the ALT text should indicate "Search", not "magnifying glass.")
  • Use options like LEGEND/FIELDSET, LABEL, ARIA Labels with correctly matching name/ids as needed within forms.

See also Understanding Guideline 2.5.3

 

New Guideline 2.5.4: Motion Actuation (A)

Guideline Text (2.5.4)

Functionality that can be operated by device motion or user motion can also be operated by user interface components and responding to the motion can be disabled to prevent accidental actuation, except when:

Supported Interface
The motion is used to operate functionality through an accessibility supported interface;
Essential
The motion is essential for the function and doing so would invalidate the activity.

How to Implement 2.5.4

  • Provide alternatives for shaking/rotation motions such as buttons, simplified gestures or input from a keyboard.

See also Understanding Guideline 2.5.4

 

Guideline 4.1: Compatible

Maximize compatibility with current and future user agents, including assistive technologies.

Guideline 4.1.1 to 4.1.2 information

New Guideline 4.1.3: Status Messages (AA)

Guideline Text (4.1.3)

In content implemented using markup languages, status messages can be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without receiving focus.

How to Implement 4.1.3

  • Make sure status messages (i.e. errors, progress bars, application updates and other types of notifications) are perceived by everyone including those using a screen reader or screen magnification.
  • ARIA can be used in number of scenarios to enable this for screen readers.

See also Understanding Guideline 4.1.3

Top of Page