Giter VIP home page Giter VIP logo

act-rules.github.io's Introduction

ACT-Rules Community repository

The ACT-Rules Community repository is where the ACT-Rules community group maintains the rules they designed for (semi-)automated accessibility testing. Within the rules directory you will find all the rules recommended by the ACT-Rules community group for implementation in automated test tools.

Visit the ACT-Rules Rules community website for the latest rules and drafts.

Related W3C Activities

The ACT-Rules Community Group is the primary contributor of rules to the Accessibility Conformance Testing (ACT) Taskforce for the W3C. The ACT Taskforce is currently developing the standard around which rules can be created, and is planning to put together a suite of rules on how WCAG 2 (and beyond) should be tested.

For more information, see ACT Overview - What is ACT.

Write rules, not tools

An ACT rule is a unambiguous description of what the results of accessibility test tools and methodologies be when running a conformance test for the Web Content Accessibility Guidelines. The rules are written without a specific implementation in mind. The goal is not to create an accessibility test tool. Instead we aim to harmonize between existing tools, and improve their transparency and the overall quality of their results.

If you want to know more about us, visit our website at: www.w3.org/community/act-r.

Implementing ACT Rules

Anyone developing their own accessibility testing tool or methodology is free to based this on the ACT-R Community rules. We encourage you to document any deviations from those rules if you do so, and make these changes known to your users.

Contribute

Contributing is open to anyone. We welcome any pull requests for changes. We ask that you make changes to pull requests only for drafts. Before contributing new rules, we recommend you checked their validity with several experienced accessibility auditors first. This helps you identify potential stumbling blocks early in their design.

ACT-R has conference calls every 4 weeks. If you are interested in becoming an active contributor or reviewer, we ask that you join the ACT-R community group through the W3C Website. This requires setting up a W3C account, may require approval by the organization you work for if they are a W3C member.

Join the ACT-Rules community group now! or visit w3.org/community/act-r/ for more information.

For info on how to use this GitHub repository, see the ACT-Rules GitHub Guidelines.

GitHub Automation

This repository automatically pushes changes to rules to the w3c/wcag-act-rules repository. There is an "Approve rule" action available which can be triggered manually by an ACT Task Force facilitator, which will set a proposed rule to "approved".

act-rules.github.io's People

Contributors

ajanec01 avatar audreymaniez avatar brynanders avatar carlosapaduarte avatar chrisloiselle avatar dagfinnromen avatar dan-tripp-siteimprove avatar daniel-montalvo avatar dependabot-preview[bot] avatar dependabot[bot] avatar emmajp avatar giacomo-petri avatar helenburge avatar jeeyyy avatar joao-vicente avatar jym77 avatar kasperisager avatar kengdoj avatar kensgists avatar kherr-a11y avatar robfentress avatar sboptum avatar shadowbb avatar susanatx avatar tbostic32 avatar tombrunet avatar vemolista avatar wcreedle avatar wilcofiers avatar zalmeraj avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

act-rules.github.io's Issues

Continue development of link-name


rule_id: SC2-4-4+SC4-1-2-link-names
name: Links have an accessible name
test_mode: automatic

criteria:

  • 2.4.4 # Link Purpose (In Context) (Level A)
  • 4.1.2 # Name, Role, Value (Level A)

authors:

  • Wilco Fiers

Description

This rule checks that all links have an accessible name.

Background

Assumptions

No known assumptions.

Test properties

Property Value
Test name Links have an accessible name
Success Criterion 2.4.4 Link Purpose (In Context), 4.1.2 Name, Role, Value
Test mode automatic
Test environment Rendered page
Test subject Single web page

Test procedure

Selector

Test mode: automatic

Select elements matching the following CSS selector:

a[href]:not([role]), *[role=link]

Step 1

Test mode: automatic

Check if the selected element has an aria-label or aria-labelledby attribute.

If yes, continue with Step 5

Else, continue with step Step 2

Step 2: no ARIA

Test mode: automatic

Concatenate the selected element's rendered text and the text of the title attribute, in variable T1.

If T1 is non-empty, return:

Outcome Passed
Testcase SC2-4-4+SC4-1-2-link-names
ID SC2-4-4+SC4-1-2-link-names-passed1
Info Link contains text

Else, continue with Step 3

Step 3

Check if the selected element contains an img element or an input element of type=image,

If yes, continue with Step 4

Else, return:

Outcome Failed
Testcase {{ page.rule_id }}
ID {{ page.rule_id }}-failed1
Error The links must have a name, either though the link text or by the title attribute.

Step 4: Linked images

Test mode: automatic

Take all images from step 3, that do not have [role=presentation] and are not hidden through display:none or visibility:hidden.

If there are no such images, return:

Outcome Failed
Testcase {{ page.rule_id }}
ID {{ page.rule_id }}-failed2
Error Ensure that images within the link are not ignored by assistive technologies.

Get the text alternatives of the images using the Text Alternative Computation Algorithm. Concatenate the resulting texts into variable T2.

If T2 contains non-empty text, return:

Outcome Passed
Testcase {{ page.rule_id }}
ID {{ page.rule_id }}-passed2
Info The link contains images with a text alternative

Else return:

Outcome Failed
Testcase {{ page.rule_id }}
ID {{ page.rule_id }}-failed3
Error An image is the only content of this anchor and so it should have a text alternative to give a name to the link.

Step 5: ARIA labels

Test mode: automatic

Concatenate the selected element's aria-label attribute, and the text content of an element referred to with the aria-labeledby attribute, in variable T3.

If T3 contains non-empty text, return:

Outcome Passed
Testcase {{ page.rule_id }}
ID {{ page.rule_id }}-passed3
Info The link has an accessible name through ARIA labels

Dlese, return:

Outcome Failed
Testcase {{ page.rule_id }}
ID {{ page.rule_id }}-failed4
Error The link's aria label does not provide an alternative

SC2-1-2-no-keyboard-trap-non-standard-navigation (Updated)


name: No keyboard trap non-standard navigation
group:

  • SC2-1-2-no-keyboard-trap-standard-navigation
  • SC2-1-2-no-keyboard-trap-non-standard-navigation (current)

description: |
This rule checks if the user is advised on a method for non-standard keyboard navigation to navigate through focusable content on a web page without becoming trapped in any element.

success_criterion:

  • 2.1.2 # No Keyboard Trap

test aspects:

  • DOM Tree

authors:

  • Dagfinn Rømen
  • Geir Sindre Fossøy
  • Malin Øvrebø
  • Shadi Abou-Zahra
  • Carlos Duarte
  • Anne Thyme Nørregaard
  • Stein Erik Skotkjerra

Test procedure

Applicability

The rule applies to any HTML or SVG element on a web page that is focusable and reachable through sequential focus navigation where focus cannot cycle to the browser UI by using standard keyboard navigation.

Expectation 1

For each target element help information is visible on the page and exposed to assistive technologies or can be navigated to from within the keyboard trap.

Note: As per Success Criterion 2.1.1 Keyboard the help information should be accessible through a keyboard interface. This however is the test subject for another ACT rule.

Expectation 2

The help information explains how to cycle to the browser UI, or on how to get to a point from where it is possible to cycle to the browser UI, using standard keyboard navigation.

Expectation 3

For each target element focus can cycle to the browser UI by using the method advised in the help information.

Note: Cycling back to the browser UI can be done both by moving forward through the tab order and by moving backwards. It is not possible to fulfil this expectation by using browser specific shortcuts to return to the browser UI.

Assumptions

  • The WCAG success criterion applies to all content where focus can be moved to through keyboard navigation.
  • It is not possible to use unmodified arrow or tab keys, or other standard exit methods to move focus away.
  • The focus order in keyboard navigation is cyclical, not linear, meaning that the focus order will cycle to the first/last element when it moves away from the last/first element.

Accessibility support

There are no major accessibility support issues known for this rule.

