Web Content Accessibility Guidelines (WCAG)

Siteimprove’s automated tests use the latest accessibility standard, which encompasses both the Web Content Accessibility Guidelines (WCAG) 2.0 and 2.1 criteria. While Stanford’s digital accessibility policy sets the minimum standard at meeting WCAG 2.0 criteria, that is the bare minimum and not the goal.

Siteimprove’s adoption of four criteria specific to WCAG 2.1 addresses shortcomings and gaps in the previous standard that can help us identify potential issues people with disabilities may experience when attempting to use the website. Regardless of whether Siteimprove’s automated accessibility tests are using the WCAG 2.0 or 2.1 criteria, it does indicate the presence of a potential accessibility barrier and should be investigated.

Siteimprove tests for WCAG 2.1

While it is not possible to filter between WCAG 2.0 and 2.1 issues globally in Siteimprove, it is possible to create a report that shows only the four tests that map to WCAG 2.1 standards. You can see this if you go to the Dashboards page and select the "WCAG 2.1 Only" option.

For those who would like to know the four WCAG 2.1 automated tests Siteimprove has adopted, they are: 

1. SIA-R44 - Orientation of the page is not restricted using CSS transform property (WCAG 1.3.4)
2. SIA-R10 - autocomplete attributes have a valid value Accessibility requirements (WCAG 1.3.5)
3. SIA-R47 - <meta name="viewport"> elements do not prevent zoom Accessibility requirements (WCAG 1.4.10).
4. SIA-R14 - Visible labels are included in accessible names Accessibility requirements (WCAG 2.5.3)

Tests #1 and #3 are typically global template issues and probably are not an issue on your site if you haven't specifically modified the template to restrict users from using mobile devices. Note though that test #3 is combined with a test for WCAG 2.0 1.4.4 which deals with another aspect of META resizing. When looking at the WCAG dashboard you might see 1.4.4 results mixed in. 

Test #2 checks if you are using the autocomplete attribute on form elements and that the values you include are valid. It doesn't make a judgment about if your form should or should not be using autocomplete, but just that if you have implemented it, you did so correctly. 

Test #4 is the only one that might require some additional review and it's easy to fix in most cases. In short, any time you have a visible label and a different accessible label (such as something added with ARIA), it is necessary that the visible label is part of the accessible label.

This example passes because "Next Page" is the visible label and the accessible label contains "Next Page" as part of the text (you can have more content in the accessible label, but not less).

Next Page

But this does not because the visible label is not entirely contained within the aria-label.

Next Page in the list

The above situation while not complaint, is probably still accessible though as the differences are minimal at best. More likely though you have something like the following example which does not pass because the terminology for the accessible label and the visible label do not match: