Automated testing exercise

Images must have alternate text (WCAG SC 1.1.1)

This accessibility violation is covered by WCAG Success Criteria (SC) 1.1.1. This image is missing an ALT attribute, which is one of the most common and easiest accessibility issues to address. All that is required is some descriptive text in an ALT attribute.

A sentence or two will usually suffice. If you're not sure what to enter as the ALT's value, try describing what's in the image as though you're describing it to someone over the phone or to someone who can't see it.

Links must have discernible text (WCAG SC 2.4.4)

Hyperlinks must contain text that describe the destination: this can be done by entering text directly between the anchor tags or via some other labeling method like the aria-label attribute. Links cannot be empty. This is a requirement of WCAG SC 2.4.4.

Elements must meet minimum color contrast ratio thresholds (WCAG SC 1.4.3)

The red text in the paragraph below does not meet the minimum WCAG AA color contrast requirements. As WCAG SC 1.4.3 explains: if the contrast between text and background is too low, some site visitors will have difficulty reading your low-contrast content. Worse, some users may not be able to read it at all, and an unlucky few won't even be able to see the content because it fades into the background to them. Tools like WebAIM's Color Contrast Checker can help you determine the appropriate hex code to use for foreground text and background colors.

Form elements must have labels (WCAG SC 3.3.2)

Form elements must be implemented properly (WCAG SC 4.1.2)

There actually is a label intended for use with the input in this form; however, the two are not associated with each other in any way, so this combination is technically inaccessible in spite of their physical proximity. It can be especially problematic for users if a form has multiple inputs. This is a fairly basic accessibility issue, and fortunately there are multiple ways to resolve it.

Think of form labels as ALT text, but for inputs instead of images. Every input must have a label. Note that there is some redundancy involved when Apple Voiceover announces label elements <label>, which results in the label being announced twice.

Below are different ways to make this input element accessible, in order of Best Practices preference:

1. Add a "for" attribute to the label element. The "for" attribute's value must match the id of the input you're targeting. In this case, the id is "username".

2. Wrap the label element around the input. Simple enough. The input just has to be nested in the label.

3. Add an "aria-label" attribute to the input. NOTE: ARIA attributes are most appropriate when a visual label is not desired or if you need to supplement the label element with additional context. Generally speaking, native HTML accessibility (e.g. using a label element) must be prioritized over ARIA usage. ARIA may be used to modify an existing codebase if refactoring the problem area with native HTML would be time intensive, but it's strongly recommended that you avoid ARIA unless you have to use it.

4. Add an "aria-label" attribute to the input. NOTE: ARIA attributes are most appropriate when a visual label is not desired or if you need to supplement the label element with additional context. Generally speaking, native HTML accessibility (e.g. using a label element) must be prioritized over ARIA usage. ARIA may be used to modify an existing codebase if refactoring the problem area with native HTML would be time intensive, but it's strongly recommended that you avoid ARIA unless you have to use it.

5. Don't use placeholders or titles. Placeholder and title attributes for labeling are not sufficient replacement options for accessible and usable forms.

Heading levels should only increase by one (Best Practices issue)

This is a Best Practice issue that isn't covered by WCAG. Though there's no WCAG guideline that specifically addresses heading level jumping, be mindful of your heading hierarchy and make sure it follows a logical reading order. For example, you may run into a situation where an <h2> has to be the first heading on the page, but try to avoid implementation like that whenever possible.

In the example below, the <h4> tags wrapping around "This is a heading" are improperly used. The heading prior to this, "Logic in heading usage," is an <h2>, so the next that appears on the page should be an <h2> or <h3>...not an <h4>.

ARIA role should be appropriate for the element (Best Practices issue)

This one may look similar, but it's not the same as the previous ARIA misuse violation. Unlike the previous example, the "navigation" value demonstrated below does exist but is used improperly. The element it's placed in, <button>, cannot function as a navigation listing.

Though improper role usage is a best practice issue, it should be treated as a WCAG violation because incorrect role values can cause confusion or cause screen reader software to malfuction. In the example below, the navigation role can be safely removed without specifying a replacement because it doesn't belong in a button anyway. Accessibility scanners can't catch all instances of ARIA misuse, so this is one of the few exceptions.

Buttons must have discernible text (WCAG SC 4.1.2)

The seventh "bonus issue" on this page is "Buttons must have discernible text": ...which exists solely because of the violation "ARIA role should be appropriate for the element" in the green button above. At first you might think it's a false positive, because every button on this page does contain a legitimate text label; however, if you look at the element location for this issue, you'll notice it's the same element flagged in the previous exercise's green button "ARIA role" issue:

What's happening here is a great example of what can happen with semantic HTML misuse, which you might remember learning about in the "Topics" section. To understand the "misuse" aspect of this concept, it may be helpful to know the BUTTON element's built-in semantic meaning and behavior includes an implicit internal role of "button", meaning the BUTTON element will always be a button by default. When we (the dev staff who created this online resource) added role="navigation" to the "Fire torpodoes" button, this created a semantic conflict that prevents axe Devtools from properly parsing and interpreting certain properties like the label. Even though a text descriptor is present between the opening and closing tags that we can clearly see, the misuse of the ARIA role disrupts assistive technology's ability to determine the element's intended purpose. Since the axe scanning engine can't detect the presence of a label, it gives up and cites a failure to meet WCAG Success Criteria 4.1.2.

So is this a false positive or is it a real issue?

It's a real issue. Either way you look at it, the button on this page is comprised of 100% truly inaccessible HTML. Assigning an inappropriate or incompatible role to a semantic element distorts how the element is interpreted, which effectively forms a barrier to those who wish to interact with it. Proper functional accessibility implementation hinges on observed expected behavior, and that can only be achieved by using semantic HTML for its intended purpose.