Background

Test Cases

Passed

<!-- Keyboard trap with help information in a paragraph before, and where the method adviced works -->

<script>
var trapOn = false ;
</script>

<p class="target">Press the Esc-key to Exit</p>
<a id="link1" href="#">Link 1</a>
<button id="btn1" class="target" onblur="(function(e){trapOn=true; document.getElementById('btn2').focus();})(event)">Button 1</button>
<button id="btn2" class="target" onkeydown="(function(e){ if (e.keyCode === 27){trapOn=false;document.getElementById('link2').focus();}})(event)" onblur="(function(e){ if(trapOn){document.getElementById('btn1').focus();}})(event)">Button 2</button>
<a id="link2" href="#">Link 2</a>
<!-- Keyboard trap with help information within the trap, and where the method adviced works --> 

<script>
var trapOn = false ;
</script>

<a id="link1" href="#">Link 1</a>
<button id="btn1" class="target" onblur="(function(e){trapOn=true; document.getElementById('btn2').focus();})(event)">Button 1</button>
<p class="target">Press the Esc-key to Exit</p>
<button id="btn2" class="target" onkeydown="(function(e){ if (e.keyCode === 27){trapOn=false;document.getElementById('link2').focus();}})(event)" onblur="(function(e){ if(trapOn){document.getElementById('btn1').focus();}})(event)">Button 2</button>
<a id="link2" href="#">Link 2</a>

Failed

<!-- Keyboard trap with no instructions  -->

<script>
var trapOn = false ;
</script>

<a id="link1" href="#">Link 1</a>
<button id="btn1" class="target" onblur="(function(e){trapOn=true; document.getElementById('btn2').focus();})(event)">Button 1</button>
<button id="btn2" class="target" onkeydown="(function(e){ if (e.keyCode === 27){trapOn=false;document.getElementById('link2').focus();}})(event)" onblur="(function(e){ if(trapOn){document.getElementById('btn1').focus();}})(event)">Button 2</button>
<a id="link2" href="#">Link 2</a>
<!-- Keyboard trap with instructions that doesn't give advice on the method for proceeding -->

<script>
var trapOn = false ;
</script>

<p class="target">Go to the next element</p>
<a id="link1" href="#">Link 1</a>
<button id="btn1" class="target" onblur="(function(e){trapOn=true; document.getElementById('btn2').focus();})(event)">Button 1</button>
<button id="btn2" class="target" onkeydown="(function(e){ if (e.keyCode === 27){trapOn=false;document.getElementById('link2').focus();}})(event)" onblur="(function(e){ if(trapOn){document.getElementById('btn1').focus();}})(event)">Button 2</button>
<a id="link2" href="#">Link 2</a>
<!-- Keyboard trap with help text, where the method adviced doesn't work --> 

<script>
var trapOn = false ;
</script>

<a id="link1" href="#">Link 1</a>
<button id="btn1" class="target" onblur="(function(e){trapOn=true; document.getElementById('btn2').focus();})(event)">Button 1</button>
<p class="target">Press the Esc-key to Exit</p>
<button id="btn2" class="target"  onblur="(function(e){ if(trapOn){document.getElementById('btn1').focus();}})(event)">Button 2</button>
<a id="link2" href="#">Link 2</a>

Inapplicable

<!-- Not a keyboard trap (interactive element) -->

<a id="link1" href="#">Link 1</a>
<button id="btn1">Button 1</button>
<button id="btn2">Button 2</button>
<a id="link2" href="#">Link 2</a>

SC3-1-2-lang


name: SC3-1-2-lang

description:

  • This rule checks that lang and/or xml:lang attribute on elements with in the body of a web page are correct.

success_criterion:

  • 3.1.2

test_aspects:

  • DOM Tree

authors:

  • Jey Nandakumar

Test Procedure

Applicability

  • Any DOM element, other than the root DOM node with a lang and/or xml:lang attribute.

Expectation

  • The value of the lang and/or xml:lang conforms to BCP 47.

Assumptions

There are currently no assumptions

Accessibility support

This rule is only applicable in a scenario where assistive technologies are inconsistent about how they determine the language of the page.

Background

Test Cases

Selector

Retrieve all DOM nodes with a lang and or xml:lang attribute, other than the root node

descendent-or-self::body[@lang]
descendent-or-self::body[@xml:lang]

Passes

<article lang="en">
<p xml:lang="DE">
<blockquote lang="fr-CH">

Failed

<article lang="dutch">
<p xml:lang="en-english">

Inapplicable

none

video-description


rule_id:
name:
test_mode: semi-automatic
environment: Web Browser

success_criterion:

  • 1.2.3

authors:


Description

Video elements without description track must be reviewed to ensure that audio descriptions aren’t necessary or are provided in a different way.

Background

Assumptions

  • The video isn't live
  • This video contains audio

Test procedure

Applicability

Any video element(s) that does not contain a track element with a kind attribute set to descriptions.

Expectation

  • Either the video does not contain any visual information that is not available through audio; or the information is available as text or audio on the page or through a link on the page.

Implementation Tests

There are currently no tests available for this rule.

Implementation tests are available at: rulename tests

Change log

Version 1.0

  • Set up the initial rule

SC3-1-1-xml-lang --draft


name: SC3-1-1-xml-lang
group: # (what goes here?)
description: |
This rule checks the value of the xml:lang and/or the lang attribute.

success_criterion:

  • 3.1.1

test_aspects:
To run the test cases, the below conditions are necessary.

  1. DOM Tree: The tree that HTML is parsed into.
  2. Accessibility Tree: The tree that user agents expose to the accessibility API.
  3. HTTP Messages: All messages sent through HTTP(s)

authors:


Test Procedure (1)

For html element.

  1. Examine the html element of the document.
  2. Check that the html element has a lang and or xml:lang attribute.
  3. Check that the value confirms to BCP 47.

Expectation (1)

  • The above checks are all true.

Test Procedure (2)

For object embedded element.

  1. Examine the object element of the document.
  2. Check that the object element has a lang and or xml:lang attribute.
  3. Check that the value confirms to BCP 47.

Expectation (2)

  • The above checks are all true.

Test Procedure (3)

Checking language in HTTP(S) Request Headers & Responses.

  1. Examine the request and response from a XHR.
  2. Check that a request has passed Accept-Lanauage in the header to advertise which languages that the client is able to undersand.
  3. Check that the response stream and Content-Language response header is specified.
  4. Check that the value confirms to BCP 47.

Expectation (3)

  • The above checks are all true.

Applicability

This rule applies to the html, object, xhr request & xhr response.

Assumptions

Past tests have shown that xml:lang is ignored by certain screenreaders (Both Jaws 15 with FF and IE, as well as NVDA with FF). This test identifies pages that use only the xml lang attribute.

Accessibility support

There are no major accessibility support issues known for this rule.

Background

The xml:lang attribute is a universal attribute to mark up and or specify the human language that an element contains, confirming to the XML 1.0 documents. It is synonymous to the lang attribute and can/ should be used in parallel to allow for back-ward compatability.

Further References:

SC3-1-1-html-has-lang


name: SC3-1-1-html-has-lang

description:

  • This rule checks that the html element has a lang or xml:lang attribute.

success_criterion:

  • 3.1.1

test_aspects:

  • DOM Tree # The tree that HTML is parsed into.

authors:

  • Jey Nandakumar

Test Procedure

Applicability

The root node of the page, if it is an html element.

Expectation

  • The element has a lang or xml:lang attribute

Assumptions

There are currently no assumptions

Accessibility support

There are no major accessibility support issues known for this rule.

Background

Test Cases

Passed

<html lang="en">
<html xml:lang="en">
<html xml:lang="en" lang="en">

Failed

<html>

Inapplicable

<svg lang="en">

SC2-4-2-title


name: HTML page has a title
description: |
This rule checks that the HTML page has a title

