Accessibility Self-Audit Training Sessions

Session 6 WCAG 3.1.1 through 3.3.4

Overview

Training Topic and Success Criteria

The WCAG criteria that are covered in this session include:

There are ten different criteria that are covered in this session. They deal with the following:

  • Using the proper language attributes to note English and other languages.
  • Avoiding unexpected changes.
  • Input assistance when filling out forms.

Prep Work and Session Recording

Recording

What You Need for this Session

For this part of the audit you will need:

Session 6 Audit: WCAG 3.1.1 through 3.3.4

WCAG 3.1.1 through 3.3.4 cover things such as setting the language of the page, setting the language of items in other languages, avoiding unexpected behaviors and assistance when filling out forms.

Below is each criterion, a brief explanation of it, how to test for it and how to score it in your survey spreadsheet.

Success Criterion 3.1.1 – Language of Page

The default language of the page is properly noted using the lang HTML attribute.

When to Test

On all pages.

WCAG Guidelines

Understanding Success Criterion 3.1.1

Testing SC 3.1.1

Use Wave and look for “Document Language missing.”

Chrome Instructions

Use Chrome inspector and look for the lang attribute in the html tag.

Scoring for SC 3.1.1

  • Score 1 = Document language is set properly. And when the page changes language, the lang attribute updates properly.
  • Score .5 = The document language is set but when the language is changed to a different language, the lang attribute is not updated accordingly.
  • Score 0 = Neither the document language or other languages use the correct lang attribute.

Success Criterion 3.1.2 – Language of Parts

The lang HTML attribute is used to specify languages other than the default language on the page.

When to Test

On pages with other languages listed. For example, a page that has the same document available in multiple languages.

WCAG Guidelines

Understanding Success Criterion 3.1.2

Example

Testing SC 3.1.2

If there are other languages on the page, use one of the following methods.

Screen Reader

Use a screen reader to read the content in other languages. The screen reader should change the voice to a voice that matches that language. It might also announce the language when it starts reading the content. If it does not, then the language is not tagged correctly.

Chrome Instructions

Inspect the element and look for the lang attribute. It should be using the correct code for each language.

Scoring for SC 3.1.2

  • Score 1 = All languages are using the proper lang attribute.
  • Score 0 = At least one language is missing the lang attribute.
  • N/A: Put N/A in the score field if there are no other languages on the page.

Success Criterion 3.2.1 – On Focus

When any component receives focus, it does not initiate a change of context. This means when keyboard focus is on any interactive element in a form, the focus will not be redirected to anywhere else, the form will not be submitted or a new window will not open up. All substantial changes need to be initiated by the user.

When to Test

On all pages.

WCAG Guidelines

Understanding Success Criterion 3.2.1

Testing SC 3.2.1

Tab through the items on the page. When each item receives focus, the following should happen:

  • It should not open a new window
  • It should not go to a new page
  • It should not move focus to a different component
  • It should not significantly rearrange the content of the page

Note

Skip to links are exempt from this criterion.

Scoring for SC 3.2.1

  • Score 1 = As keyboard focus moves from item to item on the page, it does not cause any unexpected changes.
  • Score 0 = As keyboard focus moves from item to item on the page, at least one item causes unexpected changes.

Success Criterion 3.2.2 On Input

Entering data or changing settings will not cause any unexpected results. Any uncommon contextual changes should be notified to the user in the instructions before they interact with any of the elements that cause this change.

When to Test

On pages with input fields or elements to change settings. This includes checkboxes, combo-boxes, toggle buttons, etc.

WCAG Guidelines

Understanding Success Criterion 3.2.2

Examples

Testing SC 3.2.2

Start typing in edit fields and change settings such as checkboxes, drop-downs, and radio-buttons. No unexpected changes should occur.

For input fields or fields that allow the user to change settings, none of them should have unexpected behaviors. Unexpected behaviors include:

  • Opening a new window
  • Going to a new page
  • Moving focus to a different component
  • Significantly rearranging the content of the page

