• What are Siteimprove accessibility checks?
• Do Siteimprove accessibility checks based on the ACT Rules provide coverage of WCAG for testing?
• What are Accessibility Best Practice Checks?
• Accessibility Best Practices
• What are “WAI-ARIA Best Practices” Checks?
• WAI-ARIA Best Practices
• WCAG Conformance Checks
• More information

What are Siteimprove accessibility checks?

The Siteimprove Accessibility product has been implemented with a set of web accessibility checks, based on Accessibility Conformance Testing (ACT) rules.
The rules have been developed by ACT Task Force, through participation in the WAI-Tools Project which is a collaborative, ongoing project to innovate accessibility testing. The Task Force is compiled of a consortium of key players in the accessibility industry, national authorities, and the World Wide Web Consortium (W3C).

The mission of ACT Task Force is to:

• Improve consistency and accuracy of automated, semi-automated, and manual accessibility testing.
• Demonstrate large-scale web accessibility monitoring built on open standards.
• Pursue leading technologies for website testing, including dynamic content and mobile web applications.

For us at Siteimprove, our participation in the development and harmonization of an internationally recognized testing standard is to deliver:

• Reliability: Users will experience one single point of truth.
• Accuracy: Users will be able to test their websites against standardized accessibility conformance testing rules.
• Transparency: Users will have full insight into how our accessibility checks work.

Do Siteimprove accessibility checks based on the ACT Rules provide coverage of WCAG for testing?

Yes. The Siteimprove checks are based on the ACT Rules Format 1.0, which is an industry-standard for testing WCAG coverage. You can read more about ACT Rules on the W3C website.
In addition, we have several best practice checks.

What are Accessibility Best Practice Checks?

 Best practice checks relate to requirements that are not covered by existing W3C specifications – meaning WCAG, WAI-ARIA, HTML5, and CSS– and are not normative. Normative means a rule or standard that you can conform to (for instance, conformance to the WCAG success criteria at Levels A, AA, and AAA).

An example of non-normative content from the W3C is the information under the Understanding WCAG document that is published as informative guidance on how to meet the normative success criterion of WCAG. 

The understanding-document contains examples of best practices to implement an accessibility fix in your code or content and testing procedures to guide you when reviewing your work. We have used this content as the basis for some of our best practice checks.

Other best practice checks have also been written from research, good user experience, and coding practices.  An example is a check for using all uppercase or italicized text, two practices that we know impact people from a cognitive perspective or those with low vision.

Accessibility Best Practices

What are “WAI-ARIA Best Practices” Checks?

These checks have been created to detect when WAI-ARIA authoring practices have been used incorrectly – for example, misspelled or a missing role or attributes, or when the value of the state or property is invalid or incorrect.
An example where the role is invalid: if an author chooses to add the ARIA role of "img", but misspelled it as “image”, this would be invalid and ineffective, but is not always a WCAG conformance issue. We flag this to ensure that code is implemented correctly. This also ensures that our tool, which relies on correct ARIA usage, can perform its checks as intended.

WAI-ARIA Best Practices

WCAG Conformance Checks

Principle 1 – Perceivable

1.1 Text Alternatives

1.1.1   Non-Text Content (A)

All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for Controls and Input, Time-based Media, Tests, Sensory content, CAPTCHA, Decoration, Formatting or Invisible content.

1.2.1 Audio-only and Video-only (Prerecorded)(A)

For prerecorded audio-only and prerecorded video-only media, the following are true, except when the audio or video is a media alternative for text and is clearly labeled as pre-recorded audio-only, or pre-recorded video-only.

1.2.2 Captions (Prerecorded) (A)

Captions are provided for all prerecorded audio content in synchronized media, except when the media is a media alternative for text and is clearly labeled as such.

1.2.3 Audio Description or Media Alternative (Prerecorded) (A)

An alternative for time-based media or audio description of the prerecorded video content is provided for synchronized media, except when the media is a media alternative for text and is clearly labeled as such.

1.2.5 Audio Description (Prerecorded)(AA)

Audio description is provided for all prerecorded video content in synchronized media.

1.3 - Adaptable

1.3.1 Info and Relationships (A)

Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.

1.3.4 Orientation (AA)

Content does not restrict its view and operation to a single display orientation, such as portrait or landscape, unless a specific display orientation is essential.

1.3.5 Identify Input Purpose (AA)

The purpose of each input field collecting information about the user can be programmatically determined when:

• The input field serves a purpose identified in the Input Purposes for User Interface Components section; and
• The content is implemented using technologies with support for identifying the expected meaning for form input data.

1.4 – Distinguishable

Make it easier for users to see and hear content including separating foreground from background.

1.4.1 Use of Color (A)

Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.

1.4.2 Audio Control (A)

If any audio on a Web page plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume independently from the overall system volume level.

1.4.3 Contrast (Minimum) (A)

The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following:

• Large Text: Large-scale text and images of large-scale text have a contrast ratio of at least 3:1;
• Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.
• Logotypes: Text that is part of a logo or brand name has no contrast requirement. 

