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:
For this part of the audit you will need:
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.
The default language of the page is properly noted using the lang HTML attribute.
On all pages.
Understanding Success Criterion 3.1.1
Use Wave and look for “Document Language missing.”
Use Chrome inspector and look for the lang attribute in the html tag.
The lang HTML attribute is used to specify languages other than the default language on the page.
On pages with other languages listed. For example, a page that has the same document available in multiple languages.
Understanding Success Criterion 3.1.2
If there are other languages on the page, use one of the following methods.
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.
Inspect the element and look for the lang attribute. It should be using the correct code for each language.
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.
On all pages.
Understanding Success Criterion 3.2.1
Tab through the items on the page. When each item receives focus, the following should happen:
Skip to links are exempt from this criterion.
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.
On pages with input fields or elements to change settings. This includes checkboxes, combo-boxes, toggle buttons, etc.
Understanding Success Criterion 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:
Auto-fill fields are expected behaviors.
Navigational mechanisms such as links that repeat on multiple pages always appear in the same order throughout the same website.
On websites with multiple pages and that have a navigation section. This includes single page websites that dynamically load new content.
If the website has only one page and that page does not dynamically load new content, do not test for this criterion.
Understanding Success Criterion 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.
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.
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.
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.
Understanding Success Criterion 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.
Use the links list feature to inspect all the labels for links. They should be unique and descriptive.
Hover the mouse over all interactable controls. A tooltip pops up with accessibility information including Accessibility name.
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.
On pages where there are required fields.
Understanding Success Criterion 3.3.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.
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.
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.
Labels or instructions are provided when content requires user input.
On pages that have input fields, including edit fields, checkboxes, radio-buttons, toggle buttons, list boxes, and combo boxes.
Understanding Success Criterion 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:
Step 3 - Make sure you can read all labels and instructions using a screen reader.
If a user makes mistakes while filling out required fields, then examples or suggestions are given to assist in correcting mistakes.
On pages with required fields or specific inputs.
Understanding Success Criterion 3.3.3
Test error messaging on the page. The scenarios below both pass for this criterion.
Press submit without filling out all of the required fields. The error alerts that appear should include:
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:
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.
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.
Understanding Success Criterion 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:
Continue testing WCAG 1.1.1 through 3.3.4 by the next session. For assistance, email Walei at wsabry@doitt.nyc.gov.