Note

Auto-fill fields are expected behaviors.

Scoring for SC 3.2.2

  • Score 1 = If the page has input fields or settings to change, none of them have unexpected behaviors.
  • Score 0 = If the page has input fields or settings to change, at least one of them causes an unexpected behavior.
  • N/A: Put N/A in the score field if there are no input fields or fields that allow the user to change settings.

Success Criterion 3.2.3 Consistent Navigation

Navigational mechanisms such as links that repeat on multiple pages always appear in the same order throughout the same website.

When to Test

On websites with multiple pages and that have a navigation section. This includes single page websites that dynamically load new content.

Note

If the website has only one page and that page does not dynamically load new content, do not test for this criterion.

WCAG Guidelines

Understanding Success Criterion 3.2.3

Testing SC 3.2.3

If there are navigation links, look at them on all the pages. Do they appear in the same order every time? If yes , this passes. If no, this criterion fails.

Scoring for SC 3.2.3

  • Score 1 = All navigational links appear in the same order on all pages.
  • Score 0 = Navigational links are out of order on at least one page.
  • N/A: Put N/A in the score field if the website has only one page and that page does not dynamically load new content.

Success Criterion 3.2.4 – Consistent Identification

Components such as links that appear on multiple pages across the same website are always identified the same way. For example, a link has the same link text every time it appears on a page in the same website.

When to Test

On websites with multiple pages and that have links that appear on more than one page. This includes single page websites that dynamically load new content.

Note

If a website only has one page that does not dynamically load new content or does not have links that repeat on multiple pages, do not test. Put N/A in the score field.

WCAG Guidelines

Understanding Success Criterion 3.2.4

Testing SC 3.2.4

Use a screen reader or inspect the accessibility labels of links that reappear on different pages. Their accessibility label should be the same.

Screen Reader Instructions

Use the links list feature to inspect all the labels for links. They should be unique and descriptive.

  • JAWS
    • List of links: press the JAWS key and f7
    • Note: The JAWS key is insert on desktop keyboards and caps lock on laptop keyboards.
  • NVDA
    • List of links: press the NVDA key and f7. Then choose links.
    • Note: the NVDA key is insert on desktops and caps lock on laptop keyboards.
  • Voiceover
    • List of headings: press Control, option and the U key. Then press right or left to navigate to links.
Chrome Instructions

Hover the mouse over all interactable controls. A tooltip pops up with accessibility information including Accessibility name.

Scoring for SC 3.2.4

  • Score 1 = All links that appear on multiple pages have the same label.
  • Score 0 = At least one link on this page does not have the same label as other pages.
  • N/A: Put N/A in the score field if the website only has one page or if the website does not have any links that repeat on multiple pages.

Success Criterion 3.3.1 – Error Identification

If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text.

When to Test

On pages where there are required fields.

WCAG Guidelines

Understanding Success Criterion 3.3.1

Example

Testing SC 3.1.1

If there are required fields on the page, make sure that they have text error alerts. The following two scenarios are considered passing for this criterion.

Option 1

Press ‘Submit’ without filling out all of the required fields. The error alerts should include text to go along with any visual alerts. For example, when the user presses the submit button in a contact form, error identification that appears near the field has text and an icon of an exclamation point.

Option 2

Tab through the required fields without filling them out. As soon as focus leaves a required field, there is a visual and text alert that appears near that field.

Scoring for 3.1.1

  • Score 1 = All required fields have text alerts.
  • Score .5 = Some fields do not have text alerts.
  • Score 0 = A significant number of fields do not have text alerts.
  • N/A: Put N/A in the score field if there are no required fields.

Success Criterion 3.3.2 – Labels or Instructions

Labels or instructions are provided when content requires user input.

When to test

On pages that have input fields, including edit fields, checkboxes, radio-buttons, toggle buttons, list boxes, and combo boxes.

WCAG Guidelines

Understanding Success Criterion 3.3.2

Example

Testing 3.3.2

Step 1 - For all fields where the user can provide input, make sure they have labels. The labels should be available to everyone. This means the labels should be appearing visually but also available to assistive technology users.

Step 2 - If any fields require specific input, there should be appropriate instructions. Examples include:

  • Use specific labels such as “First name” and “Last name.”
  • For fields that require a specific format, there should be instructions. For example, a date field instructs users to use the format MM/DD/YYYY.
  • A state field that requires a code for each state has a link next to it that takes the user to a page or modal dialogue that displays all of the codes available.
  • In a form which contains both required and optional fields, the required fields and/or the optional fields are clearly labeled as such.

Step 3 - Make sure you can read all labels and instructions using a screen reader.

  • JAWS and NVDA
    • Use tab to navigate from field to field and listen for their labels. The labels might include the instructions.
    • If the labels do not include instructions, use the up or down arrow keys to try to read the instructions manually.
  • Voiceover
    • Use Control, Option and left or right arrows to navigate the fields as well as text between fields. You should be able to hear labels for all fields and instructions when it is relevant.

Scoring for 3.3.2

  • Score 1 = All fields have labels and fields that require specific input have instructions.
  • Score 0 = There is at least one field that is missing a label or is missing instructions when it requires a specific format for its input.
  • N/A: Put N/A in the score field if there are no required fields or no fields that need a specific format.

Success Criterion 3.3.3 – Error Suggestions

If a user makes mistakes while filling out required fields, then examples or suggestions are given to assist in correcting mistakes.

When to Test

On pages with required fields or specific inputs.

WCAG Guidelines

Understanding Success Criterion 3.3.3

Example

Testing SC 3.3.2

Test error messaging on the page. The scenarios below both pass for this criterion.

Option 1

Press submit without filling out all of the required fields. The error alerts that appear should include:

  • Which field has an error.
  • How to fix it.
    • Example: “Alert! Name field is required. Please fill in your name.”
Option 2

Press tab to go through the required fields without filling them out. As soon as focus leaves a required field, there is a visual and text alert that appears near that field. If so, it should include:

  • Which field has an error.
  • How to fix it.
    • Example: Alert! Name field is required. Please fill in your name.

Scoring for SC 3.3.3

  • Score 1 = All fields have proper error suggestions.
  • Score .5 = More than half of the Fields have proper error suggestions.
  • Score 0 = More than half of the fields are missing error suggestions.
  • N/A: Put N/A in the score field if there are no required fields.

Success Criterion 3.3.4 – Error Prevention Legal, Financial Data

For webpages that cause legal commitments or financial transactions one of the following must be true. Submissions are reversable, data is checked and the user is given an opportunity to correct them, or a mechanism is provided for reviewing, correcting or confirming data entered.

Examples of legal or financial commitments include the following. A marriage license, a stock trade (financial and legal), a will, a loan, adoption, signing up for the army, a contract of any type, etc.

When to Test

On pages that cause a legal or financial commitment. This generally doesn’t happen on nyc.gov. In most cases we will not test for this.

WCAG Guidelines

Understanding Success Criterion 3.3.4

Testing SC 3.3.4

Check to find out if the webpage causes a financial or legal commitment. If so, it needs to have one of the following:

  • Reversable: After pressing submit, the user has a chance to cancel.
  • Checked: Data entered by the user is checked for input errors and the user is provided an opportunity to correct them.
  • Confirmed: A mechanism is available for reviewing, confirming and correcting information before finalizing the submission.

Scoring for SC 3.3.4

  • Score 1 = If there are financial or legal commitments, the user has an opportunity to reverse, check or confirm before submitting.
  • Score 0 = If there are financial or legal commitments, the user has no opportunity to reverse, check or confirm before submitting.
  • N/A: Put N/A in the score field if the page does not cause a legal or financial commitment.

Homework

Continue testing WCAG 1.1.1 through 3.3.4 by the next session. For assistance, email Walei at wsabry@doitt.nyc.gov.