1.4.4 Resize Text (A)

Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality.

1.4.6 Contrast (Enhanced) (AAA)

The visual presentation of text and images of text have a contrast ratio of at least 7:1, except for the following:

• Large Text: Large-scale text and images of large-scale text have a contrast ratio of at least 4.5:1;
• Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.
• Logotypes: Text that is part of a logo or brand name has no contrast requirement.

1.4.8 Visual Presentation (AAA)

For the visual presentation of blocks of text, a mechanism is available to achieve the following:

• Foreground and background colors can be selected by the user.
• Width is no more than 80 characters or glyphs (40 if CJK).
• Text is not justified (aligned to both the left and the right margins).
• Line spacing (leading) is at least space-and-a-half within paragraphs, and paragraph spacing is at least 1.5 times larger than the line spacing.
• Text can be resized without assistive technology up to 200 percent in a way that does not require the user to scroll horizontally to read a line of text on a full-screen window. 

1.4.10 Reflow (AA)

Content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions for:

• Vertical scrolling content at a width equivalent to 320 CSS pixels;
• Horizontal scrolling content at a height equivalent to 256 CSS pixels;
• Except for parts of the content which require two-dimensional layout for usage or meaning. 

1.4.12 Text Spacing (AA)

In content implemented using markup languages that support the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property:

• Line height (line spacing) to at least 1.5 times the font size
• Spacing following paragraphs to at least 2 times the font size
• Letter spacing (tracking) to at least 0.12 times the font size
• Word spacing to at least 0.16 times the font size

Exception: Human languages and scripts that do not make use of one or more of these text style properties in written text can conform using only the properties that exist for that combination of language and script.

Principle 2 – Operable

2.1 – Keyboard Accessible

Make all functionality available from a keyboard.

2.1.1 Keyboard (A)

All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.

Note 1: This exception relates to the underlying function, not the input technique. For example, if using handwriting to enter text, the input technique (handwriting) requires path-dependent input but the underlying function (text input) does not.

Note 2: This does not forbid and should not discourage providing mouse input or other input methods in addition to keyboard operation. 

2.2 – Enough Time

Provide users enough time to read and use the content.

2.2.1 Timing Adjustable (A)

For each time limit that is set by the content, at least one of the following is true:

• Turn off: The user is allowed to turn off the time limit before encountering it; or
• Adjust: The user is allowed to adjust the time limit before encountering it over a wide range that is at least ten times the length of the default setting; or
• Extend: The user is warned before time expires and given at least 20 seconds to extend the time limit with a simple action (for example, "press the space bar"), and the user is allowed to extend the time limit at least ten times; or
• Real-time Exception: The time limit is a required part of a real-time event (for example, an auction), and no alternative to the time limit is possible; or
• Essential Exception: The time limit is essential and extending it would invalidate the activity; or
• 20 Hour Exception: The time limit is longer than 20 hours. 

2.2.4 Interruptions (AAA)

Interruptions can be postponed or suppressed by the user, except interruptions involving an emergency.

2.4 – Navigable

Provide ways to help users navigate, find content, and determine where they are.

2.4.2 Page Titled (A)

Web pages have titles that describe topic or purpose.

2.4.4 Link Purpose (In Context) (A)

The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general.

2.4.7 Focus Visible (AA)

Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.

2.4.9 Link Purpose (Link Only) (AAA)

A mechanism is available to allow the purpose of each link to be identified from link text alone, except where the purpose of the link would be ambiguous to users in general.

2.5 – Input Modalities

Make it easier for users to operate functionality through various inputs beyond keyboard. 

2.5.3 Label in Name (A)
For user interface components with labels that include text or images of text, the name contains the text that is presented visually.

Principle 3 – Understandable

3.1 – Readable

Make text content readable and understandable.

3.1.1 Language of Page (A)

The default human language of each Web page can be programmatically determined.

3.1.2 Language of Parts (AA)

The human language of each passage or phrase in the content can be programmatically determined except for proper names, technical terms, words of indeterminate language, and words or phrases that have become part of the vernacular of the immediately surrounding text.

3.2 Predictable

Make Web pages appear and operate in predictable ways.

3.2.5 Change on Request (AAA)

Changes of context are initiated only by user request or a mechanism is available to turn off such changes.

3.3 Input Assistance

Help users avoid and correct mistakes.

3.3.1 Error Identification (A)

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.

Principle 4 – Robust

4.1 – Compatible

Maximize compatibility with current and future user agents, including assistive technologies.

4.1.1 Parsing (A)

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.

Note 1: Start and end tags that are missing a critical character in their formation, such as a closing angle bracket or a mismatched attribute value quotation mark are not complete. 

4.1.2 Name, Role, Value (A)

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 1: 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. 

4.1.3 Status Messages (AA)

In content implemented using markup languages, status messages can be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without receiving focus.

More information

Visit this page for a full overview of the key features in Accessibility.