Accessibility Self-Audit Training Sessions

Print icon Print

Session 7 WCAG 4.1.1 through 4.1.3

Date: May 6, 2021

Overview

Training topic and Success Criteria

The WCAG criterion that will be demonstrated include:

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

  • Proper mark up in your websites code
  • Use of name, role and value for custom elements
  • Status messages and screen reader accessibility

Housekeeping:

  • We have created a new spreadsheet format that is vertically oriented
    • Download the latest version of the spreadsheet here
  • Walei and Arthur will support folks who have been auditing to transfer their data to the new format
    • We have completed converting spreadsheets and will be sharing them soon.
  • Our first review session will be on either on May 19th or 21st. Please email wsabry@doitt.nyc.gov and share your preference.
    • This will be the first of a few review sessions. In the review sessions, we will audit one page from beginning to end.
  • Our next Open Office Hours will be held on May 13th at 2:30 PM
  • You can also email Walei at wsabry@doitt.nyc.gov if you'd like to setup one-on-one time to conduct audits together.
  • If you are new to this training, email wsabry@doitt.nyc.gov to be added to the contact list and find out about future training sessions.

Prep work and Session Recording

Recording

What you need for this session

For this part of the audit you will need:

Session 7 Audit: WCAG 4.1.1 through 4.1.3

WCAG 4.1.1 through 4.1.3 cover the robustness of the code that makes up your website. It also covers custom elements and scripts to ensure that they are accessible. Finally, it covers status messages and screen reader accessibility.

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 4.1.1 Parsing

In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features.

When to Test

On all pages.

WCAG Guidelines

Understanding Success Criterion 4.1.1

Testing SC 4.1.1

Step 1
Count the total number of lines of code. When using Google Chrome, right click and choose view page source. Each line of code has a number next to it. Scroll until the last line and take the number next to it.

Step 2
Use the W3C Mark-up Validation Service to test the html of the page. Take the number of errors and add it to the number of alerts.

Scoring for SC 4.1.1

Scoring is calculated using the following:

  • Count the total number of lines of code.
  • Count the number of errors and alerts.
  • Divide the number of errors and alerts by the total number of lines of code for a number between 0 and 1.

Success Criterion 4.1.2 Name, Role Value

For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.

Note

This success criterion is primarily for Web authors who develop or script their own user interface components. For example, standard HTML controls already meet this success criterion when used according to specification.

When to Test

On all pages.

WCAG Guidelines

Understanding Success Criterion 4.1.2

Testing SC 4.1.2

Find out if the page has custom elements and scripts. For things like acordions, tab panels, toggle buttons etc. Do they have proper names, roles states and values?

Scoring for SC 4.1.2

  • Score 1 = Page uses standard HTML5 elements or if there are custom scripts, they have proper names roles and values.
  • Score .5 = there are custom elements but only a small number of them do not use name, role and value.
  • Score 0 = at least half or more of custom elements do not use name, role or value.

Success Criterion 4.1.3 Status Messages

When there are status messages that appear on the page without loading are automatically read out loud by screen readers without moving focus.

Note

Modal dialogues do not count for this criterion. A modal dialogue moves screen reader focus when it appears. It traps keyboard focus inside until the user dismisses it. The message for leaving nyc.gov when going to an external website does not count for this criterion.

When to test

On pages that have status messages that appear without loading a new page.

WCAG Guidelines

Understanding Success criterion 4.1.3

Examples

Testing SC 4.1.3

If there are status messages that appear visually, they should be read a loud by screen readers.

Steps:

  • Turn on a screen reader
  • Use tab to navigate to a button that will cause a status message and press enter on it
  • You should hear a status message read a loud by the screen reader

Scoring for SC 4.1.3

  • Score 1 = if there are status messages that appear visually, all of them are read by screen readers.
  • Score .5 = a few status messages are not read by screen readers.
  • Score 0 = at least half of the status messages are not read by screen readers.
  • N/A: leave the score blank if there are no status messages on the page.

Due May 21st

Please send me your spreadsheets with WCAG 1.1.1 through 4.1.3 filled in by our first review session on May 21st. For assistance, email Walei at wsabry@doitt.nyc.gov.