success_criterion:

  • 2.4.2 # Page Titled

test_aspects:

  • DOM Tree

authors:

  • Wilco Fiers
  • Stein Erik Skotkjerra
  • Bryn Anderson
  • Anne Thyme Nørregaard
  • Jey Nandakumar

Test procedure

Applicability

The rule applies to any page where the root element is an html element, and which is not embedded in another page.

Note: Pages may be embedded inside other pages through elements such as iframes and object elements.

Expectation 1

The page contains at least one title element.

Note: The title element exists in other namespaces such as SVG. These are not title elements for HTML document and should be ignored.

Expectation 2

The first title element contains non-empty text.

Assumptions

There are currently no assumptions

Accessibility Support

There are no major accessibility support issues known for this rule.

Background

Test Cases

Passed

<html>
  <title>This page has a title</title>
</html>
<html>
  <title>This page gives a title to an iframe</title>
  <iframe src="page-without-title.html"></iframe>
</html>

Failed

<html>
  <h1>this page has no title</h1>
</html>
<html>
  <title> <!-- this page has an empty title --> </title>
</html>
<html>
  <iframe src="page-with-title.html"></iframe>
</html>

Inapplicable

<svg>
  <title>This is an SVG</title>
</svg>

Update Electron

From Github:

"We found a potential security vulnerability in a repository for which you have been granted security alert access.

**bbc/bbc-a11y**

Known critical severity security vulnerability detected in electron >= 1.7.0,< 1.7.11 defined in package-lock.json.
package-lock.json update suggested: electron ~> 1.7.11

Always verify the validity and compatibility of suggestions with your codebase."

This is something to check and potentially update dependencies.

SC3-1-2-text (draft)/ parked for now


name: SC3-1-2-text

description:

  • This rule checks for any changes in the human language, with in the contents of a web page & ensures if they are marked up correctly with the relevant lang attribute for any such changes.

success_criterion:

  • 3.1.2

test_aspects:

  • DOM Tree: The tree that HTML is parsed into.

authors:

  • Jey Nandakumar

Test Procedure

Applicability

  • Any valid DOM node/ element.
  • The test is applied to natural language test, and is not applicable to content of script elements, attribute and comments.

Expectation

  • The element has a lang attribute & that the value conforms to BCP 47.
  • The element is visible.
  • The test applies to visible text as contents of the element, and not to text in attributes of the element.
  • The language (identified using a language assertion algorithm) used in the text matches specified in the attribute.

Assumptions

There are currently no assumptions

Accessibility support

This rule is only applicable in a scenario where assistive technologies are inconsistent about how they determine the language of the page.

Background

Test Cases

Steps

  • Select consecutive run of text of the DOM element to which a lang attribute applies.
  • Note: Refer SC3-1-1-lang on how to retrieve relevant DOM element.
  • Ensure the element and the text contents, satisfy above expectations.

Passes

<article>
To say good morning in Dutch, you would say <p lang="nl">Goedemorgen</p>
</article>

Failed

<article lang="en">
Goedemorgen
</article>

Inapplicable

<article>
<!--
<p lang="nl">Goedemorgen</p>
-->
Good Morning
</article>

SC1-2-1+SC1-2-3-video-transcript


name: video element transcript
group: SC1-2-video-element
description: |
Non-streaming video elements must have all audio and visual information available in a transcript.

success_criterion:

  • 1.2.1 # Audio-only and Video-only (Prerecorded)
  • 1.2.3 # Audio Description or Media Alternative (Prerecorded)
  • 1.2.8 # Media Alternative (Prerecorded)

test_aspects:

authors:

  • Wilco Fiers
  • Brian Bors

Test Procedure

Applicability

The rule applies to any non-streaming video element visible in the page

Expectation 1

A text transcript is available for the test target, either on the page or available through a link (or some other mechanism).

Expectation 2

The text transcript (from expectation 1) contains all the visual and auditory information of the test target.

Assumptions

There are currently no assumptions

Accessibility support

There are no major accessibility support issues known for this rule.

Background

Test Cases

Passed

<video src="../test-assets/rabbit-video.mp4" controls></video>
<p>The above video shows a giant fat rabbit climbing out of a hole in the ground. 
He stretches, yaws, and then starts walking. 
Then he stops to scratch his bottom.</p>
<video src="../test-assets/rabbit-video.mp4" controls></video>
<a href="/test-assets/rabbit-video-transcript.html">Transcript</p>

Failed

<video src="../test-assets/rabbit-video.mp4" controls></video>
<p>The above video shows a giant fat dog climbing out of a hole in the ground. 
He stretches, yaws, and then starts walking. 
Then he stops to scratch his bottom.</p>
<video src="../test-assets/rabbit-video.mp4" controls></video>
<a href="/test-assets/rabbit-video-incorrect-transcript.html">Transcript</p>

Inapplicable

TODO: a source to a live video
<video src="../test-assets/rabbit-video.mp4" controls style="display: none;"></video>

SC3-1-1-html-lang-valid


name: SC3-1-1-html-lang-valid

description:

  • This rule checks the validity of the xml:lang and/or the lang attribute, and that it conforms to BCP 47.

success_criterion:

  • 3.1.1

test_aspects:

  • DOM Tree: The tree that HTML is parsed into.

authors:

  • Jey Nandakumar

Test Procedure

Applicability

The root node of the page, if it is an <html> element with a lang and/or xml:lang attribute.

Expectation

  • The value of the lang and/or xml:lang attribute conforms to BCP 47.

Assumptions

There are currently no assumptions

Accessibility Support

This rule is only applicable in a scenario where assistive technologies are inconsistent about how they determine the language of the page.

Background

Test Cases

Passes

<html lang="fr">
<html xml:lang="fr">
<html xml:lang="fr" lang="fr">

Failed

<html lang="xyz">
<html xml:lang="xyz">
<html lang="fr" xml:lang="xyz">

Inapplicable

<svg lang="fr">
<svg xml:lang="fr">

SC4.1.1-unique-element-id-attributes


name: unique element id attributes
description: |
This rule checks that all id attribute values on a single page are unique.

success_criterion:

  • 4.1.1 # Success Criterion 4.1.1 (Parsing)

test_aspects:

  • DOM Tree

authors:

  • Bryn Anderson
  • Jey Nandakumar

Test procedure

Applicability

Any element with an id attribute.

Expectation

All id attribute values are unique.

Assumptions

There are currently no assumptions.

Accessibility Support

There are no major accessibility support issues known for this rule.

Background

Test Cases

Passed

<div id="my-div"> This is my first element</div>
<div id="my-div1"> This is my first element</div>
<div id="my-div2"> This is my second element</div>
<svg id="my-div3"> This is my third element</svg>
<div id="my-elm"></div>
<script>
  var myElm = document.getElementById('my-elm');
  var shadow = myElm.attachShadow({ move: 'open' });
  shadow.innerHTML = '<b id="my-elm"><slot /></b>';
</script>

Failed

<div id="my-div"> This is my first element</div>
<div id="my-div"> This is my second element</svg>
<div id="my-div"> This is my first element</div>
<svg id="my-div"> This is my second element</svg>

Inapplicable

<div>This is my first element</div>
<div xml:id="my-div">This is my first element</div>

Is SC4-1-1-unique-attrs test 'page' wide or element specific?

While I understand that the guideline is element specific, the rule refers to HTML document as a whole as well as the individual elements.

Current rule https://github.com/auto-wcag/auto-wcag/blob/master/_rules/SC4-1-1-unique-attrs.md includes:

...

Selector

Select all opening tags in the HTML document

Step 1

Make a list of all the attribute names on the current tag

Check if any of the attributes occurs more the once:

Return [step1-fail][#step1-fail]

Else, return [step1-pass][#step1-fail]

...

Fail: "Attribute was used more then once on the element"

SC1-4-1-inline-links-distinguishable

name: Inline links are distinguishable

description: |
This rule checks that links that are embedded in a block of text and where color alone is used to identify them, have a sufficient color contrast ratio with the surrounding text, and additional cues are given when the link receives focus or hover.

success_criterion:

  • 1.4.1 # Use of Color

test_aspects:

  • Dom Tree
  • CSS Styling

authors:

  • Wilco Fiers
  • Jennifer Chadwick
  • Anne Thyme Nørregaard

Test procedure

Applicability

The rule applies to any HTML or SVG element with the semantic role of link that lives up to the following criteria:

Expectation 1

Within the same block of text the contrast ratio is 3:1 or greater between either

Expectation 2

When the link's focus state is triggered, the link has a distinguishing style, a distinguishing border, a distinguishing box-shadow or a background-image.

Expectation 3

When the link's hover state is triggered, the link has a distinguishing style, a distinguishing border, a distinguishing box-shadow or a background-image.

Assumptions

  • This tests assumes that distinguishing style, distinguishing border or one of the following CSS properties is used to make the link visually evident: color, background-color or background-image.
  • This test assumes that the 3:1 contrast ratio between link text and surrounding text is sufficient to meet WCAG 2.0. This value is part of technique G183, but is not specified in the 1.4.1 success criterion.
  • The methods described in distinguishing style is assumed to be sufficiently distinguishable.
  • The methods described in distinguishing border is assumed to be sufficiently distinguishable.
  • The methods described in distinguishing box-shadow is assumed to be sufficiently distinguishable.

Accessibility Support

There are no major accessibility support issues known for this rule.

Background

Test Cases

@@@ Test cases: breaks, margins, content in lots of spans etc.

Passed

<!-- Link uses the browser's default link styling -->
<p>This is a block of text with an embedded <a href="http://w3.org/WAI">link text</a>.</p>
<!-- Blue link in block of black text with text-decoration none has underline on hover and focus -->
<head>
<style>
p {
    color: black;
}

a:link {
    color: blue;
    text-decoration: none;
}

a:hover, a:focus {
    text-decoration: underline;
}
</style>
</head>

<body>

<p>This is a block of text with an embedded <a href="http://w3.org/WAI">link text</a>.</p>

</body>
<!-- Block of text only consist of one letter that is not contained within a link -->
<head>
<style>
p {
    color: black;
}

a:link {
    color: blue;
    text-decoration: none;
}

a:hover, a:focus {
    text-decoration: underline;
}
</style>
</head>

<body>

<p>A<a href="http://w3.org/WAI"> link text</a></p>

</body>
<!-- -->
<head>
<style>
p {
    color: black;
}

a:link {
    color: blue;
    text-decoration: none;
}

a:hover, a:focus {
    text-decoration: underline;
}
</style>
</head>

<body>

<p>This is a block of text with an embedded <a href="http://w3.org/WAI">link text</a>.</p>

</body>
<!-- Additional cues on hover/focus is change in font-family-->
<head>
<style>
p {
    color: black;
}

a:link {
    color: blue;
    text-decoration: none;
    font-family: "Times New Roman", Times, serif;
}

a:hover, a:focus {
    font-family: Arial, Helvetica, sans-serif;
}
</style>
</head>

<body>

<p>This is a block of text with an embedded <a href="http://w3.org/WAI">link text</a>.</p>

</body>
<!-- Additional cues on hover/focus is change in font-weight -->
<head>
<style>
p {
    color: black;
}

a:link {
    color: blue;
    text-decoration: none;
    font-weight: normal;
}

a:hover, a:focus {
    font-weight: bold;
}
</style>
</head>

<body>

<p>This is a block of text with an embedded <a href="http://w3.org/WAI">link text</a>.</p>

</body>
<!-- Additional cues on hover/focus is italics -->
<head>
<style>
p {
    color: black;
}

a:link {
    color: blue;
    text-decoration: none;
    font-style: normal;
}

a:hover, a:focus {
    font-style: italic;
}
</style>
</head>

<body>

<p>This is a block of text with an embedded <a href="http://w3.org/WAI">link text</a>.</p>

</body>
<!-- Additional cues on hover/focus is change of background-color -->
<head>
<style>
p {
    color: black;
    background-color: white;
}

a:link {
    color: blue;
    text-decoration: none;
}

a:hover, a:focus {
    background-color: red;
}
</style>
</head>

<body>

<p>This is a block of text with an embedded <a href="http://w3.org/WAI">link text</a>.</p>

</body>
<!-- Additional cues on hover/focus is background-image -->
<head>
<style>
p {
    color: black;
}

a:link {
    color: blue;
    text-decoration: none;
}

a:hover, a:focus {
    background-image: url("arrow.gif");
}
</style>
</head>

<body>

<p>This is a block of text with an embedded <a href="http://w3.org/WAI">link text</a>.</p>

</body>
<!-- Button that is styled to look like a link and has role of link -->
<head>
<style>
p {
    color: black;
}

button {
     background:none;
     color:blue;
     border:none; 
     padding:0;
     font: inherit;
     cursor: pointer;
}

button:hover, button:focus {
    text-decoration: underline;
}
</style>
</head>

<body>

<p>This is a block of text with an embedded <button role="link">button that acts like a link</button>.</p>

</body>

´´´html

´´´

´´´html

´´´

Failed

@@@ split out and a: link underlined

<!-- Too low contrast between link text and surrounding text-->

<head>
<style>
p {
    color: red;
}

a:link {
    color: blue;
    text-decoration: none;
}

a:hover, a:focus {
    text-decoration: underline;
}
</style>
</head>

<body>

<p>This is a block of text with an embedded <a href="http://w3.org/WAI">link text</a>.</p>

</body>
<!-- No additional cues on hover  -->

<head>
<style>
p {
    color: black;
}

a:link {
    color: blue;
    text-decoration: none;
}

a:focus {
    text-decoration: underline;
}
</style>
</head>

<body>

<p>This is a block of text with an embedded <a href="http://w3.org/WAI">link text</a>.</p>

</body>
<!-- Additional cues on focus -->
<head>
<style>
p {
    color: black;
}

a:link {
    color: blue;
    text-decoration: none;
}

a:hover {
    text-decoration: underline;
}
</style>
</head>

<body>

<p>This is a block of text with an embedded <a href="http://w3.org/WAI">link text</a>.</p>

</body>

´´´html

´´´

Inapplicable

<!-- -->
<!-- <a> element doesn't have href="", so it doesn't have role of link -->
<head>
<style>
p {
    color: black;
}

a:link {
    color: blue;
    text-decoration: none;
}
</style>
</head>

<body>

<p>This is a block of text with an embedded <a>a element without href attribute</a>.</p>

</body>
<!-- <a> element has had it's role changed -->
<head>
<style>
p {
    color: black;
}

a:link {
    color: blue;
    text-decoration: none;
}
</style>
</head>

<body>

<p>This is a block of text with an embedded <a href="http://w3.org/WAI" role="button">link that has had its role changed</a>.</p>

</body>
<!-- No visible text in the block of text the link is contained within -->
<head>
<style>
p {
    color: black;
}

a:link {
    color: blue;
    text-decoration: none;
}
</style>
</head>

<body>

<p><a href="http://w3.org/WAI">Read more</a><span style="display:none">about our latest organisational changes.</span></p>

</body>
<!-- Breadcrumb with only links and separator characters -->
<head>
<style>
p {
    color: black;
}

a:link {
    color: blue;
    text-decoration: none;
}

</style>
</head>

<body>

<p>... / <a>About us</a> / <a>CSR</a> / <a>Accessibility</a></p>

</body>
<!-- -->
<head>
<style>
p {
    color: black;
}

a:link {
    color: blue;
    text-decoration: none;
}
</style>
</head>

<body>

<p>This is a block of text<a href="http://w3.org/WAI"></a>.</p>

</body>
<!-- Link is underlined, therefore this rule is not applicable -->
<head>
<style>
p {
    color: black;
}

a:link {
    text-decoration: underline;
}
</style>
</head>

<body>

<p>This is a block of text with an embedded <a href="http://w3.org/WAI">link text</a>.</p>

</body>
<!-- -->
<head>
<style>
a:link {
    text-decoration: none;
}
</style>
</head>

<body>

<p>This is a block of text with an embedded <span style="text-decoration: underline;"><a href="http://w3.org/WAI">link text that is underlined</a><span>.</p>

</body>
<!-- -->
<head>
<style>
a:link {
    text-decoration: none;
}
</style>
</head>

<body>

<p><a href="http://w3.org/WAI">link 1</a> | <a href="http://w3.org/WAI">link 2</a>.</p>

</body>
<!-- -->
<head>
<style>
a:link {
    text-decoration: none;
}
</style>
</head>

<body>

<p>This is a block of text with an embedded <a href="http://w3.org/WAI"><span style="text-decoration: underline;">link text that is underlined<span></a>.</p>

</body>
<!-- -->
<!-- button that looks like a link but has the role of button -->
<head>
<style>
p {
    color: black;
}

button {
     background:none;
     color:blue;
     border:none; 
     padding:0;
     font: inherit;
     cursor: pointer;
}

button:hover {
    text-decoration: underline;
}

button:focus {
    text-decoration: underline;
}

</style>
</head>

<body>

<p>This is a block of text with an embedded <button>button that acts like a link</button>.</p>

</body>
<!-- Link text color has too low contrast with background, but this is a violation of success criteria 1.4.3 Contrast (Minimum) and 1.4.6 Contrast (Enhanced), not 1.4.1 Use of Color  -->
<p>This is a block of text with an embedded <a href="http://w3.org/WAI">link text</a>.</p>
<!-- Blue link in block of black text with text-decoration none has underline on hover and focus -->
<head>
<style>
p {
    color: black;
    background-color: white;
}

a:link {
    color: yellow;
    text-decoration: none;
}

</style>
</head>

<body>

<p>This is a block of text with an embedded <a href="http://w3.org/WAI">link text</a>.</p>

</body>

@@@ add a:focus test cases for Passed test cases
@@@ fix up text color in first failed test case
@@@ comments in test cases about why they are failing


Definitions

Block of text

A block of text is a run of phrasing content containing no consecutive line breaks.

Contained within one block-like ancestor
has rendered text or phrasing content with rendered text

If more than one br element is used, followed by additional rendered text or phrasing content with rendered text, this is considered a new block of text.

What if preelement is used?

Distinguishing Border

Look at the width, style, and color of the border-top, border-bottom or outline.

For one of these to be a distinguishing border, all the following must be true:

  • The *-width is greater than 0
  • The *-style is not set to none
  • The *-color is not transparent

If either border-top, border-bottom or outline is distinguishable, the element has a distinguishing border.

Assumptions

  • Use of a border, of 1 or more pixels, not set to none, and not with a color of transparent, is assumed to be sufficiently distinguishable.

Distinguishing style

Compare the style properties font-family, font-weight, font-style, text-decoration of the element to that of the surrounding text.

If any of the properties have a different value for the one than for the other, the style is distinguishable.

Assumptions

  • This definition assumes that one of the following shorthand CSS properties (or the related expanded properties e.g. font-family) is used to make the element visually evident: font or text-decoration
  • This definition assumes that any change in font is sufficiently distinguishable, and that fonts are loaded when they are present

SC2-4-6-descriptive-headings


name: Descriptive headings
description: |
This rule checks that headings describe the topic or purpose of the content.

success_criterion:

  • 2.4.6 # Headings and labels

test aspects:

  • DOM Tree

authors:

  • Dagfinn Rømen
  • Geir Sindre Fossøy
  • Carlos Duarte

Test procedure

Applicability

The rule applies to any element with the the semantic role of heading.

Note: The WCAG 2.0 success criterion 2.4.6 applies to all headings.

Note: Heading content defines the header of a section (whether explicitly marked up using sectioning content elements, or implied by the heading content itself).

Expectation

Each target element describes the topic or purpose of the subsequent content.

Note: Headings do not need to be lengthy. A word, or even a single character, may suffice.

Assumptions

  • Heading markup is covered by success criterion 1.3.1 Info and Relationships.

Accessibility Support

There are no major accessibility support issues known for this rule.

Background

Test Cases

Passed

<!-- Heading marked up with h-element that describes the topic or purpose of the following section of content -->
<h1 class="target">Opening Hours</h1>
<p>We are open Monday through Friday from 10 to 16</p>
<!-- Heading marked up with role="heading" that describes the topic or purpose of the following section of content -->
<span role="heading">Opening Hours</span>
<p>We are open Monday through Friday from 10 to 16</p>
<!-- Heading marked up with h-element with an image that describes the topic or purpose of the following section of content -->
<h1 class="target"><img scr="../test-assets/opening_hours_icon.png" alt="Opening hours"></img></h1>
<p>We are open Monday through Friday from 10 to 16</p>
<!-- Heading marked up with h-element that is a single character that describes the topic or purpose of the following section of content -->
<h1 class="target">A</h1>
<dl>  
<dt>airplane</dt>
  <dd>a powered flying vehicle with fixed wings and a weight greater than that of the air it displaces.</dd>
 <dt>apple</dt>
  <dd>the round fruit of a tree of the rose family, which typically has thin green or red skin and crisp flesh.</dd>
</dl>

Failed

<!-- Heading marked up with h-element that does not describe the topic or purpose of the following section of content -->
<h1 class="target">Weather</h1>
<p>We are open Monday through Friday from 10 to 16</p>
<!-- Heading marked up with role="heading" that does not describe the topic or purpose of the following section of content -->
<span role="heading">Weather</span>
<p>We are open Monday through Friday from 10 to 16</p>

Inapplicable

<!-- No heading -->
<p>We are open Monday through Friday from 10 to 16</p>
<!-- Heading that is not visible to users -->
<h1 style="display: none;">Opening hours</h1>
<p>We are open Monday through Friday from 10 to 16</p>

Review of SC1-3-1-tables-headers-id-correct


rule_id: SC1-3-1-tables-headers-id-correct
name: Tables headers-id associations correct
test_mode: semi-automatic
environment: DOM Structure

success_criterion:

  • 1.3.1 # Info and relationships (level A)

authors:

  • Ken Petri

Description

This rule checks that data table headers-id associations reference correct targets in the correct order.

Background

Assumptions

Test procedure

Selector

Loop outward from most deeply nested table.

For each un-marked table, select all elements that match the following CSS selector:

table:not([role=presentation]) th[headers],
table:not([role=presentation]) td[headers],
table:not([role=none]) th[headers],
table:not([role=none]) td[headers]

Step 1

Mark table complete.

For each value in each cell headers attribute,

find the 'th' referenced,

give the user the following question:

Property Value
Presented item Highlight a table cell and the related "header" cell.
Question Is the cell appropriately categorized by or semantically related with the associated "header" cell?
Requires context Yes.
Requires interaction Yes.

if yes, continue with step 2

else, return step1-fail1.

Step 2

For each value in each cell headers attribute,

find the 'th' referenced,

give the user the following question:

Property Value
Presented item Highlight a table cell and the related header cell. Display the sequence order of the header cell as a number value, as specified by the order in which the header's id appears within the cell's headers attribute.
Question Is the number of the related header consistent with the desired reading sequence?
Requires context Yes.
Requires interaction Yes.

if yes, return step2-pass1

else, return step2-fail1.

Outcome

The resulting assertion is as follows,

Property Value
type Assertion
test auto-wcag:SC1-3-1-tables-headers-id-correct
subject the selected element
mode semi-automatic
result One TestResult from below

step1-fail1

Property Value
type TestResult
outcome Failed
description Table cell references an incorrect th via the headers attribute.

step1-pass1

Property Value
type TestResult
outcome Passed

step2-fail1

Property Value
type TestResult
outcome Failed
description Table cell references a th via the headers in an incorrect order.

step2-pass1

Property Value
type TestResult
outcome Passed

Implementation Tests

Implementation tests are available at:

Change log

Version 0.2

  • Removed explanations from Requires context and Requires interaction rows in Step 1 and Step 2 questions.
  • Rule now conforms to HTML 5.1 spec: headers can only reference a th.
  • Added recommended dependency on tables headers id valid.

Version 0.1

  • Initial draft of rule.

SC1-2-2-Video-closed-captions


name: video closed captions
group: SC1-2-2-video-captions
description: |
Closed captions are available for audio information in non-streaming video elements.

success_criterion:

  • 1.2.2 # Captions (Prerecorded)

test_aspects:

authors:

  • Wilco Fiers
  • Brian Bors

Test Procedure

Applicability

The rule applies to any non-streaming video element visible in the page where the video contains audio.

Expectation

Of each test target, audio information that is not expressed visually in the video, is available through a caption track.

Assumptions

There are currently no assumptions

Accessibility support

There are no major accessibility support issues known for this rule.

Background

Test Cases

Passed

<video src="../test-assets/rabbit-video.mp4" controls>
  <track src="rabbit-video-closed-caption.vtt" kind="captions">
</video>

Failed

<video src="../test-assets/rabbit-video.mp4" controls></video>

Inapplicable

TODO: a source to a live video
<video src="../test-assets/rabbit-video-silent.mp4" controls></video>
<video src="../test-assets/rabbit-video.mp4" controls style="display: none;"></video>

Review of SC1-3-1-tables-headers-id-valid


rule_id: SC1-3-1-tables-headers-id-valid
name: Tables headers-id associations valid
test_mode: automatic
environment: DOM Structure

success_criterion:

  • 1.3.1 # Info and relationships (level A)

authors:

  • Ken Petri

Description

This rule checks that data table headers attributes have values that reference td or th elements in the same table.

Background

Assumptions

Test procedure

Selector

Loop outward from most deeply nested table.

For each un-marked table, select all elements that match the following CSS selector:

table:not([role=presentation]) th[headers],
table:not([role=presentation]) td[headers],
table:not([role=none]) th[headers],
table:not([role=none]) td[headers]

Step 1

Mark table completed.

For each value in each cell headers attribute,

check that the value references an id attribute value of a th within the currently selected table,

if yes, return step1-pass1

else, return step1-fail1.

Outcome

The resulting assertion is as follows,

Property Value
type Assertion
test auto-wcag:SC1-3-1-tables-headers-id-valid
subject the selected element
mode automatic
result One TestResult from below

step1-fail1

Property Value
type TestResult
outcome Failed
description Table cell's headers attribute contains an id that does not correspond to a th in the same table.

step1-pass1

Property Value
type TestResult
outcome Passed

Implementation Tests

Implementation tests are available at:

Change log

Version 0.3

  • Rule now conforms to HTML 5.1 spec: headers can only reference a th.

Version 0.2

  • Refactored into an automatic rule (this one) and a semi-automatic rule, tables headers id correct.
  • Selector corrected.
  • Ensures selector tests only a single table at a time (for nested tables).
  • Conforms to rule template.

Review draft SC1-4-3-text-bg-contrast

Current rule is at https://github.com/auto-wcag/auto-wcag/blob/master/_drafts/SC1-4-3-text-bg-contrast.md and includes commented notes.

For review purposes:

Description

This test checks that the text nodes on a page contrast sufficiently with the background, gradient or image behind them.

Background

  • Understanding SC 1.4.3
  • Contrast (Minimum) Understanding SC 1.4.3
  • G18: Ensuring that a contrast ratio of at least 4.5:1 exists between text (and images of text) and background behind the text
  • G145: Ensuring that a contrast ratio of at least 3:1 exists between text (and images of text) and background behind the text
  • F24: specifying foreground colors without specifying background colors
  • F83: Failure of Success Criterion 1.4.3 and 1.4.6 due to using background images that do not provide sufficient contrast with foreground text (or images of text)

Assumptions

  • Code validates to a published grammar (eg. 4.1.1 and 4.1.2)
  • Only checking HTML text nodes, not text in images
  • Requires a rendered page (manual steps will require sight)
  • Only checking text nodes on a single page at a time

Test procedure

Selector

Select elements that match the following XPath or Javascript selector:

//*[text()]
node.nodeType = 3;

For each selected item, go through the following steps:

Step 1

Determine if the text node has an applied/computed "color" property (ie. not default and not a background image or gradient). Record the text-color value; unknown or null if default.

Continue with step 2

Step 2

Determine if the parent, or another layer or layers behind the text node, has an applied/computed "background-color" (ie. not default and not a background image or gradient) and is not transparent. Record the background-color value or values; unknown or null if default.

Continue with step 3

Step 3

Check if the recorded text-color value, or background-color value or values, is unknown or null, while the other or others has a color.

if yes, return step3-fail else, continue with step 4

Step 4

Check if the text-color value and background-color value or values contrast sufficiently for the size and boldness of text. Record all contrast-ratios.

if no, return step4-fail else, continue with step 5

Step 5

Determine if any other styles are applied to the text node or background element or elements that would affect the colour contrast. For example, background image or gradient, drop-shadow, border or opacity. Record text-styles and background-styles.

if yes, return step5-cannottell else, return step 5-pass

Outcome

step3-fail

Property Value
type TestResult
outcome Failed
description Text node or background has some color property, while the other does not (see F24).

step4-fail

Property Value
type TestResult
outcome Failed
description Text node color property and background color property do not contrast sufficiently (for the text size and weight): [contrast-ratio].

step5-cannottell

Property Value
type TestResult
outcome CannotTell
description Further contrast tests are needed for text node and background, because of [text-styles] and/or [background-styles].

step5-pass

Property Value
type TestResult
outcome Pass
description Text node and background appear to contrast sufficiently: [contrast-ratio].

SC2-1-2-no-keyboard-trap-r1 - Test-case


rule_id: SC2-1-2-no-keyboard-trap-r1
test_case_template: default
success_criterion:

  • 2.1.2 No Keyboard Trap (level A)

Passed

<a href ="#">Link 1</a>
<button class="target">Button1</button>

Failed

<a href="#">Link 1</a>
<button class="target" onblur="setTimeout(() => this.focus(), 10)">Button1</button>
<button class="target" onblur="setTimeout(() => this.nextSibling.focus(), 10)">Button1</button>
<button class="target" onblur="setTimeout(() => this.previousSibling.focus(), 10)">Button2</button>

Inapplicable

<h1>Page 1</h1>

Review 1.1.1 images

Action on me to review 1.1.1. images, see given our current approach if where we can break up this rule.

Rule SC2-4-7-focus-in-viewport.html assumes negative offset

I was looking at
https://auto-wcag.github.io/auto-wcag/rules/SC2-4-7-focus-in-viewport.html
Just wondering if the check would catch cases where authors pick large positive offsets to move items to outside the viewport. The problem is clear: the exact size of the viewport is not known. x=2000px / y=2000px will movce the item outside the viewport but not on very large screens. So it seems this can only be tested for negative offsets - or positive offsets just beyond the currenty available screen resolutions.

SC4-1-1-id test procedure may only check first id and requires full page load

Current rule https://github.com/auto-wcag/auto-wcag/blob/master/_rules/SC4-1-1-id.md includes:

Assumptions
no known assumptions

...

Selector

Select all elements that match the following CSS selector: *[id]

Step 1

  • IF there is no list called 'knownIDs':
    • Create an empty list 'knownIDs;
  • IF the value of the ID attribute exists in 'knownIDs':
    • Return step1-fail
  • ELSE:
    • Add the value of the ID attribute of the selected element to 'knownIDs'
    • Return step1-pass

...

Fail: "The ID of this element has occurred before on this page"

SC1-2-3+SC1-2-5-Video-description-track


name: Video element description track
group: SC1-2-3+1-2-5-Video-element
description: |
This rule checks that non-streaming video elements with a description track have that track be descriptive.

success_criterion:

  • 1.2.3 # Audio Description or Media Alternative (Prerecorded)
  • 1.2.5 # Audio Description (Prerecorded)

test_aspects:

authors:

  • Wilco Fiers
  • Brian Bors

Test Procedure

Applicability

The rule applies to any non-streaming video element visible in the page where the video contains audio and a track element with a kind="description" attribute.

Expectation

The visual information of each test target not available through its audio is describes with a description track element.

Note: Multiple description track elements may be useful for different languages, but at least one must match the language of the video.

Assumptions

There are currently no assumptions

Accessibility support

Unknown

Background

Test cases

Passed

<video src="../test-assets/rabbit-video.mp4" controls>
  <track kind="descriptions" src="rabbit-video-descriptions.vtt">
</video>

Failed

<video src="../test-assets/rabbit-video.mp4" controls>
  <track kind="descriptions" src="rabbit-video-incorrect-descriptions.vtt">
</video>

Inapplicable

<video src="../test-assets/rabbit-video.mp4" controls></video>
TODO: a source to a live video
<video src="../test-assets/rabbit-video.mp4" controls style="display: none;">
  <track kind="descriptions" src="rabbit-video-descriptions.vtt">
</video>
<video src="../test-assets/rabbit-video-silent.mp4" controls></video>

Restructure the format

We've been using the same template for two years now, and given what we've learned I think we can do better.

https://github.com/auto-wcag/auto-wcag/blob/master/pages/rule-template.md

A few topics to address:

  • Move the test procedure above background and assumptions. It seems to me this is a more important part of any rule.
  • We should consider including validation tests. I would suggest that we include at least one code snippet for each unique outcome a rule creates. The discussions about ACT have shown there is a lot of interest in this.
  • The way we present results currently isn't semantically correct. In the wiki we had a template for this, but markup does not have these. We'll need a better way to show these in markdown, without them getting too complicated.

Chore: Improve test cases format

The current format looks like this:

---
rule_id: SCx-y-z-name

success_criterion:
- x.y.z
---

<h2>inapplicable</h2>

<div data-outcome="incomplete">
    <!-- HTML code here -->
</div>

<!-- other incomplete examples if needed -->

<h2>step1-pass</h2>

<div data-outcome="passed"
  data-outcome-id="step1-pass">
    <!-- HTML code here -->
</div>

<!-- more test cases -->

<h2>step1-fail</h2>

<div data-outcome="failed"
  data-outcome-id="step1-fail">
    <!-- HTML code here -->
</div>

<!-- more test cases -->

<h2>step#-pass/fail</h2>

<!-- Add pass / fail / incomplete examples for every step that has them -->

There are a number of limitations to this:

  • This format is fairly verbose
  • It doesn't allow us to isolate tests from one another
  • The metadata could actually impact the test

The ACT TF has developed an alternative format, which comes with its own advantages and disadvantages. We should think about what would be the easiest format for us to work with.
https://github.com/w3c/wcag-act-rules/blob/master/_rule-tests/ACT-R1-tests.html

SC1-2-3+SC1-2-5-video-audio-description


name: audio described video element
group: SC1-2-video-element
description: |
Non-streaming video elements must not contain any visual information that is not expressed in the audio

success_criterion:

  • 1.2.3 # Audio Description or Media Alternative (Prerecorded)
  • 1.2.5 # Audio Description (Prerecorded)

test_aspects:

authors:

  • Wilco Fiers
  • Brian Bors

Test Procedure

Applicability

The rule applies to any non-streaming video element visible in the page where the video contains audio.

Expectation

The visual information of each test target is available through its audio, or through an audio description track.

Assumptions

There are currently no assumptions

Accessibility support

There are no major accessibility support issues known for this rule.

Background

Test Cases

Passed

<video src="../test-assets/rabbit-video-with-voiceover.mp4" controls></video>
TODO: Video with separate audio description

Failed

<video src="../test-assets/rabbit-video.mp4" controls></video>
<video src="../test-assets/rabbit-video-with-incorrect-voiceover.mp4" controls></video>
TODO: Video with separate incorrect audio description

Inapplicable

TODO: a source to a live video
<video src="../test-assets/rabbit-video-silent.mp4" controls></video>
<video src="../test-assets/rabbit-video.mp4" controls style="display: none;"></video>

SC4-1-1-accesskey test procedure may only check first accesskey and requires full page load

Current rule https://github.com/auto-wcag/auto-wcag/blob/master/_rules/SC4-1-1-accesskey.md includes:

Assumptions

  • If the accesskey value has multiple characters the user agent picks the first character and ignores the rest. See: WHATWG on Interaction.

...

Selector

Select any element with an accesskey attribute. The following CSS selector could be used: *[accesskey]

Step 1

  • IF there is no list called 'knownAccesskeys':
    • Create an empty list 'knownAccesskeys;
  • Take the first character of the ACCESSKEY attribute as FirstChar
  • IF the FirstChar exists in 'knownAccesskeys':
    • Return step1-fail
  • ELSE:
    • Add the FirstChar to 'knownAccesskeys'
    • Return step1-pass

...

Fail "The accesskey of this element has occurred before on this page"

SC2-1-2-no-keyboard-trap-standard-navigation (Updated)


name: No keyboard trap standard navigation
group:

  • SC2-1-2-no-keyboard-trap-standard-navigation
  • SC2-1-2-no-keyboard-trap-non-standard-navigation

description: |
This rule checks if it is possible to use standard keyboard navigation to navigate through all content on a web page without becoming trapped in any element.

success_criterion:

  • 2.1.2 # No Keyboard Trap

test aspects:

  • DOM Tree

authors:

  • Dagfinn Rømen
  • Geir Sindre Fossøy
  • Malin Øvrebø
  • Shadi Abou-Zahra
  • Carlos Duarte
  • Anne Thyme Nørregaard
  • Stein Erik Skotkjerra

Test procedure

Applicability

The rule applies to any HTML or SVG element on a web page that is focusable by keyboard.

Expectation

For each target element focus can cycle to the browser UI by using standard keyboard navigation.

Note: Cycling back to the browser UI can be done both by moving forward through the tab order and by moving backwards. It is not possible to fulfil this expectation by using browser specific shortcuts to return to the browser UI.

Assumptions

  • The WCAG success criterion applies to all content where focus can be moved to through keyboard navigation.
  • It is possible to use unmodified arrow or tab keys, or other standard exit methods to move focus away.
  • The focus order in keyboard navigation is cyclical, not linear, meaning that the focus order will cycle to the first/last element when it moves away from the last/first element.

Accessibility support

There are no major accessibility support issues known for this rule.

Background

Test Cases

Passed

<a href ="#">Link 1</a>
<button class="target">Button1</button>
<a href ="#" style="visibility: hidden;">Link 1</a>
<button class="target" style="visibility: hidden;">Button1</button>
<div tabindex=“1”>Text</div>
<!-- something with tabindex=0 ? -->

Failed

<a href="#">Link 1</a>
<button class="target" onblur="setTimeout(() => this.focus(), 10)">Button1</button>
<button class="target" onblur="setTimeout(() => this.nextSibling.focus(), 10)">Button1</button>
<button class="target" onblur="setTimeout(() => this.previousSibling.focus(), 10)">Button2</button>

Inapplicable

<h1>Page 1</h1>
<a href="#" tabindex="-1">Tab key cannot reach here!</a>
<!-- Element you can't reach -->
<button type="button" disabled>Click Me!</button>
<!-- Disabled element -->
<button type="button" style=“display: none;”>Click Me!</button>
<!-- Hidden element -->

Document the new workflow

Auto-WCAG Workflow

Step 1: Creating the proposal in an Issue

Every rule is designed by a team of two or three people. They do their work in a github issue. This means that every activity is represented by an open issue on Github. The first post of an issue contains the proposal they are working on. In subsequent posts, discussions are held, and as they are resolved, the draft at the top of the issue is updated. Once the group is done with the proposal, a pull request is created, and the issue is closed.

Step 2: Propose a change in a Pull Request

When a proposal in step 1 is done, a pull request is created to update the rule in _drafts. This gives the rest of auto-WCAG the opportunity to respond to the proposal. At this point one of three things can happen:

  1. Editorial comments can be resolved immediately by updating the pull request.

  2. For any comments that can't be resolved immediately, a new issue is created. Once the review period of the pull request has passed, the pull request is merged in. The team working on this rule continues working on the new issue that was created, going back to step 1.

  3. If no comments come in, the issue can be merged in after the review period. If the authors feel the rule is read for publication, after they merged the PR into draft, they can open a new PR, wich must have "FINAL" in the PR name, to move the rule from _drafts to _rules. This will publish the rule. The rule needs at least 3 approved votes before it can be merged from people who weren't the editors. If new comments come in, the PR must be closed without merging, and a new issue is created to work on the fix.

Pruning Issues and PRs

At every auto-WCAG call, inactive issues and PRs are reviewed. If an issue / PR hasn't been updated since the last auto-WCAG call it will be closed. This is to ensure that issues and PRs don't get stale, and so that it's always clear at a glance what is being worked on. Issues closed for this reason are given the stale flag, and can be reopened if a new team is interested to work on it.

SC3-1-1-html-xml-lang-match


name: SC3-1-1-html-xml-lang-match

description:

  • The rule checks that for the html element, there is no mismatch between the primary language in lang and xml:lang attributes, if both are used.

success_criterion:

  • 3.1.1

test_aspects:

  • DOM Tree # The tree that HTML is parsed into.

authors:

  • Jey Nandakumar

Test Procedure

Applicability

The root node of the page, if it is an html element with both lang and xml:lang attributes.

Expectation

  • The value of the primary language sub-tag for the lang and xml:lang attributes are the same.

Note: language tags are not case sensitive

Assumptions

There are currently no assumptions

Accessibility Support

Since most assistive technologies will consistently use lang over xml:lang when both are used, violation of this rule may not necessarily be a violation of WCAG 2. Only when there are inconsistencies between assistive technologies, as to which attribute is used to determine the language, does this lead to a violation of SC 3.1.1.

Background

Test Cases

Passed

<html lang="en" xml:lang="en">
<html lang="en" xml:lang="En">
<html lang="en" xml:lang="en-GB">

Failed

<html lang="fr" xml:lang="en">

Inapplicable

<svg lang="en" xml:lang="en">

SC2-4-6-descriptive-labels


name: Label is descriptive
test_type: atomic

description: |
This rule checks that labels describe the purpose of the interface components.

success_criterion:

  • 2.4.6 # Headings and labels

test_aspects:

  • DOM Tree
  • Accessibility Tree

authors:

  • Dagfinn Rømen
  • Geir Sindre Fossøy

Test Procedure

Applicability

This rule applies to

  • <label> elements and
  • elements that are connected to a second element with the use of the aria labelledby attributt
  • that are visible and included in the accessibility tree.

Note: This rule is only applies to (...markup equivalent to semantic role of label...). Thus, it is a partial check for WCAG 2.0 success criterion 2.4.6, which applies to all labels. "Label" is used in its general sense and includes text or other components with a text alternative that is presented to a user to identify a component within Web content.

Note: A label is presented to all users whereas the name may be hidden and only exposed by assistive technology. In many (but not all) cases the name and the label are the same.

Expectation

Each target element describes the purpose of the element its a caption for.

Note: Labels do not need to be lengthy. A word, or even a single character, may suffice.

Assumptions

There are currently no assumptions.

Accessibility support

There are no major accessibility support issues known for this rule.

Background

Test Cases

Passed

Passed example 1

Label that is coded with the <label> element and describes the purpose of the associated element.

<label for ="fname">First name:</label>
<input id="fname" type="text" name="fname"/>

Failed

Failed example 1

Description...

<!-- code -->

Inapplicable

Inapplicable example 1

Description...

<!-- code -->

SC1-2-2-Video-captions


name: video captions
description: |
Captions are available for audio information in non-streaming video elements.

success_criterion:

  • 1.2.2 # Captions (Prerecorded)

test_aspects:

authors:

  • Wilco Fiers
  • Brian Bors

Test Procedure

Applicability

The rule applies to any non-streaming video element visible on the page where the video contains audio.

Expectation

Of each test target, audio information that is not expressed visually in the video, is available through captions.

Note: Captions can be either embedded in the video file itself or can be made available trough a separate track.

Assumptions

There are currently no assumptions

Accessibility support

There are no major accessibility support issues known for this rule.

Background

Test Cases

Passed

<video src="../test-assets/perspective-video-with-captions.mp4" controls></video>
<video src="../test-assets/perspective-video.mp4" controls>
  <track src="perspective-caption.vtt" kind="captions">
</video>

Failed

<video src="../test-assets/perspective-video.mp4" controls></video>
<video src="../test-assets/perspective-keyboard-compatibility-video.mp4" controls>
  <track src="perspective-incorrect-caption.vtt" kind="captions">
</video>

Inapplicable

<video src="../test-assets/perspective-video-silent.mp4" controls></video>
<video src="../test-assets/perspective-video.mp4" controls style="display: none;"></video>

SC2-2-1+SC3-2-5-meta-refresh


name: Meta-refresh no delay
description: |
This rule checks that the meta element is not used for delayed redirecting or refreshing.

success_criterion:

  • 2.2.1 # Timing Adjustable
  • 3.2.5 # Change on Request

test_aspects:

  • DOM Tree

authors:

  • Anne Thyme Nørregaard

Test procedure

Applicability

The rule applies to any content attribute in a meta element that contains the http-equiv attribute with value "refresh" (case-insensitive).

Expectation

The value before the first semicolon or comma (representing seconds) of the value of the content attribute is not a number greater than 0.

Note: Semi-colon or comma is optional in the content attribute. When none is present, the value of the attribute should be considered as a whole. See meta-refresh for parsing instructions.

Assumptions

  • This test assumes no functionality was provided by the website for the user to adjust the timer.

Accessibility Support

There are no major accessibility support issues known for this rule.

Background

  • H76: Using meta refresh to create an instant client-side redirect
  • F40: Failure of Success Criterion 2.2.1 and 2.2.4 due to using meta redirect with a time limit
  • F41: Failure of Success Criterion 2.2.1, 2.2.4, and 3.2.5 due to using meta refresh with a time-out

Test Cases

Passed

  <head>           
    <meta http-equiv="refresh" content="0; URL='https://auto-wcag.github.io/auto-wcag/'" />    
  </head>  
  <head>           
    <meta http-equiv="refresh" content="foo; URL='https://auto-wcag.github.io/auto-wcag/'" />    
  </head>  
<head>
<meta http-equiv=refresh content=" -00.12 foo">
</head>
<head>
<meta http-equiv="refresh" content="; 30">
</head>

Failed

<head>
<meta http-equiv="refresh" content="30">
</head>
<head>
<meta http-equiv="refresh" content="30; URL='https://auto-wcag.github.io/auto-wcag/'">
</head>

Inapplicable

<head>
<meta http-equiv="refresh">
</head>
<head>
<meta http-equiv="">
</head>
<head>
<meta content="30">
</head>
<head>
<meta>
</head>

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.