CINXE.COM

<!doctype html><html lang="en"> <head> <meta content="text/html; charset=utf-8" http-equiv="Content-Type"> <meta content="width=device-width, initial-scale=1, shrink-to-fit=no" name="viewport"> <title>Accessibility Conformance Testing (ACT) Rules Format 1.1</title> <meta content="WD" name="w3c-status"> <meta content="Bikeshed version 82ce88815, updated Thu Sep 7 16:33:55 2023 -0700" name="generator"> <link href="https://www.w3.org/TR/act-rules-format/" rel="canonical"> <meta content="f0884d5fe87415ada432b24115bc615145f990d0" name="document-revision"> <style> .rfc2119 { text-transform: uppercase; } pre.highlight { background: white !important; border: solid 1px #ded390; border-radius: 2px; } pre.highlight c-[s], pre.highlight c-[u] { color: #79532e; } pre.highlight c-[f] { color: #578201; } pre.highlight c-[p] { color: #757575; } </style> <style>/* Boilerplate: style-autolinks */ .css.css, .property.property, .descriptor.descriptor { color: var(--a-normal-text); font-size: inherit; font-family: inherit; } .css::before, .property::before, .descriptor::before { content: "‘"; } .css::after, .property::after, .descriptor::after { content: "’"; } .property, .descriptor { /* Don't wrap property and descriptor names */ white-space: nowrap; } .type { /* CSS value <type> */ font-style: italic; } pre .property::before, pre .property::after { content: ""; } [data-link-type="property"]::before, [data-link-type="propdesc"]::before, [data-link-type="descriptor"]::before, [data-link-type="value"]::before, [data-link-type="function"]::before, [data-link-type="at-rule"]::before, [data-link-type="selector"]::before, [data-link-type="maybe"]::before { content: "‘"; } [data-link-type="property"]::after, [data-link-type="propdesc"]::after, [data-link-type="descriptor"]::after, [data-link-type="value"]::after, [data-link-type="function"]::after, [data-link-type="at-rule"]::after, [data-link-type="selector"]::after, [data-link-type="maybe"]::after { content: "’"; } [data-link-type].production::before, [data-link-type].production::after, .prod [data-link-type]::before, .prod [data-link-type]::after { content: ""; } [data-link-type=element], [data-link-type=element-attr] { font-family: Menlo, Consolas, "DejaVu Sans Mono", monospace; font-size: .9em; } [data-link-type=element]::before { content: "<" } [data-link-type=element]::after { content: ">" } [data-link-type=biblio] { white-space: pre; } @media (prefers-color-scheme: dark) { :root { --selflink-text: black; --selflink-bg: silver; --selflink-hover-text: white; } } </style> <style>/* Boilerplate: style-colors */ /* Any --*-text not paired with a --*-bg is assumed to have a transparent bg */ :root { color-scheme: light dark; --text: black; --bg: white; --unofficial-watermark: url(https://www.w3.org/StyleSheets/TR/2016/logos/UD-watermark); --logo-bg: #1a5e9a; --logo-active-bg: #c00; --logo-text: white; --tocnav-normal-text: #707070; --tocnav-normal-bg: var(--bg); --tocnav-hover-text: var(--tocnav-normal-text); --tocnav-hover-bg: #f8f8f8; --tocnav-active-text: #c00; --tocnav-active-bg: var(--tocnav-normal-bg); --tocsidebar-text: var(--text); --tocsidebar-bg: #f7f8f9; --tocsidebar-shadow: rgba(0,0,0,.1); --tocsidebar-heading-text: hsla(203,20%,40%,.7); --toclink-text: var(--text); --toclink-underline: #3980b5; --toclink-visited-text: var(--toclink-text); --toclink-visited-underline: #054572; --heading-text: #005a9c; --hr-text: var(--text); --algo-border: #def; --del-text: red; --del-bg: transparent; --ins-text: #080; --ins-bg: transparent; --a-normal-text: #034575; --a-normal-underline: #bbb; --a-visited-text: var(--a-normal-text); --a-visited-underline: #707070; --a-hover-bg: rgba(75%, 75%, 75%, .25); --a-active-text: #c00; --a-active-underline: #c00; --blockquote-border: silver; --blockquote-bg: transparent; --blockquote-text: currentcolor; --issue-border: #e05252; --issue-bg: #fbe9e9; --issue-text: var(--text); --issueheading-text: #831616; --example-border: #e0cb52; --example-bg: #fcfaee; --example-text: var(--text); --exampleheading-text: #574b0f; --note-border: #52e052; --note-bg: #e9fbe9; --note-text: var(--text); --noteheading-text: hsl(120, 70%, 30%); --notesummary-underline: silver; --assertion-border: #aaa; --assertion-bg: #eee; --assertion-text: black; --advisement-border: orange; --advisement-bg: #fec; --advisement-text: var(--text); --advisementheading-text: #b35f00; --warning-border: red; --warning-bg: hsla(40,100%,50%,0.95); --warning-text: var(--text); --amendment-border: #330099; --amendment-bg: #F5F0FF; --amendment-text: var(--text); --amendmentheading-text: #220066; --def-border: #8ccbf2; --def-bg: #def; --def-text: var(--text); --defrow-border: #bbd7e9; --datacell-border: silver; --indexinfo-text: #707070; --indextable-hover-text: black; --indextable-hover-bg: #f7f8f9; --outdatedspec-bg: rgba(0, 0, 0, .5); --outdatedspec-text: black; --outdated-bg: maroon; --outdated-text: white; --outdated-shadow: red; --editedrec-bg: darkorange; } @media (prefers-color-scheme: dark) { :root { --text: #ddd; --bg: black; --unofficial-watermark: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' width='400' height='400'%3E%3Cg fill='%23100808' transform='translate(200 200) rotate(-45) translate(-200 -200)' stroke='%23100808' stroke-width='3'%3E%3Ctext x='50%25' y='220' style='font: bold 70px sans-serif; text-anchor: middle; letter-spacing: 6px;'%3EUNOFFICIAL%3C/text%3E%3Ctext x='50%25' y='305' style='font: bold 70px sans-serif; text-anchor: middle; letter-spacing: 6px;'%3EDRAFT%3C/text%3E%3C/g%3E%3C/svg%3E"); --logo-bg: #1a5e9a; --logo-active-bg: #c00; --logo-text: white; --tocnav-normal-text: #999; --tocnav-normal-bg: var(--bg); --tocnav-hover-text: var(--tocnav-normal-text); --tocnav-hover-bg: #080808; --tocnav-active-text: #f44; --tocnav-active-bg: var(--tocnav-normal-bg); --tocsidebar-text: var(--text); --tocsidebar-bg: #080808; --tocsidebar-shadow: rgba(255,255,255,.1); --tocsidebar-heading-text: hsla(203,20%,40%,.7); --toclink-text: var(--text); --toclink-underline: #6af; --toclink-visited-text: var(--toclink-text); --toclink-visited-underline: #054572; --heading-text: #8af; --hr-text: var(--text); --algo-border: #456; --del-text: #f44; --del-bg: transparent; --ins-text: #4a4; --ins-bg: transparent; --a-normal-text: #6af; --a-normal-underline: #555; --a-visited-text: var(--a-normal-text); --a-visited-underline: var(--a-normal-underline); --a-hover-bg: rgba(25%, 25%, 25%, .2); --a-active-text: #f44; --a-active-underline: var(--a-active-text); --borderedblock-bg: rgba(255, 255, 255, .05); --blockquote-border: silver; --blockquote-bg: var(--borderedblock-bg); --blockquote-text: currentcolor; --issue-border: #e05252; --issue-bg: var(--borderedblock-bg); --issue-text: var(--text); --issueheading-text: hsl(0deg, 70%, 70%); --example-border: hsl(50deg, 90%, 60%); --example-bg: var(--borderedblock-bg); --example-text: var(--text); --exampleheading-text: hsl(50deg, 70%, 70%); --note-border: hsl(120deg, 100%, 35%); --note-bg: var(--borderedblock-bg); --note-text: var(--text); --noteheading-text: hsl(120, 70%, 70%); --notesummary-underline: silver; --assertion-border: #444; --assertion-bg: var(--borderedblock-bg); --assertion-text: var(--text); --advisement-border: orange; --advisement-bg: #222218; --advisement-text: var(--text); --advisementheading-text: #f84; --warning-border: red; --warning-bg: hsla(40,100%,20%,0.95); --warning-text: var(--text); --amendment-border: #330099; --amendment-bg: #080010; --amendment-text: var(--text); --amendmentheading-text: #cc00ff; --def-border: #8ccbf2; --def-bg: #080818; --def-text: var(--text); --defrow-border: #136; --datacell-border: silver; --indexinfo-text: #aaa; --indextable-hover-text: var(--text); --indextable-hover-bg: #181818; --outdatedspec-bg: rgba(255, 255, 255, .5); --outdatedspec-text: black; --outdated-bg: maroon; --outdated-text: white; --outdated-shadow: red; --editedrec-bg: darkorange; } /* In case a transparent-bg image doesn't expect to be on a dark bg, which is quite common in practice... */ img { background: white; } } </style> <style>/* Boilerplate: style-counters */ body { counter-reset: example figure issue; } .issue { counter-increment: issue; } .issue:not(.no-marker)::before { content: "Issue " counter(issue); } .example { counter-increment: example; } .example:not(.no-marker)::before { content: "Example " counter(example); } .invalid.example:not(.no-marker)::before, .illegal.example:not(.no-marker)::before { content: "Invalid Example" counter(example); } figcaption { counter-increment: figure; } figcaption:not(.no-marker)::before { content: "Figure " counter(figure) " "; } </style> <style>/* Boilerplate: style-dfn-panel */ :root { --dfnpanel-bg: #ddd; --dfnpanel-text: var(--text); } @media (prefers-color-scheme: dark) { :root { --dfnpanel-bg: #222; --dfnpanel-text: var(--text); } } .dfn-panel { position: absolute; z-index: 35; width: 20em; width: 300px; height: auto; max-height: 500px; overflow: auto; padding: 0.5em 0.75em; font: small Helvetica Neue, sans-serif, Droid Sans Fallback; background: var(--dfnpanel-bg); color: var(--dfnpanel-text); border: outset 0.2em; white-space: normal; /* in case it's moved into a pre */ } .dfn-panel:not(.on) { display: none; } .dfn-panel * { margin: 0; padding: 0; text-indent: 0; } .dfn-panel > b { display: block; } .dfn-panel a { color: var(--dfnpanel-text); } .dfn-panel a:not(:hover) { text-decoration: none !important; border-bottom: none !important; } .dfn-panel > b + b { margin-top: 0.25em; } .dfn-panel ul { padding: 0 0 0 1em; list-style: none; } .dfn-panel li a { white-space: pre; display: inline-block; max-width: calc(300px - 1.5em - 1em); overflow: hidden; text-overflow: ellipsis; } .dfn-panel.activated { display: inline-block; position: fixed; left: .5em; bottom: 2em; margin: 0 auto; max-width: calc(100vw - 1.5em - .4em - .5em); max-height: 30vh; } .dfn-paneled[role="button"] { cursor: pointer; } </style> <style>/* Boilerplate: style-issues */ a[href].issue-return { float: right; float: inline-end; color: var(--issueheading-text); font-weight: bold; text-decoration: none; } </style> <style>/* Boilerplate: style-md-lists */ /* This is a weird hack for me not yet following the commonmark spec regarding paragraph and lists. */ [data-md] > :first-child { margin-top: 0; } [data-md] > :last-child { margin-bottom: 0; } </style> <style>/* Boilerplate: style-selflinks */ :root { --selflink-text: white; --selflink-bg: gray; --selflink-hover-text: black; } .heading, .issue, .note, .example, li, dt { position: relative; } a.self-link { position: absolute; top: 0; left: calc(-1 * (3.5rem - 26px)); width: calc(3.5rem - 26px); height: 2em; text-align: center; border: none; transition: opacity .2s; opacity: .5; } a.self-link:hover { opacity: 1; } .heading > a.self-link { font-size: 83%; } .example > a.self-link, .note > a.self-link, .issue > a.self-link { /* These blocks are overflow:auto, so positioning outside doesn't work. */ left: auto; right: 0; } li > a.self-link { left: calc(-1 * (3.5rem - 26px) - 2em); } dfn > a.self-link { top: auto; left: auto; opacity: 0; width: 1.5em; height: 1.5em; background: var(--selflink-bg); color: var(--selflink-text); font-style: normal; transition: opacity .2s, background-color .2s, color .2s; } dfn:hover > a.self-link { opacity: 1; } dfn > a.self-link:hover { color: var(--selflink-hover-text); } a.self-link::before { content: "¶"; } .heading > a.self-link::before { content: "§"; } dfn > a.self-link::before { content: "#"; } </style> <style>/* Boilerplate: style-syntax-highlighting */ code.highlight { padding: .1em; border-radius: .3em; } pre.highlight, pre > code.highlight { display: block; padding: 1em; margin: .5em 0; overflow: auto; border-radius: 0; } .highlight:not(.idl) { background: rgba(0, 0, 0, .03); } c-[a] { color: #990055 } /* Keyword.Declaration */ c-[b] { color: #990055 } /* Keyword.Type */ c-[c] { color: #708090 } /* Comment */ c-[d] { color: #708090 } /* Comment.Multiline */ c-[e] { color: #0077aa } /* Name.Attribute */ c-[f] { color: #669900 } /* Name.Tag */ c-[g] { color: #222222 } /* Name.Variable */ c-[k] { color: #990055 } /* Keyword */ c-[l] { color: #000000 } /* Literal */ c-[m] { color: #000000 } /* Literal.Number */ c-[n] { color: #0077aa } /* Name */ c-[o] { color: #999999 } /* Operator */ c-[p] { color: #999999 } /* Punctuation */ c-[s] { color: #a67f59 } /* Literal.String */ c-[t] { color: #a67f59 } /* Literal.String.Single */ c-[u] { color: #a67f59 } /* Literal.String.Double */ c-[cp] { color: #708090 } /* Comment.Preproc */ c-[c1] { color: #708090 } /* Comment.Single */ c-[cs] { color: #708090 } /* Comment.Special */ c-[kc] { color: #990055 } /* Keyword.Constant */ c-[kn] { color: #990055 } /* Keyword.Namespace */ c-[kp] { color: #990055 } /* Keyword.Pseudo */ c-[kr] { color: #990055 } /* Keyword.Reserved */ c-[ld] { color: #000000 } /* Literal.Date */ c-[nc] { color: #0077aa } /* Name.Class */ c-[no] { color: #0077aa } /* Name.Constant */ c-[nd] { color: #0077aa } /* Name.Decorator */ c-[ni] { color: #0077aa } /* Name.Entity */ c-[ne] { color: #0077aa } /* Name.Exception */ c-[nf] { color: #0077aa } /* Name.Function */ c-[nl] { color: #0077aa } /* Name.Label */ c-[nn] { color: #0077aa } /* Name.Namespace */ c-[py] { color: #0077aa } /* Name.Property */ c-[ow] { color: #999999 } /* Operator.Word */ c-[mb] { color: #000000 } /* Literal.Number.Bin */ c-[mf] { color: #000000 } /* Literal.Number.Float */ c-[mh] { color: #000000 } /* Literal.Number.Hex */ c-[mi] { color: #000000 } /* Literal.Number.Integer */ c-[mo] { color: #000000 } /* Literal.Number.Oct */ c-[sb] { color: #a67f59 } /* Literal.String.Backtick */ c-[sc] { color: #a67f59 } /* Literal.String.Char */ c-[sd] { color: #a67f59 } /* Literal.String.Doc */ c-[se] { color: #a67f59 } /* Literal.String.Escape */ c-[sh] { color: #a67f59 } /* Literal.String.Heredoc */ c-[si] { color: #a67f59 } /* Literal.String.Interpol */ c-[sx] { color: #a67f59 } /* Literal.String.Other */ c-[sr] { color: #a67f59 } /* Literal.String.Regex */ c-[ss] { color: #a67f59 } /* Literal.String.Symbol */ c-[vc] { color: #0077aa } /* Name.Variable.Class */ c-[vg] { color: #0077aa } /* Name.Variable.Global */ c-[vi] { color: #0077aa } /* Name.Variable.Instance */ c-[il] { color: #000000 } /* Literal.Number.Integer.Long */ @media (prefers-color-scheme: dark) { .highlight:not(.idl) { background: rgba(255, 255, 255, .05); } c-[a] { color: #d33682 } /* Keyword.Declaration */ c-[b] { color: #d33682 } /* Keyword.Type */ c-[c] { color: #2aa198 } /* Comment */ c-[d] { color: #2aa198 } /* Comment.Multiline */ c-[e] { color: #268bd2 } /* Name.Attribute */ c-[f] { color: #b58900 } /* Name.Tag */ c-[g] { color: #cb4b16 } /* Name.Variable */ c-[k] { color: #d33682 } /* Keyword */ c-[l] { color: #657b83 } /* Literal */ c-[m] { color: #657b83 } /* Literal.Number */ c-[n] { color: #268bd2 } /* Name */ c-[o] { color: #657b83 } /* Operator */ c-[p] { color: #657b83 } /* Punctuation */ c-[s] { color: #6c71c4 } /* Literal.String */ c-[t] { color: #6c71c4 } /* Literal.String.Single */ c-[u] { color: #6c71c4 } /* Literal.String.Double */ c-[ch] { color: #2aa198 } /* Comment.Hashbang */ c-[cp] { color: #2aa198 } /* Comment.Preproc */ c-[cpf] { color: #2aa198 } /* Comment.PreprocFile */ c-[c1] { color: #2aa198 } /* Comment.Single */ c-[cs] { color: #2aa198 } /* Comment.Special */ c-[kc] { color: #d33682 } /* Keyword.Constant */ c-[kn] { color: #d33682 } /* Keyword.Namespace */ c-[kp] { color: #d33682 } /* Keyword.Pseudo */ c-[kr] { color: #d33682 } /* Keyword.Reserved */ c-[ld] { color: #657b83 } /* Literal.Date */ c-[nc] { color: #268bd2 } /* Name.Class */ c-[no] { color: #268bd2 } /* Name.Constant */ c-[nd] { color: #268bd2 } /* Name.Decorator */ c-[ni] { color: #268bd2 } /* Name.Entity */ c-[ne] { color: #268bd2 } /* Name.Exception */ c-[nf] { color: #268bd2 } /* Name.Function */ c-[nl] { color: #268bd2 } /* Name.Label */ c-[nn] { color: #268bd2 } /* Name.Namespace */ c-[py] { color: #268bd2 } /* Name.Property */ c-[ow] { color: #657b83 } /* Operator.Word */ c-[mb] { color: #657b83 } /* Literal.Number.Bin */ c-[mf] { color: #657b83 } /* Literal.Number.Float */ c-[mh] { color: #657b83 } /* Literal.Number.Hex */ c-[mi] { color: #657b83 } /* Literal.Number.Integer */ c-[mo] { color: #657b83 } /* Literal.Number.Oct */ c-[sa] { color: #6c71c4 } /* Literal.String.Affix */ c-[sb] { color: #6c71c4 } /* Literal.String.Backtick */ c-[sc] { color: #6c71c4 } /* Literal.String.Char */ c-[dl] { color: #6c71c4 } /* Literal.String.Delimiter */ c-[sd] { color: #6c71c4 } /* Literal.String.Doc */ c-[se] { color: #6c71c4 } /* Literal.String.Escape */ c-[sh] { color: #6c71c4 } /* Literal.String.Heredoc */ c-[si] { color: #6c71c4 } /* Literal.String.Interpol */ c-[sx] { color: #6c71c4 } /* Literal.String.Other */ c-[sr] { color: #6c71c4 } /* Literal.String.Regex */ c-[ss] { color: #6c71c4 } /* Literal.String.Symbol */ c-[fm] { color: #268bd2 } /* Name.Function.Magic */ c-[vc] { color: #cb4b16 } /* Name.Variable.Class */ c-[vg] { color: #cb4b16 } /* Name.Variable.Global */ c-[vi] { color: #cb4b16 } /* Name.Variable.Instance */ c-[vm] { color: #cb4b16 } /* Name.Variable.Magic */ c-[il] { color: #657b83 } /* Literal.Number.Integer.Long */ } </style> <link href="https://www.w3.org/StyleSheets/TR/2021/W3C-WD" rel="stylesheet"> <body class="h-entry"> <div class="head"> <a class="logo" href="https://www.w3.org/"> <img alt="W3C" height="48" src="https://www.w3.org/StyleSheets/TR/2021/logos/W3C" width="72"> </a> <h1 class="p-name no-ref" id="title">Accessibility Conformance Testing (ACT) Rules Format 1.1</h1> <a href="https://www.w3.org/standards/types#FPWD">W3C First Public Working Draft</a>, <time class="dt-updated" datetime="2024-06-18">18 June 2024</time> <details open> <summary>More details about this document</summary> <div data-fill-with="spec-metadata"> <dl> <dt>This version: <dd><a class="u-url" href="https://www.w3.org/TR/2024/WD-act-rules-format-1.1-20240618/">https://www.w3.org/TR/2024/WD-act-rules-format-1.1-20240618/</a> <dt>Latest published version: <dd><a href="https://www.w3.org/TR/act-rules-format-1.1/">https://www.w3.org/TR/act-rules-format-1.1/</a> <dt>Editor's Draft: <dd><a href="https://w3c.github.io/wcag-act/act-rules-format.html">https://w3c.github.io/wcag-act/act-rules-format.html</a> <dt>Previous Versions: <dd><a href="https://www.w3.org/TR/act-rules-format-1.0/" rel="prev">https://www.w3.org/TR/act-rules-format-1.0/</a> <dt>History: <dd><a class="u-url" href="https://www.w3.org/standards/history/act-rules-format-1.1/">https://www.w3.org/standards/history/act-rules-format-1.1/</a> <dt>Feedback: <dd><a href="https://github.com/w3c/wcag-act/issues/">GitHub</a> <dt class="editor">Editors: <dd class="editor p-author h-card vcard" data-editor-id="43334">Wilco Fiers (Deque Systems) <dd class="editor p-author h-card vcard" data-editor-id="107871">Kathy Eng (US Access Board) <dd class="editor p-author h-card vcard" data-editor-id="105887">Trevor Bostic (MITRE Corp.) <dd class="editor p-author h-card vcard" data-editor-id="114058">Daniel Montalvo (W3C) <dt class="editor">Former Editors: <dd class="editor p-author h-card vcard">Maureen Kraft (IBM Corp.) <dd class="editor p-author h-card vcard">Mary Jo Mueller (IBM Corp.) <dd class="editor p-author h-card vcard">Shadi Abou-Zahra (W3C) </dl> </div> </details> <div data-fill-with="warning"></div> <a href="https://www.w3.org/policies/#copyright">Copyright</a> © 2024 <a href="https://www.w3.org/">World Wide Web Consortium</a>. <abbr title="World Wide Web Consortium">W3C</abbr>® <a href="https://www.w3.org/policies/#Legal_Disclaimer">liability</a>, <a href="https://www.w3.org/policies/#W3C_Trademarks">trademark</a> and <a href="https://www.w3.org/copyright/document-license/">document use</a> rules apply. <hr title="Separator for header"> </div> <div class="p-summary" data-fill-with="abstract"> <h2 class="no-num no-toc no-ref heading settled" id="abstract">Abstract</h2> The Accessibility Conformance Testing (ACT) Rules Format 1.1 defines a format for writing accessibility test rules. These test rules can be used for developing automated testing tools and manual testing methodologies. It provides a common format that allows any party involved in accessibility testing to document and share their testing procedures in a robust and understandable manner. This enables transparency and harmonization of testing methods, including methods implemented by accessibility test tools. </div> <h2 class="no-num no-toc no-ref heading settled" id="sotd">Status of this document</h2> <div data-fill-with="status"> This section describes the status of this document at the time of its publication. A list of current <abbr title="World Wide Web Consortium">W3C</abbr> publications and the latest revision of this technical report can be found in the <a href="https://www.w3.org/TR/"><abbr title="World Wide Web Consortium">W3C</abbr> technical reports index</a> at https://www.w3.org/TR/. This is a First Public Working Draft of Accessibility Conformance Testing (ACT) Rules Format 1.1 by the <a href="https://www.w3.org/groups/wg/ag/">Accessibility Guidelines Working Group</a>. ACT-Rules Format 1.1 is a complete draft, addressing all of the <a href="https://w3c.github.io/wcag-act/act-fr-reqs.html">requirements</a> the ACT Task Force believes are important to cover when writing rules. The ACT-Rules Format is based on rules developed by the <a href="https://act-rules.github.io/">ACT-Rules Community Group</a>. For this publication, the Accessibility Conformance Testing Task Force particularly seeks feedback on the items detailed in the <a href="#Change_History">Change log</a>. To comment, <a href="https://github.com/w3c/wcag-act/issues/new">file an issue in the <abbr title="World Wide Web Consortium">W3C</abbr> ACT GitHub repository</a>. It is free to create a GitHub account to file issues. If filing issues in GitHub is not feasible, send email to <a href="mailto:public-wcag-act-comments@w3.org?subject=ACT%20Format%201.1%20public%20comment">public-wcag-act-comments@w3.org</a> (<a href="https://lists.w3.org/Archives/Public/public-wcag-act-comments/">comment archive</a>). Comments are requested by 18 August 2024. In-progress updates to the document may be viewed in the <a href="https://w3c.github.io/wcag-act/act-rules-format.html">publicly visible editors' draft</a>. This document was published by the <a href="https://www.w3.org/groups/wg/ag/">Accessibility Guidelines Working Group</a> as a First Public Working Draft using the <a href="https://www.w3.org/2023/Process-20231103/#recs-and-notes">Recommendation track</a>. This document is intended to become a <abbr title="World Wide Web Consortium">W3C</abbr> Recommendation. Publication as a First Public Working Draft does not imply endorsement by <abbr title="World Wide Web Consortium">W3C</abbr> and its Members. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress. This document was produced by a group operating under the <a href="https://www.w3.org/Consortium/Patent-Policy/">W3C Patent Policy</a>. W3C maintains a <a href="https://www.w3.org/groups/wg/ag/ipr/" rel="disclosure">public list of any patent disclosures</a> made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains <a href="https://www.w3.org/Consortium/Patent-Policy/#def-essential">Essential Claim(s)</a> must disclose the information in accordance with <a href="https://www.w3.org/Consortium/Patent-Policy/#sec-Disclosure">section 6 of the W3C Patent Policy</a>. This document is governed by the <a href="https://www.w3.org/2023/Process-20231103/" id="w3c_process_revision">03 November 2023 W3C Process Document</a>. </div> <div data-fill-with="at-risk"></div> <nav data-fill-with="table-of-contents" id="toc"> <h2 class="no-num no-toc no-ref" id="contents">Table of Contents</h2> <ol class="toc" role="directory"> <li><a href="#intro">1 Introduction</a> <li><a href="#scope">2 Scope</a> <li><a href="#rule-types">3 ACT Rule Types</a> <li> <a href="#act-rule-structure">4 ACT Rule Structure</a> <ol class="toc"> <li><a href="#rule-identifier">4.1 Rule Identifier</a> <li><a href="#rule-description">4.2 Rule Description</a> <li><a href="#rule-type">4.3 Rule Type</a> <li> <a href="#accessibility-requirements-mapping">4.4 Accessibility Requirements Mapping</a> <ol class="toc"> <li> <a href="#outcome-mapping">4.4.1 Outcome Mapping</a> <ol class="toc"> <li><a href="#conformance-requirements">4.4.1.1 Conformance Requirements</a> <li><a href="#secondary-requirements">4.4.1.2 Secondary Requirements</a> </ol> <li><a href="#mapping-outside-wcag">4.4.2 Mapping Outside WCAG</a> <li><a href="#rules-without-accessibility-requirements">4.4.3 Rules Without Accessibility Requirements</a> <li><a href="#external-accessibility-requirements-mapping">4.4.4 External Accessibility Requirements Mapping</a> </ol> <li> <a href="#input">4.5 Rule Input</a> <ol class="toc"> <li><a href="#input-aspects">4.5.1 Input Aspects (Atomic rules only)</a> <li><a href="#input-rules">4.5.2 Input Rules (Composite rules only)</a> </ol> <li> <a href="#applicability">4.6 Applicability</a> <ol class="toc"> <li> <a href="#applicability-atomic">4.6.1 Applicability for Atomic Rules</a> <ol class="toc"> <li><a href="#applicability-type-designation-atomic-optional">4.6.1.1 Applicability Type Designation (optional) {#applicability-type-designation-atomic-optional}</a> </ol> <li> <a href="#applicability-composite">4.6.2 Applicability for Composite Rules</a> <ol class="toc"> <li><a href="#applicability-type-designation-composite-optional">4.6.2.1 Applicability Type Designation (optional) {#applicability-type-designation-composite-optional}</a> </ol> </ol> <li> <a href="#expectations">4.7 Expectations</a> <ol class="toc"> <li><a href="#expectations-atomic">4.7.1 Expectations for Atomic Rules</a> <li><a href="#expectations-composite">4.7.2 Expectations for Composite Rules</a> </ol> <li> <a href="#background">4.8 Background</a> <ol class="toc"> <li><a href="#assumptions">4.8.1 Assumptions</a> <li><a href="#accessibility-support">4.8.2 Accessibility Support</a> <li><a href="#related-rules">4.8.3 Related Rules (optional)</a> <li><a href="#other-resources">4.8.4 Other Resources (optional)</a> </ol> <li><a href="#test-cases">4.9 Test Cases</a> <li><a href="#rule-versions">4.10 Rule Versions</a> <li><a href="#act-rules-format-version">4.11 ACT Rules Format Version</a> <li><a href="#glossary">4.12 Glossary</a> <li><a href="#issues-list">4.13 Issues List (optional)</a> <li> <a href="#implementations">4.14 Implementations (optional)</a> <ol class="toc"> <li><a href="#impl-consistency">4.14.1 Consistency</a> <li><a href="#impl-partial-consistency">4.14.2 Partial Consistency</a> <li><a href="#impl-multi-check">4.14.3 Consistency with multiple checks</a> </ol> <li><a href="#acknowledgments">4.15 Acknowledgments (optional)</a> </ol> <li><a href="#rule-accuracy">5 Rule Accuracy</a> <li><a href="#harmonization">6 Harmonization</a> <li><a href="#definitions">7 Definitions</a> <li><a href="#appendix-data-example"> Appendix 1: Expressing ACT Rule results with JSON-LD and EARL</a> <li> <a href="#Acknowledgments"> Appendix 2: Acknowledgments</a> <ol class="toc"> <li><a href="#participants"> Participants of the AG WG active in the development of this document</a> <li><a href="#enabling-funders"> Enabling funders</a> </ol> <li><a href="#Change_History"> Appendix 3: Change History</a> <li> <a href="#w3c-conformance"> Conformance</a> <ol class="toc"> <li><a href="#w3c-conventions"> Document conventions</a> <li><a href="#w3c-conformant-algorithms"> Conformant Algorithms</a> </ol> <li> <a href="#index"> Index</a> <ol class="toc"> <li><a href="#index-defined-here"> Terms defined by this specification</a> </ol> <li> <a href="#references"> References</a> <ol class="toc"> <li><a href="#normative"> Normative References</a> <li><a href="#informative"> Informative References</a> </ol> </ol> </nav> <main> <h2 class="heading settled" data-level="1" id="intro">1. Introduction<a class="self-link" href="#intro"></a></h2> There are currently many test procedures and tools available which aid their users in testing web content for conformance to accessibility standards such as the <a href="https://www.w3.org/WAI/standards-guidelines/wcag/">Web Content Accessibility Guidelines</a> <a data-link-type="biblio" href="#biblio-wcag22" title="Web Content Accessibility Guidelines (WCAG) 2.2">[WCAG22]</a>. As the Web develops in both size and complexity, these procedures and tools are essential for managing the accessibility of resources available on the Web. This format is intended to enable a consistent interpretation of how to test conformance to WCAG and other <a data-link-type="dfn" href="#accessibility-requirements-document" id="ref-for-accessibility-requirements-document">accessibility requirements documents</a> and promote consistent results in accessibility testing. The rules format is designed to describe both manual accessibility tests, as well as automated tests as performed by accessibility testing tools. Documenting how to test <a data-link-type="dfn" href="#accessibility-requirement" id="ref-for-accessibility-requirement">accessibility requirements</a> will result in accessibility tests that are transparent, with test results that are reproducible. The Accessibility Conformance Testing (ACT) Rules Format defines the requirements for these test descriptions, known as Accessibility Conformance Testing Rules (ACT Rules). An ACT Rule is a plain language description of how to test a specific type of content for a specific aspect of an accessibility requirement. An ACT Rule describes what kind of content it applies to and which conditions are true about the applicable elements for them to meet all expectations of the rule. In the context of WCAG, ACT Rules test for failures in satisfying Success Criteria. Such failures are often described in <a href="https://www.w3.org/TR/WCAG22/#wcag-2-layers-of-guidance">common failures</a> documented for WCAG. ACT Rules are written for the testing process and are usually more specific than common failures. The ACT Rules Format defines the requirements and rule structure for the types of information each rule needs to include to be called an ACT Rule. The structure of the ACT rule is defined in the <a href="#act-rule-structure">ACT Rule Structure</a> section. Each ACT Rule also contains a plain language description of the type of content under test, the test to perform, and the expected result. Where the test result affects conformance, the rule documents the particular requirement being tested. The resulting outcomes from the test can be used to help determine conformance or non-conformance to the requirement. Test cases are also written as part of the ACT rule to provide a way to verify that implementations of the rule can successfully determine the expected outcomes. <h2 class="heading settled" data-level="2" id="scope">2. Scope<a class="self-link" href="#scope"></a></h2> The ACT Rules Format defined in this specification is designed for rules that can be used in testing content created using web technologies, such as <a href="https://www.w3.org/TR/html/">Hypertext Markup Language</a> <a data-link-type="biblio" href="#biblio-html" title="HTML Standard">[HTML]</a>, <a href="https://www.w3.org/TR/CSS/">Cascading Style Sheets</a> <a data-link-type="biblio" href="#biblio-css-2018" title="CSS Snapshot 2018">[css-2018]</a>, <a href="https://www.w3.org/WAI/standards-guidelines/aria/">Accessible Rich Internet Applications</a> <a data-link-type="biblio" href="#biblio-wai-aria" title="Accessible Rich Internet Applications (WAI-ARIA) 1.0">[WAI-ARIA]</a>, <a href="https://www.w3.org/TR/SVG/">Scalable Vector Graphics</a> <a data-link-type="biblio" href="#biblio-svg2" title="Scalable Vector Graphics (SVG) 2">[SVG2]</a>, <a href="httpss://www.idpf.org/">EPUB 3</a> <a data-link-type="biblio" href="#biblio-epub-33" title="EPUB 3.3">[epub-33]</a>, and more. The ACT Rules Format is designed to be technology agnostic, meaning that it can conceivably be used to describe test rules for other technologies. The ACT Rules Format can be used to describe ACT Rules dedicated to testing the <a data-link-type="dfn" href="#accessibility-requirement" id="ref-for-accessibility-requirement①">accessibility requirements</a> defined in the Web Content Accessibility Guidelines <a data-link-type="biblio" href="#biblio-wcag22" title="Web Content Accessibility Guidelines (WCAG) 2.2">[WCAG22]</a>, which are specifically designed for web content. Other accessibility requirements applicable to web technologies can also be testable with ACT Rules. For example, ACT Rules could be developed to test the conformance of web-based user agents to the <a href="https://www.w3.org/WAI/standards-guidelines/uaag/">User Agent Accessibility Guidelines</a> <a data-link-type="biblio" href="#biblio-uaag20" title="User Agent Accessibility Guidelines (UAAG) 2.0">[UAAG20]</a>. The ACT Rules Format might not always be suitable to describe tests for other types of accessibility requirements. <h2 class="heading settled" data-level="3" id="rule-types">3. ACT Rule Types<a class="self-link" href="#rule-types"></a></h2> In accessibility, there are often different technical solutions to make the same type of content accessible. For example, there are multiple methods for giving an <code>img</code> element in HTML an accessible name. Multiple solutions could be tested in a single rule; however, such a rule tends to be quite complex, making it difficult to understand and maintain. The ACT Rules Format solves this by providing two types of rules: <ul> <li data-md> <dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="atomic-rules">Atomic rules</dfn> describe how to test a specific type of solution. It contains a precise definition of what elements, nodes or other "parts" of a <a data-link-type="dfn" href="#test-subject" id="ref-for-test-subject">test subject</a> are to be tested, and when those test targets are considered to pass or fail the rule. These rules are to be kept small and atomic. This means that atomic rules test a single "condition" and do so without using the <a data-link-type="dfn" href="#outcome" id="ref-for-outcome">outcomes</a> from other rules. <li data-md> <dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="composite-rules">Composite rules</dfn> describe how the <a data-link-type="dfn" href="#outcome" id="ref-for-outcome①">outcomes</a> of multiple <a data-link-type="dfn" href="#atomic-rules" id="ref-for-atomic-rules">atomic rules</a> can be combined into a single outcome for each <a data-link-type="dfn" href="#test-target" id="ref-for-test-target">test target</a>. A composite rule can have multiple "conditions", each of these tested in a separate atomic rule. The logic in the composite rule describes how any one of these satisfying conditions, or some combination of them, is used to determine a single outcome. </ul> Composite rules cannot contain other composite rules. Any time a nested composite rule would be needed, all of the relevant atomic rules can be combined directly into the new composite rule. <aside class="example" id="example-73f36a1c"> <a class="self-link" href="#example-73f36a1c"></a> <header>Example of using multiple input rules in a composite rule:</header> <blockquote> Each HTML <code>video</code> element meets all expectations from at least one of the following rules: <ul> <li>Video elements have a transcript <li>Video elements have an audio description <li>Video elements have a description track </ul> </blockquote> </aside> Not all atomic rules have to be part of a composite rule. Composite rules are used when the <a data-link-type="dfn" href="#outcome" id="ref-for-outcome②">outcomes</a> of multiple atomic rules need to be combined to determine if a <a data-link-type="dfn" href="#test-subject" id="ref-for-test-subject①">test subject</a> does not satisfy an <a data-link-type="dfn" href="#accessibility-requirement" id="ref-for-accessibility-requirement②">accessibility requirement</a>. The separation between atomic rules and composite rules creates a division of responsibilities. Atomic rules test if web content is correctly implemented in a particular solution. Composite rules can test if a combination of <a data-link-type="dfn" href="#outcome" id="ref-for-outcome③">outcomes</a> from other atomic rules satisfy the accessibility requirement, in part or as a whole. <h2 class="heading settled" data-level="4" id="act-rule-structure">4. ACT Rule Structure<a class="self-link" href="#act-rule-structure"></a></h2> An ACT Rule must consist of at least the following items: <ul> <li data-md> <dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="descriptive-title">Descriptive Title</dfn> <li data-md> <a href="#rule-identifier">Rule Identifier</a> <li data-md> <a href="#rule-description">Rule Description</a> <li data-md> <a href="#rule-type">Rule Type</a> <li data-md> <a href="#accessibility-requirements-mapping">Accessibility Requirements Mapping</a> <li data-md> <a href="#input">Rule Input</a>, which is one of the following: <ul> <li data-md> <a href="#input-aspects">Input Aspects</a> (for atomic rules) OR <li data-md> <a href="#input-rules">Input Rules</a> (for composite rules) </ul> <li data-md> <a href="#applicability">Applicability</a> <li data-md> <a href="#expectations">Expectations</a> <li data-md> <a href="#background">Background</a> <ul> <li data-md> <a href="#assumptions">Assumptions</a> <li data-md> <a href="#accessibility-support">Accessibility Support</a> <li data-md> <a href="#related-rules">Related Rules (optional)</a> <li data-md> <a href="#other-resources">Other Resources (optional)</a> </ul> <li data-md> <a href="#test-cases">Test Cases</a> <li data-md> <a href="#rule-versions">Rule Versions</a> <li data-md> <a href="#act-rules-format-version">ACT Rules Format Version</a> <li data-md> <a href="#glossary">Glossary</a> </ul> An ACT Rule MAY also contain: <ul> <li data-md> <a href="#related-rules">Related Rules</a> (optional) under Background <li data-md> <a href="#other-resources">Other Resources</a> (optional) under Background <li data-md> <a href="#issues-list">Issues List</a> (optional) <li data-md> <a href="#implementations">Implementations</a> (optional) <li data-md> <a href="#acknowledgments">Acknowledgments</a> (optional) </ul> The ACT Rules format does not prescribe what format ACT Rules can be written in (e.g. HTML, DOCX, PDF, etc.). However, ACT Rules must be written in a document that conforms to the Web Content Accessibility Guidelines <a data-link-type="biblio" href="#biblio-wcag22" title="Web Content Accessibility Guidelines (WCAG) 2.2">[WCAG22]</a> or a comparable accessibility standard. This ensures that ACT Rules are accessible to people with disabilities. ACT Rule <a href="#test-cases">test cases</a> are allowed to contain inaccessible content. If any test case contains accessibility issues listed in <a href="https://www.w3.org/TR/WCAG22/#cc5">WCAG 2.2 Section 5.2.5 Non-Interference</a>, users must be warned of this in advance. In addition to supporting people with disabilities, using an accessible format also makes internationalization of ACT Rules easier. <h3 class="heading settled" data-level="4.1" id="rule-identifier">4.1. Rule Identifier<a class="self-link" href="#rule-identifier"></a></h3> An ACT Rule must have an identifier. This identifier must be unique when the rule is part of a ruleset. The identifier can be any text, such as plain text, URL, or a database identifier. <aside class="example" id="example-8adf6793"> <a class="self-link" href="#example-8adf6793"></a> <header>Example of identifiers that are also used as filenames; They include a technology directory, followed by a handle that includes an element name or attribute:</header> <blockquote> <ul> <li>html+svg/video-alternative <li>html+svg/meta-no-refresh <li>html+svg/unique-id </ul> </blockquote> </aside> In addition to the identifier, each new release of an ACT Rule must be versioned with either a date or a number. A reference to the previous version of that rule must be available. The identifier must not be changed when the rule is updated. For substantial changes, a new rule should be created with a new identifier, and the old rule should be deprecated. <aside class="example" id="example-c6a27e25"> <a class="self-link" href="#example-c6a27e25"></a> <header>Example situation of updating a rule:</header> <blockquote> When updating a rule that is about buttons, to now also be about links, menu items and tabs, the buttons rule is deprecated. As a replacement, a new rule is created that is applicable to all those elements. </blockquote> </aside> <h3 class="heading settled" data-level="4.2" id="rule-description">4.2. Rule Description<a class="self-link" href="#rule-description"></a></h3> An ACT Rule must have a description that is in plain language which provides a brief explanation of what the rule does. <aside class="example" id="example-5275cb2a"> <a class="self-link" href="#example-5275cb2a"></a> <header>Example of a rule description:</header> <blockquote> This rule checks that the HTML page has a title </blockquote> </aside> <h3 class="heading settled" data-level="4.3" id="rule-type">4.3. Rule Type<a class="self-link" href="#rule-type"></a></h3> An ACT Rule must have a rule type which is one of the following: <ul> <li>Atomic rule <li>Composite rule </ul> Refer to the <a href="#rule-types">Rule Type</a> section for detailed definitions of the rule types. <h3 class="heading settled" data-level="4.4" id="accessibility-requirements-mapping">4.4. Accessibility Requirements Mapping<a class="self-link" href="#accessibility-requirements-mapping"></a></h3> When an ACT Rule is designed to test conformance to one or more <a data-link-type="dfn" href="#accessibility-requirements-document" id="ref-for-accessibility-requirements-document①">Accessibility requirements documents</a>, the rule must list all <a data-link-type="dfn" href="#accessibility-requirement" id="ref-for-accessibility-requirement③">accessibility requirements</a> from those documents that are not satisfied when one or more of the <a data-link-type="dfn" href="#outcome" id="ref-for-outcome④">outcomes</a> of the rule is <code>failed</code>. The rule may list accessibility requirements that could be not satisfied when the rule outcome is failed. There are two types of accessibility requirements: <ul> <li data-md> <a href="#conformance-requirements">Conformance Requirements</a> <li data-md> <a href="#secondary-requirements">Secondary Requirements</a> </ul> Each <a data-link-type="dfn" href="#accessibility-requirement" id="ref-for-accessibility-requirement④">accessibility requirement</a> in the mapping must include the following: <ol> <li data-md> either the name, title, identifier or summary of the accessibility requirement, and <li data-md> the name of the <a data-link-type="dfn" href="#accessibility-requirements-document" id="ref-for-accessibility-requirements-document②">accessibility requirements document</a>, and <li data-md> a link or reference to the <a data-link-type="dfn" href="#accessibility-requirements-document" id="ref-for-accessibility-requirements-document③">accessibility requirements document</a> if one exists, and <li data-md> the conformance level associated with the accessibility requirement, if one exists, and <li data-md> whether the requirement is a conformance requirement or a secondary requirement. </ol> <h4 class="heading settled" data-level="4.4.1" id="outcome-mapping">4.4.1. Outcome Mapping<a class="self-link" href="#outcome-mapping"></a></h4> For each conformance requirement in the mapping, an ACT Rule must indicate what the <a data-link-type="dfn" href="#outcome" id="ref-for-outcome⑤">outcomes</a> of the rule mean for satisfying an accessibility requirement for that <a data-link-type="dfn" href="#test-subject" id="ref-for-test-subject②">test subject</a>. <h5 class="heading settled" data-level="4.4.1.1" id="conformance-requirements">4.4.1.1. <dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="conformance-requirements①">Conformance Requirements</dfn><a class="self-link" href="#conformance-requirements"></a></h5> When a rule is designed to test a specific accessibility requirement, the accessibility requirement is mapped as a Conformance Requirement when both of the following conditions are true: <ul> <li data-md> Failed Outcomes: When one or more of the outcomes for a test subject is <code>failed</code>, the accessibility requirement is <dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="not-satisfied">not satisfied</dfn> for the test subject, and <li data-md> Passed or Inapplicable Outcomes: When all of the outcomes are <code>passed</code> or <code>inapplicable</code> for a test subject, the accessibility requirement could be <dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="satisfied">satisfied</dfn> or <dfn data-dfn-type="dfn" data-noexport id="further-testing-is-needed">further testing is needed<a class="self-link" href="#further-testing-is-needed"></a></dfn> for the test subject. </ul> Rules that can be used to determine if an accessibility requirement is satisfied are called <dfn data-dfn-type="dfn" data-noexport id="satisfying-tests">satisfying tests<a class="self-link" href="#satisfying-tests"></a></dfn>. <ul> <li data-md> Passed: When all of the outcomes are <code>passed</code>, the accessibility requirement is <a data-link-type="dfn" href="#satisfied" id="ref-for-satisfied">satisfied</a> for the test subject. </ul> <div class="note" role="note"> Note: In the <a href="https://www.w3.org/WAI/standards-guidelines/wcag/">Web Content Accessibility Guidelines</a> <a data-link-type="biblio" href="#biblio-wcag22" title="Web Content Accessibility Guidelines (WCAG) 2.2">[WCAG22]</a>, success criteria do not evaluate to <code>passed</code>, <code>failed</code> or <code>inapplicable</code>. Rather they can be satisfied (or not). (See the <a href="https://www.w3.org/TR/WCAG22/#dfn-satisfies">WCAG 2.2 definition: satisfies a success criterion</a>.) If a success criterion is not satisfied, a web page can only conform if there is a conforming alternative version, as described in <a href="https://www.w3.org/TR/WCAG22/#cc1">WCAG 2.2 Conformance Requirement 1</a>. </div> <aside class="example" id="example-0fd4e5d3"> <a class="self-link" href="#example-0fd4e5d3"></a> <header>Example accessibility requirements mapping for a rule that was designed to test if an image button has an accessible name maps success criteria 1.1.1 Non-text content and 4.1.2 Name, Role, Value as conformance requirements:</header> <blockquote> <ul> <li> <a href="https://www.w3.org/TR/WCAG22/#non-text-content">Success criterion 1.1.1: Non-text content</a> <ul> <li>Required for conformance to WCAG 2.0 and WCAG 2.2 level A and higher <li> Outcome mapping: <ul> <li>Any <code>failed</code> outcomes: not satisfied <li>All <code>passed</code> outcomes: further testing is needed <li>An <code>inapplicable</code> outcome: further testing is needed </ul> </ul> <li> <a href="https://www.w3.org/TR/WCAG22/#name-role-value">Success criterion 4.1.2: Name, Role, Value</a> <ul> <li>Required for conformance to WCAG 2.0 and WCAG 2.2 level A and higher <li> Outcome mapping: <ul> <li>Any <code>failed</code> outcomes: not satisfied <li>All <code>passed</code> outcomes: further testing is needed <li>An <code>inapplicable</code> outcome: further testing is needed </ul> </ul> </ul> </blockquote> </aside> <h5 class="heading settled" data-level="4.4.1.2" id="secondary-requirements">4.4.1.2. <dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="secondary-requirements①">Secondary Requirements</dfn><a class="self-link" href="#secondary-requirements"></a></h5> A secondary accessibility requirement is a requirement that is correlated with the rule, but for which the rule is not designed to test. The outcome of the rule impacts the result of the accessibility requirement, but the rule is not intended to test the conformance of that requirement. This correlation often results in some of the rule’s test cases not satisfying the secondary accessibility requirement. When the rule is not designed to test the accessibility requirement, or failed outcomes of the rule still require further testing for the accessibility requirement, the rule may map the accessibility requirement as Secondary. When an ACT rule maps to a Secondary requirement, it must include an explanation of why that requirement is Secondary in the Background section of the rule. When the rule is designed to test an accessibility requirement, differences in <a href="#accessibility-support">accessibility support</a> must not be a reason for that requirement to be a secondary accessibility requirement. Some scenarios when a rule will have Secondary requirements include: Scenario 1: the rule is not as strict as a requirement A rule was designed to test a minimum accessibility requirement and there exists a stricter requirement. The rule’s failed outcomes can determine that the stricter accessibility requirement is not satisfied, and the rule’s passed outcomes may not determine that the stricter requirement is satisfied. It is possible that the accessibility requirement may be not satisfied when the rule’s outcomes are passed. The stricter requirement is a Secondary requirement. <aside class="example" id="example-99498c9e"> <a class="self-link" href="#example-99498c9e"></a> <header>Example: a rule that tests if text has minimum contrast</header> <blockquote> This rule was designed to test Success Criterion 1.4.3 Contrast Minimum (AA). A stricter requirement, Success Criterion 1.4.6 Contrast (Enhanced) (Level AAA), will be not satisfied when the rule outcome is failed, and may be not satisfied when the rule outcomes are passed. This rule’s mapping: <ul> <li>Conformance Requirement: Success Criterion 1.4.3 Contrast (Minimum) <li>Secondary Requirement: Success Criterion 1.4.6 Contrast (Enhanced) <ul> <li>Explanation: This success criterion is more strict than this rule. This is because this criterion has a higher minimum contrast. Some of the passed examples do not satisfy this success criterion. </ul> </ul> </blockquote> </aside> Scenario 2: the rule is stricter than a requirement A rule was designed to test a specific solution for an accessibility requirement, but the requirement can be satisfied by other solutions that are not included in the rule. In this scenario, the rule’s failed outcomes cannot determine that an accessibility requirement is not satisfied because further testing is needed. The rule’s passed outcomes can determine that an accessibility requirement is satisfied. The accessibility requirement is a secondary requirement. <aside class="example" id="example-9c026a7f"> <a class="self-link" href="#example-9c026a7f"></a> <header>Example: a rule that tests if a focusable element has no keyboard trap via standard navigation</header> <blockquote> This rule was designed to test for a specific solution that can be used to meet Success Criterion 2.1.2: No Keyboard Trap. The rule does not test for the use of other possible solutions, such as non-standard navigation, that can satisfy the success criterion. Its failed outcomes cannot determine that the accessibility requirement is <a data-link-type="dfn" href="#not-satisfied" id="ref-for-not-satisfied">not satisfied</a>. This rule’s mapping: <ul> <li>Secondary Requirement: Success Criterion 2.1.2: No Keyboard Trap <ul> <li>Explanation: This success criterion is less strict than this rule. This is because this criterion allows for the use of non-standard keyboard navigation to exit a keyboard trap. Some of the failed examples may satisfy this success criterion. </ul> </ul> </blockquote> </aside> A rule was designed to test an accessibility requirement and there exists a less strict accessibility requirement. In this scenario, the rule’s passed outcomes can determine that the less strict requirement is satisfied, and the rule’s failed outcomes may not determine that the less strict requirement is not satisfied. It is possible that the accessibility requirement may be satisfied when the rule’s outcome is failed. The less strict accessibility requirement is a secondary requirement. <aside class="example" id="example-66ff2871"> <a class="self-link" href="#example-66ff2871"></a> <header>Example: a rule that tests Enhanced Contrast</header> <blockquote> This rule was designed to test Success Criterion 1.4.6 Contrast (Enhanced) (Level AAA). A less strict requirement, Success Criterion 1.4.3 Contrast Minimum (AA), will be satisfied when the rule outcomes are passed, and may be satisfied when the rule outcomes are failed. This rule’s mapping: <ul> <li>Conformance Requirement: Success Criterion 1.4.6 Contrast (Enhanced) <li>Secondary Requirement: Success Criterion 1.4.3 Contrast (Minimum) <ul> <li>Explanation: This success criterion is less strict than this rule. This is because this criterion has a lower minimum contrast. Some of the failed examples may satisfy this success criterion. </ul> </ul> </blockquote> </aside> Scenario 3: the rule may impact the result of the accessibility requirement, but the rule is not intended to test the conformance of that requirement A rule was designed to test an accessibility requirement and under certain conditions, other accessibility requirements apply. In this scenario, the other accessibility requirements are sometimes, but not always, satisfied or not satisfied because they are not always applicable in the rule. These other accessibility requirements are secondary requirements. <aside class="example" id="example-baa35e9f"> <a class="self-link" href="#example-baa35e9f"></a> <header>Example 1: a rule that tests if a link has a non-empty accessible name</header> <blockquote> This rule was designed to test links for accessibility requirements 4.1.2 Name, Role, Value (Level A), 2.4.4 Link Purpose (In Context) (Level A), 2.4.9 Link Purpose (Link Only) (Level AAA). In an image map, <area> elements that define regions within the map are both links and images. Testing for non-empty accessible name for <area> elements would map to another accessibility requirement 1.1.1 Non-text Content. Because the rule tests for all links and Success Criterion 1.1.1 only applies certain links, this rule’s mapping: <ul> <li>Conformance Requirement: Success Criteria 4.1.2 Name, Role, Value (Level A), 2.4.4 Link Purpose (In Context) (Level A), 2.4.9 Link Purpose (Link Only) (Level AAA) <li>Secondary Requirement: Success Criterion 1.1.1 Non-text Content <ul> <li>Explanation: This success criterion is related to this rule. This is because HTML <area> elements are both links and non-text content. Most failed examples satisfy this success criterion. </ul> </ul> </blockquote> </aside> <aside class="example" id="example-cfb70282"> <a class="self-link" href="#example-cfb70282"></a> <header>Example 2: A rule that tests that elements that have an explicit role also specify all required states and properties </header> <blockquote> This rule was designed to test a requirement of WAI-ARIA. In some cases, a failed outcome for this rule may result in WCAG 2 Success Criterion 4.1.2 Name, Role, Value being not satisfied, but not always. This rule’s mapping: <ul> <li>Conformance Requirement: WAI-ARIA 1.2 <li> Secondary Requirement: Success Criterion 4.1.2 Name, Role, Value <ul> <li>Background Section: Success Criterion 4.1.2 Name, Role, Value is mapped as a Secondary requirement because it only applies to user controls. </ul> </ul> </blockquote> </aside> <h4 class="heading settled" data-level="4.4.2" id="mapping-outside-wcag">4.4.2. Mapping Outside WCAG<a class="self-link" href="#mapping-outside-wcag"></a></h4> ACT Rules can be used to test accessibility requirements that are not part of a W3C accessibility standard, such as accessibility requirements in <a href="https://www.w3.org/TR/html/">Hypertext Markup Language</a> <a data-link-type="biblio" href="#biblio-html" title="HTML Standard">[HTML]</a>, or tests in a methodology like <a href="https://disic.github.io/rgaa_referentiel_en/criteria.html">RGAA 3 2016</a>. An ACT Rule must indicate whether or not the <a data-link-type="dfn" href="#accessibility-requirement" id="ref-for-accessibility-requirement⑤">accessibility requirement</a> it maps to is required for conformance in its <a data-link-type="dfn" href="#accessibility-requirements-document" id="ref-for-accessibility-requirements-document④">accessibility requirements document</a>. Examples of accessibility requirements that are not required for conformance are WCAG sufficient techniques, or a company style guide that includes both requirements and optional "best practices". The distinction between what is required and what is optional has to be clear. <aside class="example" id="example-18e1d695"> <a class="self-link" href="#example-18e1d695"></a> <header>Example accessibility requirements mapping for a rule that tests that each <code>img</code> element has an <code>alt</code> attribute:</header> <blockquote> <ul> <li> <a href="https://www.w3.org/TR/WCAG20-TECHS/H37.html">Technique H37: Using alt attributes on img elements</a> <ul> <li>Not required for conformance to WCAG 2.0 and WCAG 2.2 at any level <li> Outcome mapping: <ul> <li>Any <code>failed</code> outcomes: not satisfied <li>All <code>passed</code> outcomes: satisfied <li>An <code>inapplicable</code> outcome: satisfied </ul> </ul> <li> <a href="https://disic.github.io/rgaa_referentiel_en/criteria.html#test-1-1-1">RGAA 3, Test 1.1.1: Does each image have a text alternative</a> <ul> <li>Required for conformance to RGAA 3 level A and higher <li> Outcome mapping: <ul> <li>Any <code>failed</code> outcomes: not satisfied <li>All <code>passed</code> outcomes: satisfied <li>An <code>inapplicable</code> outcome: satisfied </ul> </ul> </ul> </blockquote> </aside> <h4 class="heading settled" data-level="4.4.3" id="rules-without-accessibility-requirements">4.4.3. Rules Without Accessibility Requirements<a class="self-link" href="#rules-without-accessibility-requirements"></a></h4> If the rule does not map to any <a data-link-type="dfn" href="#accessibility-requirement" id="ref-for-accessibility-requirement⑥">accessibility requirement</a>, the accessibility requirement mapping will only contain the explainer that it is not required for conformance to the <a data-link-type="dfn" href="#accessibility-requirements-document" id="ref-for-accessibility-requirements-document⑤">accessibility requirements document</a>. This is common with atomic rules used in composite rules. <aside class="example" id="example-e22fa6d9"> <a class="self-link" href="#example-e22fa6d9"></a> <header>Example of a rule that tests if <code>role=alert</code> is used to satisfy <a href="https://www.w3.org/TR/WCAG22/#status-messages">WCAG 2.2 success criterion 4.1.3 Status Messages</a>:</header> <blockquote> This rule is not required for conformance to WCAG 2.2 at any level. </blockquote> </aside> If the <code>failed</code> <a data-link-type="dfn" href="#outcome" id="ref-for-outcome⑥">outcome</a> cannot be mapped to an <a data-link-type="dfn" href="#accessibility-requirement" id="ref-for-accessibility-requirement⑦">accessibility requirement</a>, there must not be an accessibility requirement in the accessibility requirements mapping. The optional <a href="#background">Background section</a> could be used to list <a data-link-type="dfn" href="#accessibility-requirements-document" id="ref-for-accessibility-requirements-document⑥">accessibility requirements documents</a> when they are thematically related, but for which the rule is not a failure test. <h4 class="heading settled" data-level="4.4.4" id="external-accessibility-requirements-mapping">4.4.4. External Accessibility Requirements Mapping<a class="self-link" href="#external-accessibility-requirements-mapping"></a></h4> This section is non-normative. While rules are often designed for one, or possibly a small collection of <a data-link-type="dfn" href="#accessibility-requirements-document" id="ref-for-accessibility-requirements-document⑦">accessibility requirements documents</a>, it is likely that other accessibility requirements documents also map to those ACT Rules. For example, rules can be written for the <a href="https://www.w3.org/WAI/standards-guidelines/wcag/">Web Content Accessibility Guidelines</a> <a data-link-type="biblio" href="#biblio-wcag22" title="Web Content Accessibility Guidelines (WCAG) 2.2">[WCAG22]</a>, but many of those could also map to a company’s internal accessibility policy. In such a scenario, an external accessibility requirements mapping could be created. An external accessibility requirements mapping amends the accessibility requirements mapping of an ACT rule by adding mapping to a different accessibility requirements document. An external accessibility requirements mapping avoids duplication of a rule for the sole purpose of changing the mapping. <h3 class="heading settled" data-level="4.5" id="input">4.5. Rule Input<a class="self-link" href="#input"></a></h3> To evaluate content using an ACT Rule, the rule requires some information from the <a data-link-type="dfn" href="#test-subject" id="ref-for-test-subject③">test subject</a>. This is the input for the rule. What input is required is made explicit, to help testers understand what capabilities are required to use a rule. <a data-link-type="dfn" href="#atomic-rules" id="ref-for-atomic-rules①">Atomic rules</a> and <a data-link-type="dfn" href="#composite-rules" id="ref-for-composite-rules">composite rules</a> have different input. <ul> <li data-md> Atomic rules have <a href="#input-aspects">Input Aspects</a> <li data-md> Composite rules have <a href="#input-rules">Input Rules</a> </ul> <h4 class="heading settled" data-level="4.5.1" id="input-aspects">4.5.1. Input Aspects (Atomic rules only)<a class="self-link" href="#input-aspects"></a></h4> An input aspect is a distinct part of the <a data-link-type="dfn" href="#test-subject" id="ref-for-test-subject④">test subject</a>. Rendering a particular piece of content to an end user commonly involves different technologies, some or all of which are required as input for an <a data-link-type="dfn" href="#atomic-rules" id="ref-for-atomic-rules②">atomic rule</a>. For example, some rules need to operate directly on the <a href="https://datatracker.ietf.org/doc/html/rfc7230">Hypertext Transfer Protocol</a> <a data-link-type="biblio" href="#biblio-http11" title="HTTP/1.1">[http11]</a> messages exchanged between a server and a client, while others need to operate on the <a href="https://dom.spec.whatwg.org">Document Object Model</a> <a data-link-type="biblio" href="#biblio-dom" title="DOM Standard">[DOM]</a> tree exposed by a web browser. <a data-link-type="dfn" href="#atomic-rules" id="ref-for-atomic-rules③">Atomic rules</a> must list the aspects used as input for the <a href="#applicability-atomic">applicability</a> and <a href="#expectations-atomic">expectations</a> of the atomic rule. Rules can operate on several aspects simultaneously, such as both the HTTP messages and the DOM tree. Some input aspects are well defined in a formal specification, such as HTTP messages, the DOM tree, and CSS styling <a data-link-type="biblio" href="#biblio-css-2018" title="CSS Snapshot 2018">[css-2018]</a>. For these, a reference to the corresponding section in the <a href="https://www.w3.org/TR/act-rules-aspects/">Common Input Aspects note</a> is sufficient as a description of the aspect. For input aspects that are not well defined, an ACT Rule must include either a detailed description of the aspect in question, or a reference to a well defined description. <aside class="example" id="example-43214b40"> <a class="self-link" href="#example-43214b40"></a> <header>Example input aspects for a rule that checks if a transcript is available for videos:</header> <blockquote> <ul> <li>DOM Tree <li>CSS Styling <li>Audio output <li>Visual output </ul> </blockquote> </aside> <aside class="example" id="example-22444586"> <a class="self-link" href="#example-22444586"></a> <header>Example input aspects for a rule that checks for use of (language specific) generic link texts like "click here" and "more":</header> <blockquote> <ul> <li>DOM Tree <li>CSS Styling <li>Language </ul> </blockquote> </aside> The method through which an input aspect is served is not relevant. For example a DOM tree can be served through HTTP as HTML, it can be bundled as several pages in an <a href="http://www.idpf.org/">EPUB publication</a>, or it can be inferred from a <a href="https://facebook.github.io/jsx/">JSX source file</a>. All rules that have only DOM tree as an input aspect can be applied to those technologies. <h4 class="heading settled" data-level="4.5.2" id="input-rules">4.5.2. Input Rules (Composite rules only)<a class="self-link" href="#input-rules"></a></h4> A <a data-link-type="dfn" href="#composite-rules" id="ref-for-composite-rules①">composite rule</a> uses <a data-link-type="dfn" href="#outcome" id="ref-for-outcome⑦">outcomes</a> from <a data-link-type="dfn" href="#atomic-rules" id="ref-for-atomic-rules④">atomic rules</a> and applies logic to them so that a single outcome can be determined for each <a data-link-type="dfn" href="#test-target" id="ref-for-test-target①">test target</a>. The <a href="#rule-identifier">identifier</a> and <a data-link-type="dfn" href="#descriptive-title" id="ref-for-descriptive-title">descriptive title</a> of all the atomic rules used in the <a href="#expectations-composite">expectations</a> must be listed in the composite rule. The input rules describe the input for composite rules, similar to how <a href="#input-aspects">input aspects</a> describe the input for atomic rules. <h3 class="heading settled" data-level="4.6" id="applicability">4.6. Applicability<a class="self-link" href="#applicability"></a></h3> The applicability describes what parts of the <a data-link-type="dfn" href="#test-subject" id="ref-for-test-subject⑤">test subject</a> are tested. <h4 class="heading settled" data-level="4.6.1" id="applicability-atomic">4.6.1. Applicability for Atomic Rules<a class="self-link" href="#applicability-atomic"></a></h4> The applicability section is a required part of an <a data-link-type="dfn" href="#atomic-rules" id="ref-for-atomic-rules⑤">atomic rule</a>. It must contain a precise description of the parts of the <a data-link-type="dfn" href="#test-subject" id="ref-for-test-subject⑥">test subject</a> to which the rule applies. For example, specific nodes in the DOM <a data-link-type="biblio" href="#biblio-dom" title="DOM Standard">[DOM]</a> tree, or tags that are incorrectly closed in an HTML <a data-link-type="biblio" href="#biblio-html" title="HTML Standard">[HTML]</a> document. These are known as the <a data-link-type="dfn" href="#test-target" id="ref-for-test-target②">test targets</a>. The applicability must only use information made available through the listed <a href="#input-aspects">input aspects</a> in the rule. No other information can be used in the applicability. Applicability must be unambiguous so that the applicability can only be understood in one way. For example, concepts like headings and images are ambiguous since they could refer to the tag name, the semantic role, or the element’s purpose on the web page. Conversely, a rule that specifically only applies to elements with a heading tag would satisfy the unambiguous requirement. Additionally, the applicability should be described objectively and in plain language. An objective description is one that can be resolved without uncertainty, in a given technology. Examples of objective properties in HTML are tag names, their computed role, and the distance between two elements. Subjective properties are concepts like decorative, navigation mechanism, and pre-recorded that may be defined in a variety of ways, often relying on human judgement. When possible, avoid subjectivity since it can easily be misunderstood. In cases where it is impossible to objectively define the applicability, the use of a subjective description in the applicability is acceptable. When crafting a subjective applicability, if possible, split the objective and subjective parts of the applicability into separate rules. This will ensure the designed rule meets the atomic rule requirement of testing a single condition. An example would be testing headings with correct semantic markup in a different rule from those without semantic markup. Definitions can be put in the rule <a href="#glossary">glossary</a>, or they can be defined in the section where they are used. <aside class="example" id="example-81a2db62"> <a class="self-link" href="#example-81a2db62"></a> <header>Example objective applicability of an atomic rule testing <a href="https://www.w3.org/WAI/WCAG22/quickref/#audio-control">WCAG 2.2 success criterion 1.4.2 Audio Control</a>:</header> <blockquote> Applicability: Each <code>video</code> or <code>audio</code> element with the <code>autoplay</code> attribute, as well as each <code>object</code> element that is used for automatically playing video or audio when the web page loads. Note: A web page is considered "loaded" when the <code>document.readyState</code> is set to <code>complete</code>. </blockquote> </aside> <aside class="example" id="example-f00856a4"> <a class="self-link" href="#example-f00856a4"></a> <header>Example objective applicability of a rule with the page as a test target</header> <blockquote> Applicability: The rule applies to any page where the document element is an <code>html</code> element, and the <code>html</code> element is rendered in a top-level context (i.e. the <code>html</code> element is not embedded in another page, such as through <code>iframe</code> or <code>object</code> elements). </blockquote> </aside> <aside class="example" id="example-6e6164c4"> <a class="self-link" href="#example-6e6164c4"></a> <header>Example objective applicability of a rule with a DOM attribute as a test target</header> <blockquote> Applicability: The rule applies to any <code>role</code> attribute that is specified on an HTML or SVG element. </blockquote> </aside> <aside class="example" id="example-5213d696"> <a class="self-link" href="#example-5213d696"></a> <header>Example subjective applicability for a rule testing that elements styled as a heading use correct heading markup. This rule applicability cannot be written objectively since "styled as a heading" is subjective and depends on the context of the page.</header> <blockquote> Applicability: The rule applies to any HTML element that is styled as a heading. Elements that are styled as a heading may include features such as a larger font-size than nearby text, bolding or changing of the font, or the use of whitespace or shapes that visually distinguish the element text. </blockquote> </aside> <aside class="example" id="example-8bd9cea1"> <a class="self-link" href="#example-8bd9cea1"></a> <header>Non-conforming Example:This example demonstrates an applicability that attempts to be subjective, but does not meet the "must be unambiguous" requirement. For example, non-text content could refer to images, interactive elements, or even a text smiling face emoji using a colon and parathesis like ":)". Due to the ambiguity in the applicability it is impossible to tell.</header> <blockquote> Applicability: This rule applies to any non-text content. </blockquote> </aside> <h5 class="heading settled" data-level="4.6.1.1" id="applicability-type-designation-atomic-optional">4.6.1.1. Applicability Type Designation (optional) {#applicability-type-designation-atomic-optional}<a class="self-link" href="#applicability-type-designation-atomic-optional"></a></h5> Rules can optionally include an applicability type identifier signifying whether the rule contains an objective or a subjective applicability. This identifier is intended to benefit rule readers and implementers by clearly stating the rule author’s intention of the applicability and reducing confusion due to different reader and implementer interpretations. <h4 class="heading settled" data-level="4.6.2" id="applicability-composite">4.6.2. Applicability for Composite Rules<a class="self-link" href="#applicability-composite"></a></h4> The applicability of a composite rule is defined as the union of all applicability definitions from the rules listed in the <a href="#input-rules">input rules</a>. Rule authors may omit a description of the applicability for composite rules. This can be useful if it is difficult to express the combined applicability in plain language. If the composite rule includes applicability, it must be the union of all the applicability in the <a href="#input-rules">input rules</a>. Note that input rules in a composite rule may have different applicability. Because of this, not every test target applicable within the composite rule is tested by every input rule. <aside class="example" id="example-5ca938b6"> <a class="self-link" href="#example-5ca938b6"></a> <header>Example of the union of applicability of input rules in a composite rule:</header> <blockquote> Input applicability: <ul> <li>Input Rule 1: All <code>img</code> element with an <code>alt</code> attribute <li>Input Rule 2: All <code>img</code> element without an <code>alt</code> attribute </ul> Combined applicability: All <code>img</code> elements. </blockquote> </aside> <h5 class="heading settled" data-level="4.6.2.1" id="applicability-type-designation-composite-optional">4.6.2.1. Applicability Type Designation (optional) {#applicability-type-designation-composite-optional}<a class="self-link" href="#applicability-type-designation-composite-optional"></a></h5> Composite rules can optionally include an applicability type identifier signifying whether the rule contains an objective or a subjective applicability. The applicability type of a composite rule is calculated as subjective if any of the input rules contain a subjective applicability or objective otherwise. <h3 class="heading settled" data-level="4.7" id="expectations">4.7. Expectations<a class="self-link" href="#expectations"></a></h3> An ACT Rule must contain one or more expectations. The expectations describe what the requirements are for the <a data-link-type="dfn" href="#test-target" id="ref-for-test-target③">test targets</a> derived from the <a href="#applicability">applicability</a>. An expectation is an assertion about a <a data-link-type="dfn" href="#test-target" id="ref-for-test-target④">test target</a>. When a test target meets all expectations, the test target <code>passed</code> the rule. If the test target does not meet all expectations, the test target <code>failed</code> the rule. If there are no test targets, the <a data-link-type="dfn" href="#outcome" id="ref-for-outcome⑧">outcome</a> for the rule is <code>inapplicable</code>. Each expectation must be distinct, unambiguous, and be written in plain language. <h4 class="heading settled" data-level="4.7.1" id="expectations-atomic">4.7.1. Expectations for Atomic Rules<a class="self-link" href="#expectations-atomic"></a></h4> All expectations of an <a data-link-type="dfn" href="#atomic-rules" id="ref-for-atomic-rules⑥">atomic rule</a> must describe the logic that is used to determine a single <code>passed</code> or <code>failed</code> <a data-link-type="dfn" href="#outcome" id="ref-for-outcome⑨">outcome</a> for a <a data-link-type="dfn" href="#test-target" id="ref-for-test-target⑤">test target</a>. The expectation must only use information available in the <a href="#input-aspects">input aspects</a>, from the applicability, and other expectations of the same rule. No other information can be used in the expectation. So for instance, an expectation could be "Expectation 1 is true and ...", but it can’t be "Rule XYZ passed and ...". This ensures that atomic rules are encapsulated. <aside class="example" id="example-6e5a951f"> <a class="self-link" href="#example-6e5a951f"></a> <header>Example expectations of a rule to test for accessible names of HTML <code>input</code> elements:</header> <blockquote> <ol> <li>Each HTML <code>input</code> element has an accessible name (as described in <a href="https://www.w3.org/TR/accname-1.1/#mapping_additional_nd_te">Accessible Name and Description: Computation and API Mappings 1.1</a>). <a data-link-type="biblio" href="#biblio-accname-aam-11" title="Accessible Name and Description Computation 1.1">[accname-aam-1.1]</a> <li>The accessible name describes the purpose of each HTML <code>input</code> element. </ol> </blockquote> </aside> <aside class="example" id="example-7aacb8b3"> <a class="self-link" href="#example-7aacb8b3"></a> <header>Example expectation of a rule to test if a <code>role</code> attribute is valid:</header> <blockquote> <ol> <li>Each <code>role</code> attribute has a value that corresponds to a non-abstract <a href="https://www.w3.org/TR/wai-aria/">WAI-ARIA 1.2</a> role. </ol> </blockquote> </aside> <div class="note" role="note"> Note: Sometimes there is the need for rules with more complex aggregation, for example that X% of all images on a web page are expected to have text alternatives. In this case, the page itself needs to become the test target. The expectation would then be "The test target (the page) has a text alternative for X% of all img elements". The logic for calculating the expectations in such rules is left to the implementations, to avoid over-complexity of this rules format. </div> <h4 class="heading settled" data-level="4.7.2" id="expectations-composite">4.7.2. Expectations for Composite Rules<a class="self-link" href="#expectations-composite"></a></h4> All expectations of a <a data-link-type="dfn" href="#composite-rules" id="ref-for-composite-rules②">composite rule</a> must describe the logic that is used to determine a single <code>passed</code> or <code>failed</code> <a data-link-type="dfn" href="#outcome" id="ref-for-outcome①⓪">outcome</a> for a <a data-link-type="dfn" href="#test-target" id="ref-for-test-target⑥">test target</a>, based on the outcomes of rules in its <a href="#input-rules">input rules</a>. A composite rule expectation must not use information from <a href="#input-aspects">input aspects</a>. The outcome for a composite rule is <code>inapplicable</code> when all input rules are inapplicable. <aside class="example" id="example-a1dcfe4c"> <a class="self-link" href="#example-a1dcfe4c"></a> <header>Example expectations for the composite rule 'video elements have an audio description or media alternative' (<a href="https://www.w3.org/WAI/WCAG22/quickref/#audio-description-or-media-alternative-prerecorded">WCAG 2.2 success criterion 1.2.3 Audio Description or Media Alternative</a>):</header> <blockquote> Each HTML <code>video</code> element meets all expectations from at least one of the following rules: <ul> <li>video elements have a transcript <li>video elements have an audio description <li>video elements have a description track </ul> </blockquote> </aside> <aside class="example" id="example-b218f8a4"> <a class="self-link" href="#example-b218f8a4"></a> <header>Example expectations for a composite rule that checks if a mechanism is available to escape a keyboard trap; Either through a standard mechanism, or one for which instructions are available:</header> <blockquote> For each focusable element, the outcome of one of the following rules is <code>passed</code>: <ul> <li>Keyboard trap with standard escape mechanism <li>Keyboard trap with escape instructions </ul> </blockquote> </aside> <h3 class="heading settled" data-level="4.8" id="background">4.8. Background<a class="self-link" href="#background"></a></h3> An ACT Rule’s Background must contain the Assumptions and Accessibility Support sections. Additional information may be included about the development of the rule, or references to relevant reading in Other Resources, or Related Rules. Whenever a reference is included in the rule, the relationship to the relevant reading can be specified. Examples of relevant background references for a rule for a <a href="https://www.w3.org/WAI/standards-guidelines/wcag/">Web Content Accessibility Guidelines</a> <a data-link-type="biblio" href="#biblio-wcag22" title="Web Content Accessibility Guidelines (WCAG) 2.2">[WCAG22]</a> success criterion could be <a href="https://www.w3.org/WAI/WCAG22/Understanding/">WCAG 2.2 Understanding documents</a>, <a href="https://www.w3.org/WAI/WCAG22/Techniques/">WCAG 2.2 Techniques</a>, or <a href="https://www.w3.org/TR/wai-aria/">WAI-ARIA 1.2</a>, CSS <a data-link-type="biblio" href="#biblio-css-2018" title="CSS Snapshot 2018">[css-2018]</a>, or HTML <a data-link-type="biblio" href="#biblio-html" title="HTML Standard">[HTML]</a> specifications. <h4 class="heading settled" data-level="4.8.1" id="assumptions">4.8.1. Assumptions<a class="self-link" href="#assumptions"></a></h4> An ACT Rule must list any known assumptions, limitations or any exceptions for the evaluation, the test environment, technologies being used or the subject being tested. For example, a rule that would partially test <a href="https://www.w3.org/WAI/WCAG22/quickref/#contrast-minimum">WCAG 2.2 success criterion 1.4.3 Contrast (Minimum)</a> based on the inspection of CSS properties could state that it is only applicable to HTML text content styleable with CSS, and that the rule does not support images of text. Sometimes there are multiple plausible ways that an accessibility requirement can be interpreted. For instance, it is not immediately obvious if emoji characters are "text" or "non-text content" in the <a href="https://www.w3.org/WAI/standards-guidelines/wcag/">Web Content Accessibility Guidelines</a> <a data-link-type="biblio" href="#biblio-wcag22" title="Web Content Accessibility Guidelines (WCAG) 2.2">[WCAG22]</a>. Whatever the interpretation is, this must be documented in the rule. While the assumptions must be included in the ACT Rule, it may be empty when there are no known assumptions, limitations or exceptions. <h4 class="heading settled" data-level="4.8.2" id="accessibility-support">4.8.2. Accessibility Support<a class="self-link" href="#accessibility-support"></a></h4> Content can be designed to rely on the support for particular accessibility features by different assistive technologies and user agents. For example, content using a particular <a href="https://www.w3.org/TR/wai-aria/">WAI-ARIA 1.2</a> feature relies on that feature to be supported by assistive technologies and user agents. This content would not work for assistive technologies and user agents that do not support WAI-ARIA. See the WCAG definition for <a href="https://www.w3.org/TR/WCAG22/#dfn-accessibility-supported">accessibility supported</a> use of a web technology. An ACT Rule must include known limitations on accessibility support. <aside class="example" id="example-90a74aef"> <a class="self-link" href="#example-90a74aef"></a> <header>Example of a rule that checks if <code>aria-errormessage</code> is used to satisfy <a href="https://www.w3.org/TR/WCAG22/#status-messages">WCAG 2.2 success criterion 4.1.3 Status messages</a>:</header> <blockquote> The <code>aria-errormessage</code> property is known to have limited support with several major screen readers. This method cannot be relied on for support. Alternatives, like using live regions, could serve as fallback. (January 2019) </blockquote> </aside> While an accessibility support section must be included in the ACT Rule, it may be empty when there are no known accessibility support issues. <div class="note" role="note"> Note: The Website Accessibility Conformance Evaluation Methodology (WCAG-EM) provides guidance on defining an <a href="https://www.w3.org/TR/WCAG-EM/#step1c">accessibility support baseline</a> for test scenarios, which can help users of ACT Rules to select the appropriate rules for their own circumstance. </div> <h4 class="heading settled" data-level="4.8.3" id="related-rules">4.8.3. Related Rules (optional)<a class="self-link" href="#related-rules"></a></h4> Related rules are other rules that test the same accessibility requirement. For example, two related rules of a composite rule can be the two atomic rules that contribute to its outcome. Similarly, each atomic rule in this example can list the other atomic rule and the composite rule as its related rules. <h4 class="heading settled" data-level="4.8.4" id="other-resources">4.8.4. Other Resources (optional)<a class="self-link" href="#other-resources"></a></h4> Whenever a resource is included in the rule, the relationship to the relevant reading can be specified. Examples of relevant background references for a rule for a <a href="https://www.w3.org/WAI/standards-guidelines/wcag/">Web Content Accessibility Guidelines</a> <a data-link-type="biblio" href="#biblio-wcag22" title="Web Content Accessibility Guidelines (WCAG) 2.2">[WCAG22]</a> success criterion could be <a href="https://www.w3.org/WAI/WCAG22/Understanding/">WCAG 2.2 Understanding documents</a>, <a href="https://www.w3.org/WAI/WCAG22/Techniques/">WCAG 2.2 Techniques</a>, or <a href="https://www.w3.org/TR/wai-aria/">WAI-ARIA 1.2</a>, CSS <a data-link-type="biblio" href="#biblio-css-2018" title="CSS Snapshot 2018">[css-2018]</a>, or HTML <a data-link-type="biblio" href="#biblio-html" title="HTML Standard">[HTML]</a> specifications. <h3 class="heading settled" data-level="4.9" id="test-cases">4.9. Test Cases<a class="self-link" href="#test-cases"></a></h3> Test cases are (snippets of) content that can be used to validate the implementation of ACT Rules. Each rule must have one or more test cases for <code>passed</code>, <code>failed</code>, and <code>inapplicable</code> <a data-link-type="dfn" href="#outcome" id="ref-for-outcome①①">outcomes</a>. A test case consists of two pieces of data, a snippet of each <a href="#input-aspects">input aspect</a> for a rule, and the expected outcome for that rule. Test cases serve two functions, firstly as example scenarios for readers to understand when the outcome of a rule is <code>passed</code>, <code>failed</code>, or <code>inapplicable</code>. It also serves developers and users of accessibility testing tools and methodologies to validate that a rule is correctly implemented. Each<code>passed</code> and <code>inapplicable</code> test case of an ACT Rule must satisfy all the rule’s <a data-link-type="dfn" href="#conformance-requirements①" id="ref-for-conformance-requirements①">conformance requirements</a>. For each <code>failed</code> test case, all conformance requirements must be not satisfied. <aside class="example" id="example-09b9695b"> <a class="self-link" href="#example-09b9695b"></a> <header>Example of HTML test cases for a rule that checks if <code>img</code> elements have a text alternative:</header> <blockquote> Example of a <code>passed</code> outcome: <pre class="language-html highlight"><c- p><</c-><c- f>img</c-> <c- e>alt</c-><c- o>=</c-><c- s>"W3C Logo"</c-> <c- e>src</c-><c- o>=</c-><c- s>"image/w3c.png"</c-><c- p>></c-> </pre> Example of a <code>failed</code> outcome: <pre class="language-html highlight"><c- p><</c-><c- f>img</c-> <c- e>src</c-><c- o>=</c-><c- s>"image/w3c.png"</c-><c- p>></c-> </pre> Example of an <code>inapplicable</code> outcome: <pre class="language-html highlight"><c- p><</c-><c- f>input</c-> <c- e>type</c-><c- o>=</c-><c- s>"image"</c-> <c- e>alt</c-><c- o>=</c-><c- s>"W3C Logo"</c-> <c- e>src</c-><c- o>=</c-><c- s>"image/w3c.png"</c-><c- p>></c-> </pre> </blockquote> </aside> <h3 class="heading settled" data-level="4.10" id="rule-versions">4.10. Rule Versions<a class="self-link" href="#rule-versions"></a></h3> It is important to keep track of versions of ACT Rules so that users of the rules can understand if changes in test results are due to changes in the rules used when performing the tests, or from changes in the content itself. All previous versions of an ACT Rule must be recorded either in the rule document or referenced from it. This section was previously named "Change Log". Either section name is acceptable. <h3 class="heading settled" data-level="4.11" id="act-rules-format-version">4.11. ACT Rules Format Version<a class="self-link" href="#act-rules-format-version"></a></h3> An ACT Rule is written for a specific version of the ACT Rules Format. Each ACT Rule must indicate the version of the ACT Rules Format for which it is written. <h3 class="heading settled" data-level="4.12" id="glossary">4.12. Glossary<a class="self-link" href="#glossary"></a></h3> ACT Rules must have a glossary section. The glossary must contain the <a data-link-type="dfn" href="#outcome" id="ref-for-outcome①②">outcome</a> definition, as well as any definitions used in <a href="#applicability">applicability</a> and <a href="#expectations">expectations</a> sections in the rule. Since changes to the definition change the rule, those definitions cannot be maintained independently of the rule. If a shared glossary is used for rules, any definition changes must result in a new <a href="#rule-versions">rule version</a> of all rules that use that definition. <h3 class="heading settled" data-level="4.13" id="issues-list">4.13. Issues List (optional)<a class="self-link" href="#issues-list"></a></h3> An ACT Rule may include a list or a reference to a list of any known issues. The issues list would be used to record cases where an <a data-link-type="dfn" href="#outcome" id="ref-for-outcome①③">outcome</a> of an ACT Rule was <code>failed</code> where it ought to have been <code>passed</code> or <code>inapplicable</code>, or vice versa. There are several reasons why this might occur. See <a href="#rule-accuracy">rule accuracy</a> for more information. The issues list serves two purposes. For users of ACT Rules, the issues list gives insight into why an inaccurate result occurred, as well as provide confidence in the result of that rule. For the designer of the rule, the issues list is also useful to plan future updates to the rule. In a new version of the rule, resolved issues would be moved to the change log. <h3 class="heading settled" data-level="4.14" id="implementations">4.14. Implementations (optional)<a class="self-link" href="#implementations"></a></h3> An ACT Rule may contain a list of <a data-link-type="dfn" href="#implementation" id="ref-for-implementation">implementations</a>, where each <a data-link-type="dfn" href="#implementation" id="ref-for-implementation①">implementation</a> has one or more <a data-link-type="dfn" href="#check" id="ref-for-check">checks</a> that are consistent or partially consistent with that rule. An implementation is an accessibility test methodology or test tool that uses <a data-link-type="dfn" href="#check" id="ref-for-check①">checks</a> to compute <a data-link-type="dfn" href="#outcome" id="ref-for-outcome①④">outcomes</a> indicating whether an <a data-link-type="dfn" href="#accessibility-requirement" id="ref-for-accessibility-requirement⑧">accessibility requirement</a> could be satisfied. These checks can be fully automated, completely manual, or some combination of the two. <a data-link-type="dfn" href="#check" id="ref-for-check②">Checks</a> are not required to have a one-to-one mapping to an ACT Rule. A single check can be consistent with multiple ACT Rules or a <a href="#impl-partial-consistency">set of checks</a> can together be consistent with a single ACT Rule. For each implementation, information such as the following could be included: <ul> <li data-md> Name, title or identifier of any consistent or partially consistent checks <li data-md> <a href="#impl-consistency">Consistency</a> <li data-md> <a href="https://www.w3.org/TR/EARL10-Schema/#TestMode">test modes</a> of the checks (e.g. automatic, manual, semiAuto) <li data-md> Name of implementation <li data-md> Version used in testing consistency and coverage <li data-md> Name of the vendor </ul> <h4 class="heading settled" data-level="4.14.1" id="impl-consistency">4.14.1. Consistency<a class="self-link" href="#impl-consistency"></a></h4> Consistency describes how well a <a data-link-type="dfn" href="#check" id="ref-for-check③">check</a> is aligned with the intent of an ACT Rule. If consistency is included in an ACT Rule it must be determined as defined in this section. A consistent check of an ACT Rule is one that can be used to identify some or all non-conformance issues as described by the rule. A check is <dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="consistent">consistent</dfn> when all the following are true: <ol> <li data-md> <dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="true-positives">True positives</dfn>: There are no inconsistencies with the test cases, meaning: <ol> <li data-md> The <code>passed</code> and <code>inapplicable</code> test cases are not reported as <code>failed</code>; and <li data-md> The <code>failed</code> test cases are not reported as <code>passed</code> or <code>inapplicable</code>; and </ol> <li data-md> <dfn data-dfn-type="dfn" data-noexport id="completeness">Completeness<a class="self-link" href="#completeness"></a></dfn>: There are no gaps in coverage, meaning: <ol> <li data-md> None of the <a data-link-type="dfn" href="#check" id="ref-for-check④">check</a>'s outcomes are <code>untested</code>; and <li data-md> At least one of the <code>failed</code> test cases is reported as <code>failed</code>; and </ol> <li data-md> <dfn data-dfn-type="dfn" data-noexport id="rule-mapping">Rule Mapping<a class="self-link" href="#rule-mapping"></a></dfn>: The accessibility requirements are reported consistently, meaning: <ol> <li data-md> The <a data-link-type="dfn" href="#check" id="ref-for-check⑤">check</a> is reported as testing for all the rule’s <a data-link-type="dfn" href="#conformance-requirements①" id="ref-for-conformance-requirements①①">conformance requirements</a>, except requirements of a level or standard not supported by the implementation; and <li data-md> All accessibility requirements the rule reports to be a part of are either <a data-link-type="dfn" href="#conformance-requirements①" id="ref-for-conformance-requirements①②">conformance requirements</a> or <a data-link-type="dfn" href="#secondary-requirements①" id="ref-for-secondary-requirements①">secondary requirements</a>, except for requirements of <a data-link-type="dfn" href="#accessibility-requirements-document" id="ref-for-accessibility-requirements-document⑧">accessibility requirements documents</a> not mentioned in the rule. </ol> </ol> When a <a data-link-type="dfn" href="#check" id="ref-for-check⑥">check</a> reports more than one outcomes for a test case, the first outcome that appears on the following ordered list is considered for determining consistency: <ol> <li data-md> <code>failed</code> <li data-md> <code>untested</code> <li data-md> <code>cantTell</code> <li data-md> <code>passed</code> <li data-md> <code>inapplicable</code> </ol> <h4 class="heading settled" data-level="4.14.2" id="impl-partial-consistency">4.14.2. Partial Consistency<a class="self-link" href="#impl-partial-consistency"></a></h4> A <a data-link-type="dfn" href="#check" id="ref-for-check⑦">check</a> that is not <a data-link-type="dfn" href="#consistent" id="ref-for-consistent">consistent</a> is considered <dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="partially-consistent">partially consistent</dfn> if the <a data-link-type="dfn" href="#true-positives" id="ref-for-true-positives">true positive</a> condition is true and not all outcomes it reports for the rule’s test cases are <code>cantTell</code> or <code>untested</code>. <h4 class="heading settled" data-level="4.14.3" id="impl-multi-check">4.14.3. Consistency with multiple checks<a class="self-link" href="#impl-multi-check"></a></h4> An <a data-link-type="dfn" href="#implementation" id="ref-for-implementation②">implementation</a> can include <a data-link-type="dfn" href="#check" id="ref-for-check⑧">checks</a> that test only parts of a single ACT Rule. The combination of those checks can be consistent if all parts of the ACT Rule are covered. The consistency of a <dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="set-of-checks">set of checks</dfn> can be determined by treating all <a data-link-type="dfn" href="#partially-consistent" id="ref-for-partially-consistent">partially consistent</a> checks as though they were a single check. A <a data-link-type="dfn" href="#set-of-checks" id="ref-for-set-of-checks">set of checks</a> is <a data-link-type="dfn" href="#consistent" id="ref-for-consistent①">consistent</a> with an ACT Rule if it meets all requirements for a <a data-link-type="dfn" href="#consistent" id="ref-for-consistent②">consistent check</a>. The <a data-link-type="dfn" href="#outcome" id="ref-for-outcome①⑤">outcomes</a> for this set of checks is a list of all outcomes of checks that are partially consistent with the ACT Rule. The accessibility requirements of this set of checks is a list of all accessibility requirements of checks that are partially consistent with the ACT rule. <aside class="example" id="example-cc021208"> <a class="self-link" href="#example-cc021208"></a> <header>Example of a consistent set of checks:</header> <blockquote> An ACT Rule checks that all native button elements, and elements with a role="button" have an accessible name. The ACT Rule has test cases including both native buttons and role="button" elements. The ACME Conformance Tool has a check for native button elements. This check passes all native buttons with an accessible name, it fails all native buttons without an accessible name, and gives inapplicable for pages with only elements with role="button". Because it reports inapplicable for some of the failed test cases of the ACT Rule, this check is partially consistent. ACME Conformance Tool has a second check for elements with role="button". This works similarly to the previous check, except it passes and fails role="button" elements, and is inapplicable for pages with only native buttons. This check is also partially consistent. The combination of these two checks is consistent though, because all failed test cases of the ACT Rule are failed by one of the checks. </blockquote> </aside> <h3 class="heading settled" data-level="4.15" id="acknowledgments">4.15. Acknowledgments (optional)<a class="self-link" href="#acknowledgments"></a></h3> An ACT Rule may contain acknowledgments. This can include, but is not limited to: <ul> <li data-md> List of rule authors <li data-md> List of rule reviewers/contributors <li data-md> Funding or other support </ul> <h2 class="heading settled" data-level="5" id="rule-accuracy">5. Rule Accuracy<a class="self-link" href="#rule-accuracy"></a></h2> This section is non-normative. While <a href="#test-cases">test cases</a> can be used to determine if an ACT Rule was correctly implemented, they do not guarantee that implementations will never produce incorrect results. When writing ACT Rules, it is almost inevitable that edge cases will be overlooked. Technologies are always evolving, and content authors are constantly coming up with new and unexpected ways to use them. Some examples of causes for inaccuracy are: <ul> <li data-md> <a href="#assumptions">Assumptions</a> were made about the test subject that turned out to be untrue <li data-md> Technologies were used in an unusual and difficult to predict manner <li data-md> Technologies have changes, or aspects of the technologies were overlooked <li data-md> The accessibility requirement was not correctly interpreted </ul> There are two types of inaccuracies that can produce incorrect results. Inaccuracies in the implementation can be addressed with test cases, but inaccuracies in the ACT Rule itself cannot. After all, rule inaccuracies come from the rule author being unaware of a particular edge case. When a test result incorrectly indicates non-conformance to an accessibility requirement, this is known as a false positive. Opposite, when a rule incorrectly indicates conformance, this is a false negative. A percentage of false positives and false negatives can be calculated by comparing it to results from an accessibility audit: <ul> <li data-md> False positives: This is the percentage of <a data-link-type="dfn" href="#test-target" id="ref-for-test-target⑦">test targets</a>, that were <code>failed</code> by the rule, but satisfy the <a data-link-type="dfn" href="#accessibility-requirement" id="ref-for-accessibility-requirement⑨">accessibility requirements</a>. <li data-md> False negatives: This is the percentage of <a data-link-type="dfn" href="#test-target" id="ref-for-test-target⑧">test targets</a>, that were <code>passed</code> by the rule, but do not satisfy the <a data-link-type="dfn" href="#accessibility-requirement" id="ref-for-accessibility-requirement①⓪">accessibility requirements</a>. </ul> The ever present possibility of false positives and false negatives with ACT Rules means they will likely require ongoing maintenance. Designing a process for maintaining ACT Rules is outside the scope of the ACT Rules Format, which is limited to the rules themselves. Nevertheless, it is suggested that rule authors work out a process for maintaining their rules. <h2 class="heading settled" data-level="6" id="harmonization">6. Harmonization<a class="self-link" href="#harmonization"></a></h2> This section is non-normative. While the ACT Rules Format is designed to stimulate harmonization, there are no direct requirement in the ACT Rules Format that prevent a rule author from writing rules inconsistent with already established ACT Rules. Neither are there requirements for ACT Rules to have a certain number of implementations, or to have a certain level of accuracy. This allows quality requirements to be different for different rulesets, and allows them to develop over time. Harmonization occurs when a group of rule implementors collectively accept the validity of an ACT Rule. For example, a community group of accessibility testing tool vendors could declare they have harmonized on a particular set of ACT Rules. Such a group can set acceptance criteria for rules, and have quality requirements that go beyond the ACT Rules Format. <aside class="example" id="example-65a5c06a"> <a class="self-link" href="#example-65a5c06a"></a> <header>Example of acceptance criteria for a group working on EPUB rules:</header> <blockquote> <ul> <li>An ACT EPUB Rule is harmonized when it is approved by members of 3 organizations, AND <li>An ACT EPUB Rule is harmonized when it has 2 independent implementations </ul> </blockquote> </aside> An example of such a process is the <a href="https://w3c.github.io/wcag-act/wcag-ruleset-review-process">WCAG ACT Review Process</a>. <h2 class="heading settled" data-level="7" id="definitions">7. Definitions<a class="self-link" href="#definitions"></a></h2> <dl> <dt><dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="accessibility-requirement">Accessibility requirement</dfn> <dd> An accessibility requirement is a requirement aimed at improving access for people with disabilities to an ICT product. In the context of ACT rules mapping, a requirement can be compulsory or advisory. When compulsory, it has to be satisfied in order to conform to a standard, or to comply with a contract, policy or regulation. When advisory, it is recommended, but not satisfying it does not lead to non-conformance or non-compliance. A common example of accessibility requirements are the WCAG success criteria. There are other standards, including W3C standards, that have recommendations for accessibility, such as WAI-ARIA and HTML. Accessibility requirements are also often found in company policies, regional standards or in legislation. <dt><dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="accessibility-requirements-document">Accessibility requirements document</dfn> <dd> A document, such as a standard, contract, policy or regulation, that includes <a data-link-type="dfn" href="#accessibility-requirement" id="ref-for-accessibility-requirement①①">accessibility requirements</a>. For example, WCAG 2.2, WAI-ARIA 1.2, HTML 5.2, EPUB Accessibility 1.0, BBC HTML Accessibility Standards v2.0 <dt><dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="check">Check</dfn> <dd> A procedure resulting in one or more <a data-link-type="dfn" href="#outcome" id="ref-for-outcome①⑥">outcomes</a> when used to evaluate the accessibility of a web page or other test subject. The procedure can be a step by step description of how to manually perform a test, a fully automated test, or some combination of manual and automated testing. <dt><dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="implementation">Implementation</dfn> <dd> An accessibility test methodology or test tool, containing a set of <a data-link-type="dfn" href="#check" id="ref-for-check⑨">checks</a> which can be used to determine (non-)conformance of <a data-link-type="dfn" href="#accessibility-requirement" id="ref-for-accessibility-requirement①②">accessibility requirements</a>. <dt><dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="outcome">Outcome</dfn> <dd> A conclusion that comes from evaluating an ACT Rule on a <a data-link-type="dfn" href="#test-subject" id="ref-for-test-subject⑦">test subject</a> or one of its constituent <a data-link-type="dfn" href="#test-target" id="ref-for-test-target⑨">test target</a>. An outcome can be one of the five following types: <ul> <li>inapplicable: No part of the test subject matches the applicability <li>passed: A <a data-link-type="dfn" href="#test-target" id="ref-for-test-target①⓪">test target</a> meets all expectations <li>failed: A <a data-link-type="dfn" href="#test-target" id="ref-for-test-target①①">test target</a> does not meet all expectations <li>cantTell: Whether the rule is applicable, or not all expectations were met could not be fully determined by the tester. <li>Untested: The tester has not attempted to evaluate the test subject. </ul> <div class="note" role="note"> Note: A rule has one <code>passed</code> or <code>failed</code> outcome for every <a data-link-type="dfn" href="#test-target" id="ref-for-test-target①②">test target</a>. When a tester evaluates a test target it can also be reported as <code>cantTell</code> if the rule cannot be tested in its entirety. For example, when applicability was automated, but the expectations have to be evaluated manually. When there are no test targets the rule has one <code>inapplicable</code> outcome. If the tester is unable to determine whether there are test targets there will be one <code>cantTell</code> outcome. And when no evaluation has occurred the test target has one <code>untested</code> outcome. This means that each <a data-link-type="dfn" href="#test-subject" id="ref-for-test-subject⑧">test subject</a> always has one or more outcomes. Outcomes used in ACT Rules can be expressed using the <a href="https://www.w3.org/TR/EARL10-Schema/#outcome">outcome property</a> of the <a data-link-type="biblio" href="#biblio-earl10-schema" title="Evaluation and Report Language (EARL) 1.0 Schema">[EARL10-Schema]</a>. </div> <dt><dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="test-subject">Test Subject</dfn> <dd> A resource or collection of resources that can be evaluated by an ACT Rule. <aside class="example" id="example-42b1dee1"> <a class="self-link" href="#example-42b1dee1"></a> <header>Example of test subjects:</header> <blockquote> <ul> <li>An HTML page, including all embedded scripts, style and images <li>An EPUB publication <li>A web component file </ul> </blockquote> </aside> <div class="note" role="note"> Note: Implementers using the <a data-link-type="biblio" href="#biblio-earl10-schema" title="Evaluation and Report Language (EARL) 1.0 Schema">[EARL10-Schema]</a> can express the test subject with the <a href="https://www.w3.org/TR/EARL10-Schema/#subject">subject property</a> </div> <dt><dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="test-target">Test Target</dfn> <dd> A distinct part of the <a data-link-type="dfn" href="#test-subject" id="ref-for-test-subject⑨">test subject</a>, as defined by the <a href="#applicability">applicability</a>. <aside class="example" id="example-cd7029f9"> <a class="self-link" href="#example-cd7029f9"></a> <header>Example of test targets:</header> <blockquote> <ul> <li>Nodes within an HTML page <li>A period of time within a video <li>A range of characters within a text document </ul> </blockquote> </aside> <div class="note" role="note"> Note: Implementers using the <a data-link-type="biblio" href="#biblio-earl10-schema" title="Evaluation and Report Language (EARL) 1.0 Schema">[EARL10-Schema]</a> can express the test target with the <a href="https://www.w3.org/TR/EARL10-Schema/#pointer">pointer property</a> </div> </dl> <h2 class="heading settled" id="appendix-data-example">Appendix 1: Expressing ACT Rule results with JSON-LD and EARL<a class="self-link" href="#appendix-data-example"></a></h2> This section is non-normative. This section provides examples of expressing results from carrying out ACT Rules using EARL and JSON-LD (See <a href="https://www.w3.org/WAI/standards-guidelines/earl/">Evaluation and Report Language</a> and <a href="https://www.w3.org/TR/json-ld/">A JSON-based Serialization for Linked Data (JSON-LD)</a>). More examples and background is provided on the <a href="https://github.com/w3c/earl">JSON-LD serialization of EARL</a> GitHub repository. Examples in this section include: <ul> <li data-md> Example 1: Minimal outcome from one assertion <li data-md> Example 2: Results from more than one assertion <li data-md> Example 3: Aggregating based on requirement <li data-md> Example 4: Aggregating based on 'Test Subject' <li data-md> Example 5: Assumed context for this section </ul> Example 1: Minimal outcome for one assertion <pre class="language-javascript highlight"><c- p>{</c-> <c- u>"@context"</c-><c- o>:</c-> <c- u>"context.json"</c-><c- p>,</c-> <c- u>"@type"</c-><c- o>:</c-> <c- u>"Assertion"</c-><c- p>,</c-> <c- u>"assertedBy"</c-><c- o>:</c-> <c- u>"https://example.org/MyTool"</c-><c- p>,</c-> <c- u>"subject"</c-><c- o>:</c-> <c- u>"https://example.org/page1.html"</c-><c- p>,</c-> <c- u>"test"</c-><c- o>:</c-> <c- u>"ACT-CG:rules/23a2a8"</c-><c- p>,</c-> <c- u>"result"</c-><c- o>:</c-> <c- p>{</c-> <c- u>"outcome"</c-><c- o>:</c-> <c- u>"earl:failed"</c-><c- p>,</c-> <c- u>"pointer"</c-><c- o>:</c-> <c- u>"html > body > h1:first-child"</c-> <c- p>}</c-> <c- p>}</c-> </pre> Example 2: Results for more than one assertion <pre class="language-javascript highlight"><c- p>{</c-> <c- u>"@context"</c-><c- o>:</c-> <c- u>"context.json"</c-><c- p>,</c-> <c- u>"@graph"</c-><c- o>:</c-> <c- p>[{</c-> <c- u>"@type"</c-><c- o>:</c-> <c- u>"Assertion"</c-><c- p>,</c-> <c- u>"assertedBy"</c-><c- o>:</c-> <c- u>"https://example.org/MyTool"</c-><c- p>,</c-> <c- u>"subject"</c-><c- o>:</c-> <c- u>"https://example.org/page1.html"</c-><c- p>,</c-> <c- u>"test"</c-><c- o>:</c-> <c- u>"ACT-CG:rules/23a2a8"</c-><c- p>,</c-> <c- u>"result"</c-><c- o>:</c-> <c- p>{</c-> <c- u>"outcome"</c-><c- o>:</c-> <c- u>"earl:failed"</c-><c- p>,</c-> <c- u>"pointer"</c-><c- o>:</c-> <c- u>"html > body > h1:first-child"</c-> <c- p>}</c-> <c- p>},</c-> <c- p>{</c-> <c- u>"@type"</c-><c- o>:</c-> <c- u>"Assertion"</c-><c- p>,</c-> <c- u>"assertedBy"</c-><c- o>:</c-> <c- u>"https://example.org/AnotherTool"</c-><c- p>,</c-> <c- u>"subject"</c-><c- o>:</c-> <c- u>"https://example.org/page1.html"</c-><c- p>,</c-> <c- u>"test"</c-><c- o>:</c-> <c- u>"ACT-CG:rules/23a2a8"</c-><c- p>,</c-> <c- u>"result"</c-><c- o>:</c-> <c- p>{</c-> <c- u>"outcome"</c-><c- o>:</c-> <c- u>"earl:passed"</c-><c- p>,</c-> <c- u>"pointer"</c-><c- o>:</c-> <c- u>"html > body > h1:nth-child(2)"</c-> <c- p>}</c-> <c- p>}]</c-> <c- p>}</c-> </pre> Example 3: Aggregating based on requirement (eg. WCAG Success Criteria) <pre class="language-javascript highlight"><c- p>{</c-> <c- u>"@context"</c-><c- o>:</c-> <c- u>"context.json"</c-><c- p>,</c-> <c- u>"@type"</c-><c- o>:</c-> <c- u>"Assertion"</c-><c- p>,</c-> <c- u>"assertedBy"</c-><c- o>:</c-> <c- u>"https://example.org/MyTool"</c-><c- p>,</c-> <c- u>"subject"</c-><c- o>:</c-> <c- u>"https://example.org/page1.html"</c-><c- p>,</c-> <c- u>"test"</c-><c- o>:</c-> <c- p>{</c-> <c- u>"@type"</c-><c- o>:</c-> <c- u>"earl:TestRequirement"</c-><c- p>,</c-> <c- u>"@id"</c-><c- o>:</c-> <c- u>"WCAG22:non-text-content"</c-> <c- p>},</c-> <c- u>"result"</c-><c- o>:</c-> <c- p>{</c-> <c- u>"outcome"</c-><c- o>:</c-> <c- u>"earl:failed"</c-><c- p>,</c-> <c- u>"source"</c-><c- o>:</c-> <c- p>[{</c-> <c- u>"test"</c-><c- o>:</c-> <c- u>"ACT-CG:rules/23a2a8"</c-><c- p>,</c-> <c- u>"result"</c-><c- o>:</c-> <c- p>{</c-> <c- u>"outcome"</c-><c- o>:</c-> <c- u>"earl:failed"</c-><c- p>,</c-> <c- u>"pointer"</c-><c- o>:</c-> <c- u>"html > body > h1:first-child"</c-> <c- p>}</c-> <c- p>},</c-> <c- p>{</c-> <c- u>"test"</c-><c- o>:</c-> <c- u>"ACT-RULES-CG:rules/23a2a8"</c-><c- p>,</c-> <c- u>"result"</c-> <c- o>:</c-> <c- p>{</c-> <c- u>"outcome"</c-><c- o>:</c-> <c- u>"earl:passed"</c-><c- p>,</c-> <c- u>"pointer"</c-><c- o>:</c-> <c- u>"html > body > h1:nth-child(2)"</c-> <c- p>}</c-> <c- p>}]</c-> <c- p>}</c-> <c- p>}</c-> </pre> Example 4: Aggregating based on 'Test Subject' (eg. for a website) <pre class="language-javascript highlight"><c- p>{</c-> <c- u>"@context"</c-><c- o>:</c-> <c- u>"context.json"</c-><c- p>,</c-> <c- u>"@type"</c-><c- o>:</c-> <c- u>"Assertion"</c-><c- p>,</c-> <c- u>"assertedBy"</c-><c- o>:</c-> <c- p>{</c-> <c- u>"@type"</c-><c- o>:</c-> <c- u>"Organization"</c-><c- p>,</c-> <c- u>"@id"</c-><c- o>:</c-> <c- u>"_:myOrg"</c-><c- p>,</c-> <c- u>"title"</c-><c- o>:</c-> <c- u>"My Organization"</c-><c- p>,</c-> <c- u>"description"</c-> <c- o>:</c-> <c- u>"Accessibility testing service"</c-><c- p>,</c-> <c- u>"homepage"</c-> <c- o>:</c-> <c- u>"http://example.org/myOrg/"</c-> <c- p>},</c-> <c- u>"subject"</c-><c- o>:</c-> <c- p>{</c-> <c- u>"@type"</c-><c- o>:</c-> <c- p>[</c-><c- u>"WebSite"</c-><c- p>,</c-> <c- u>"TestSubject"</c-><c- p>],</c-> <c- u>"@id"</c-><c- o>:</c-> <c- u>"https://example.org/"</c-> <c- p>},</c-> <c- u>"test"</c-><c- o>:</c-> <c- p>{</c-> <c- u>"@type"</c-><c- o>:</c-> <c- u>"earl:TestRequirement"</c-><c- p>,</c-> <c- u>"@id"</c-><c- o>:</c-> <c- u>"http://www.w3.org/WAI/WCAG2A-Conformance"</c-> <c- p>},</c-> <c- u>"result"</c-><c- o>:</c-> <c- p>{</c-> <c- u>"outcome"</c-><c- o>:</c-> <c- u>"earl:failed"</c-><c- p>,</c-> <c- u>"source"</c-><c- o>:</c-> <c- p>[{</c-> <c- u>"test"</c-><c- o>:</c-> <c- p>{</c-> <c- u>"@type"</c-><c- o>:</c-> <c- u>"earl:TestRequirement"</c-><c- p>,</c-> <c- u>"@id"</c-><c- o>:</c-> <c- u>"WCAG22:non-text-content"</c-> <c- p>},</c-> <c- u>"result"</c-><c- o>:</c-> <c- p>{</c-> <c- u>"outcome"</c-><c- o>:</c-> <c- u>"earl:failed"</c-><c- p>,</c-> <c- u>"source"</c-><c- o>:</c-> <c- p>[</c-> … <c- p>]</c-> <c- p>}</c-> <c- p>},</c-> <c- p>{</c-> <c- u>"test"</c-><c- o>:</c-> <c- p>{</c-> <c- u>"@type"</c-><c- o>:</c-> <c- u>"earl:TestRequirement"</c-><c- p>,</c-> <c- u>"@id"</c-><c- o>:</c-> <c- u>"WCAG22:audio-only-and-video-only-prerecorded"</c-> <c- p>},</c-> <c- u>"result"</c-><c- o>:</c-> <c- p>{</c-> <c- u>"outcome"</c-><c- o>:</c-> <c- u>"earl:passed"</c-><c- p>,</c-> <c- u>"source"</c-><c- o>:</c-> <c- p>[</c-> … <c- p>]</c-> <c- p>}</c-> <c- p>},</c-> <c- p>{</c-> <c- u>"test"</c-><c- o>:</c-> <c- p>{</c-> <c- u>"@type"</c-><c- o>:</c-> <c- u>"earl:TestRequirement"</c-><c- p>,</c-> <c- u>"@id"</c-><c- o>:</c-> <c- u>"WCAG22:captions-prerecorded"</c-> <c- p>},</c-> <c- u>"result"</c-> <c- o>:</c-> <c- p>{</c-> <c- u>"outcome"</c-><c- o>:</c-> <c- u>"earl:passed"</c-><c- p>,</c-> <c- u>"source"</c-><c- o>:</c-> <c- p>[</c-> … <c- p>]</c-> <c- p>}</c-> <c- p>},</c-> … <c- p>]</c-> <c- p>}</c-> <c- p>}</c-> </pre> Example 5: Assumed context for this section <pre class="language-javascript highlight"><c- p>{</c-> <c- u>"@vocab"</c-><c- o>:</c-> <c- u>"http://www.w3.org/ns/earl#"</c-><c- p>,</c-> <c- u>"cnt"</c-><c- o>:</c-> <c- u>"http://www.w3.org/2011/content#"</c-><c- p>,</c-> <c- u>"dct"</c-><c- o>:</c-> <c- u>"http://purl.org/dc/terms/"</c-><c- p>,</c-> <c- u>"earl"</c-><c- o>:</c-> <c- u>"http://www.w3.org/ns/earl#"</c-><c- p>,</c-> <c- u>"foaf"</c-><c- o>:</c-> <c- u>"http://xmlns.com/foaf/0.1/"</c-><c- p>,</c-> <c- u>"htp"</c-><c- o>:</c-> <c- u>"http://www.w3.org/2011/http#"</c-><c- p>,</c-> <c- u>"ptr"</c-><c- o>:</c-> <c- u>"https://www.w3.org/2009/pointers#"</c-><c- p>,</c-> <c- u>"schema"</c-><c- o>:</c-> <c- u>"http://schema.org/"</c-><c- p>,</c-> <c- u>"xsd"</c-><c- o>:</c-> <c- u>"https://www.w3.org/2001/XMLSchema#"</c-><c- p>,</c-> <c- u>"WCAG20"</c-><c- o>:</c-> <c- u>"https://www.w3.org/TR/WCAG20#"</c-><c- p>,</c-> <c- u>"WCAG22"</c-><c- o>:</c-> <c- u>"https://www.w3.org/TR/WCAG22#"</c-><c- p>,</c-> <c- u>"ACT-RULES-CG"</c-><c- o>:</c-> <c- u>"https://act-rules.github.io/"</c-><c- p>,</c-> <c- u>"WebSite"</c-><c- o>:</c-> <c- u>"schema:WebSite"</c-><c- p>,</c-> <c- u>"WebPage"</c-><c- o>:</c-> <c- u>"schema:WebPage"</c-><c- p>,</c-> <c- u>"title"</c-><c- o>:</c-> <c- u>"dct:title"</c-><c- p>,</c-> <c- u>"description"</c-><c- o>:</c-> <c- u>"dct:description"</c-><c- p>,</c-> <c- u>"date"</c-><c- o>:</c-> <c- u>"dct:date"</c-><c- p>,</c-> <c- u>"hasVersion"</c-><c- o>:</c-> <c- u>"dct:hasVesion"</c-><c- p>,</c-> <c- u>"isPartOf"</c-><c- o>:</c-> <c- u>"dct:isPartOf"</c-><c- p>,</c-> <c- u>"hasPart"</c-><c- o>:</c-> <c- u>"dct:hasPart"</c-><c- p>,</c-> <c- u>"source"</c-><c- o>:</c-> <c- u>"dct:source"</c-><c- p>,</c-> <c- u>"Agent"</c-><c- o>:</c-> <c- u>"foaf:Agent"</c-><c- p>,</c-> <c- u>"Person"</c-><c- o>:</c-> <c- u>"foaf:Person"</c-><c- p>,</c-> <c- u>"Organization"</c-><c- o>:</c-> <c- u>"foaf:Organization"</c-><c- p>,</c-> <c- u>"Group"</c-><c- o>:</c-> <c- u>"foaf:Group"</c-><c- p>,</c-> <c- u>"Document"</c-><c- o>:</c-> <c- u>"foaf:Document"</c-><c- p>,</c-> <c- u>"name"</c-><c- o>:</c-> <c- u>"foaf:name"</c-><c- p>,</c-> <c- u>"firstName"</c-><c- o>:</c-> <c- u>"foaf:firstName"</c-><c- p>,</c-> <c- u>"surname"</c-><c- o>:</c-> <c- u>"foaf:surname"</c-><c- p>,</c-> <c- u>"mbox"</c-><c- o>:</c-> <c- u>"foaf:mbox"</c-><c- p>,</c-> <c- u>"mbox_sha1sum"</c-><c- o>:</c-> <c- u>"foaf:mbox_sha1sum"</c-><c- p>,</c-> <c- u>"member"</c-><c- o>:</c-> <c- u>"foaf:member"</c-><c- p>,</c-> <c- u>"homepage"</c-><c- o>:</c-> <c- u>"foaf:homepage"</c-><c- p>,</c-> <c- u>"assertedBy"</c-><c- o>:</c-> <c- p>{</c-> <c- u>"@type"</c-><c- o>:</c-> <c- u>"@id"</c-> <c- p>},</c-> <c- u>"subject"</c-><c- o>:</c-> <c- p>{</c-> <c- u>"@type"</c-><c- o>:</c-> <c- u>"@id"</c-> <c- p>},</c-> <c- u>"test"</c-><c- o>:</c-> <c- p>{</c-> <c- u>"@type"</c-><c- o>:</c-> <c- u>"@id"</c-> <c- p>},</c-> <c- u>"mode"</c-><c- o>:</c-> <c- p>{</c-> <c- u>"@type"</c-><c- o>:</c-> <c- u>"@id"</c-> <c- p>},</c-> <c- u>"outcome"</c-><c- o>:</c-> <c- p>{</c-> <c- u>"@type"</c-><c- o>:</c-> <c- u>"@id"</c-> <c- p>},</c-> <c- u>"pointer"</c-><c- o>:</c-> <c- p>{</c-> <c- u>"@id"</c-><c- o>:</c-> <c- u>"earl:pointer"</c-><c- p>,</c-> <c- u>"@type"</c-><c- o>:</c-> <c- u>"ptr:CSSSelectorPointer"</c-> <c- p>}</c-> <c- p>}</c-> </pre> <h2 class="heading settled" id="Acknowledgments">Appendix 2: Acknowledgments<a class="self-link" href="#Acknowledgments"></a></h2> This section is non-normative. <h3 class="heading settled" id="participants">Participants of the AG WG active in the development of this document<a class="self-link" href="#participants"></a></h3> Shadi Abou-Zahra, Trevor Bostic, Romain Deltour, Kathy Eng, Wilco Fiers, Alistair Garrison, Kasper Isager, Maureen Kraft, Mary Jo Mueller, Jey Nandakumar, Charu Pandhi, Stein Erik Skotkjerra, Anne Thyme Nørregaard, Kathleen Wahlbin <h3 class="heading settled" id="enabling-funders">Enabling funders<a class="self-link" href="#enabling-funders"></a></h3> This publication has been developed with support from the <a href="https://www.w3.org/WAI/about/projects/wai-tools/">WAI-Tools Project</a>, co-funded by the European Commission (EC) under the Horizon 2020 Program (Grant Agreement 780057). The content of this publication does not necessarily reflect the views or policies of the European Commission (EC) or any of the European Union (EU) Member States. <h2 class="heading settled" id="Change_History">Appendix 3: Change History<a class="self-link" href="#Change_History"></a></h2> This section is non-normative. <ul> <li>4. Rule Structure Accessibility Support and Assumptions section are now subsections of Background. <li>4.4. Accessibility Requirements Mapping Accessibility requirements are now categorized as either Conformance requirements or Secondary requirements. <li>4.6 Applicability Subjective applicability statements are now allowed. Objective and plain language requirements have been reduced to should instead of must. <li>4.8. Background New optional Related Rules and Other Resources subsections have been added <li>4.10. Change Log The Change Log has been renamed to Rule Versions <li>4.11 ACT Rules Format Version New requirement to identify ACT Rules Format version compatibility <li>4.14. Implementations New section has been added, including a method for determining consistency with ACT Rules <li>7. Definitions The Outcome definition is updated to include cantTell and untested <li>Overall Links to W3C specifications are updated to their latest recommendation </ul> All changes from the previous published version can be viewed using the <a href="https://services.w3.org/htmldiff?doc1=https://www.w3.org/TR/act-rules-format/&doc2=https://w3c.github.io/wcag-act/act-rules-format.html">Editor’s draft to Rules Format 1.0 Recommendation diff link</a> </main> <div data-fill-with="conformance"> <h2 class="no-ref no-num heading settled" id="w3c-conformance">Conformance<a class="self-link" href="#w3c-conformance"></a></h2> <h3 class="no-ref no-num heading settled" id="w3c-conventions">Document conventions<a class="self-link" href="#w3c-conventions"></a></h3> Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification. All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. <a data-link-type="biblio" href="#biblio-rfc2119" title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</a> Examples in this specification are introduced with the words “for example” or are set apart from the normative text with <code>class="example"</code>, like this: <div class="example" id="w3c-example"> <a class="self-link" href="#w3c-example"></a> This is an example of an informative example. </div> Informative notes begin with the word “Note” and are set apart from the normative text with <code>class="note"</code>, like this: Note, this is an informative note. <section> <h3 class="no-ref no-num heading settled" id="w3c-conformant-algorithms">Conformant Algorithms<a class="self-link" href="#w3c-conformant-algorithms"></a></h3> Requirements phrased in the imperative as part of algorithms (such as "strip any leading space characters" or "return false and abort these steps") are to be interpreted with the meaning of the key word ("must", "should", "may", etc) used in introducing the algorithm. Conformance requirements phrased as algorithms or specific steps can be implemented in any manner, so long as the end result is equivalent. In particular, the algorithms defined in this specification are intended to be easy to understand and are not intended to be performant. Implementers are encouraged to optimize. </section> </div> <script src="https://www.w3.org/scripts/TR/2021/fixup.js"></script> <h2 class="no-num no-ref heading settled" id="index">Index<a class="self-link" href="#index"></a></h2> <h3 class="no-num no-ref heading settled" id="index-defined-here">Terms defined by this specification<a class="self-link" href="#index-defined-here"></a></h3> <ul class="index"> <li><a href="#accessibility-requirement">Accessibility requirement</a>, in § 7 <li><a href="#accessibility-requirements-document">Accessibility requirements document</a>, in § 7 <li><a href="#atomic-rules">Atomic rules</a>, in § 3 <li><a href="#check">Check</a>, in § 7 <li><a href="#completeness">Completeness</a>, in § 4.14.1 <li><a href="#composite-rules">Composite rules</a>, in § 3 <li><a href="#conformance-requirements①">Conformance Requirements</a>, in § 4.4.1.1 <li><a href="#consistent">consistent</a>, in § 4.14.1 <li><a href="#descriptive-title">Descriptive Title</a>, in § 4 <li><a href="#further-testing-is-needed">further testing is needed</a>, in § 4.4.1.1 <li><a href="#implementation">Implementation</a>, in § 7 <li><a href="#not-satisfied">not satisfied</a>, in § 4.4.1.1 <li><a href="#outcome">Outcome</a>, in § 7 <li><a href="#partially-consistent">partially consistent</a>, in § 4.14.2 <li><a href="#rule-mapping">Rule Mapping</a>, in § 4.14.1 <li><a href="#satisfied">satisfied</a>, in § 4.4.1.1 <li><a href="#satisfying-tests">satisfying tests</a>, in § 4.4.1.1 <li><a href="#secondary-requirements①">Secondary Requirements</a>, in § 4.4.1.2 <li><a href="#set-of-checks">set of checks</a>, in § 4.14.3 <li><a href="#test-subject">Test Subject</a>, in § 7 <li><a href="#test-target">Test Target</a>, in § 7 <li><a href="#true-positives">True positives</a>, in § 4.14.1 </ul> <h2 class="no-num no-ref heading settled" id="references">References<a class="self-link" href="#references"></a></h2> <h3 class="no-num no-ref heading settled" id="normative">Normative References<a class="self-link" href="#normative"></a></h3> <dl> <dt id="biblio-rfc2119">[RFC2119] <dd>S. Bradner. <a href="https://datatracker.ietf.org/doc/html/rfc2119"><cite>Key words for use in RFCs to Indicate Requirement Levels</cite></a>. March 1997. Best Current Practice. URL: <a href="https://datatracker.ietf.org/doc/html/rfc2119">https://datatracker.ietf.org/doc/html/rfc2119</a> </dl> <h3 class="no-num no-ref heading settled" id="informative">Informative References<a class="self-link" href="#informative"></a></h3> <dl> <dt id="biblio-accname-aam-11">[ACCNAME-AAM-1.1] <dd>Joanmarie Diggs; Bryan Garaventa; Michael Cooper. <a href="https://www.w3.org/TR/accname-1.1/"><cite>Accessible Name and Description Computation 1.1</cite></a>. 18 December 2018. REC. URL: <a href="https://www.w3.org/TR/accname-1.1/">https://www.w3.org/TR/accname-1.1/</a> <dt id="biblio-css-2018">[CSS-2018] <dd>Tab Atkins Jr.; Elika Etemad; Florian Rivoal. <a href="https://www.w3.org/TR/css-2018/"><cite>CSS Snapshot 2018</cite></a>. 22 January 2019. NOTE. URL: <a href="https://www.w3.org/TR/css-2018/">https://www.w3.org/TR/css-2018/</a> <dt id="biblio-dom">[DOM] <dd>Anne van Kesteren. <a href="https://dom.spec.whatwg.org/"><cite>DOM Standard</cite></a>. Living Standard. URL: <a href="https://dom.spec.whatwg.org/">https://dom.spec.whatwg.org/</a> <dt id="biblio-earl10-schema">[EARL10-Schema] <dd>Shadi Abou-Zahra. <a href="https://www.w3.org/TR/EARL10-Schema/"><cite>Evaluation and Report Language (EARL) 1.0 Schema</cite></a>. 2 February 2017. NOTE. URL: <a href="https://www.w3.org/TR/EARL10-Schema/">https://www.w3.org/TR/EARL10-Schema/</a> <dt id="biblio-epub-33">[EPUB-33] <dd>Ivan Herman; Matt Garrish; Dave Cramer. <a href="https://www.w3.org/TR/epub-33/"><cite>EPUB 3.3</cite></a>. 25 May 2023. REC. URL: <a href="https://www.w3.org/TR/epub-33/">https://www.w3.org/TR/epub-33/</a> <dt id="biblio-html">[HTML] <dd>Anne van Kesteren; et al. <a href="https://html.spec.whatwg.org/multipage/"><cite>HTML Standard</cite></a>. Living Standard. URL: <a href="https://html.spec.whatwg.org/multipage/">https://html.spec.whatwg.org/multipage/</a> <dt id="biblio-http11">[HTTP11] <dd>R. Fielding, Ed.; M. Nottingham, Ed.; J. Reschke, Ed.. <a href="https://httpwg.org/specs/rfc9112.html"><cite>HTTP/1.1</cite></a>. June 2022. Internet Standard. URL: <a href="https://httpwg.org/specs/rfc9112.html">https://httpwg.org/specs/rfc9112.html</a> <dt id="biblio-svg2">[SVG2] <dd>Amelia Bellamy-Royds; et al. <a href="https://www.w3.org/TR/SVG2/"><cite>Scalable Vector Graphics (SVG) 2</cite></a>. 4 October 2018. CR. URL: <a href="https://www.w3.org/TR/SVG2/">https://www.w3.org/TR/SVG2/</a> <dt id="biblio-uaag20">[UAAG20] <dd>James Allan; et al. <a href="https://www.w3.org/TR/UAAG20/"><cite>User Agent Accessibility Guidelines (UAAG) 2.0</cite></a>. 15 December 2015. NOTE. URL: <a href="https://www.w3.org/TR/UAAG20/">https://www.w3.org/TR/UAAG20/</a> <dt id="biblio-wai-aria">[WAI-ARIA] <dd>James Craig; Michael Cooper; et al. <a href="https://www.w3.org/TR/wai-aria/"><cite>Accessible Rich Internet Applications (WAI-ARIA) 1.0</cite></a>. 20 March 2014. REC. URL: <a href="https://www.w3.org/TR/wai-aria/">https://www.w3.org/TR/wai-aria/</a> <dt id="biblio-wcag22">[WCAG22] <dd>Michael Cooper; et al. <a href="https://www.w3.org/TR/WCAG22/"><cite>Web Content Accessibility Guidelines (WCAG) 2.2</cite></a>. 5 October 2023. REC. URL: <a href="https://www.w3.org/TR/WCAG22/">https://www.w3.org/TR/WCAG22/</a> </dl> <script>/* Boilerplate: script-dfn-panel */ "use strict"; { const dfnsJson = window.dfnsJson || {}; function genDfnPanel({dfnID, url, dfnText, refSections, external}) { return mk.aside({ class: "dfn-panel", id: `infopanel-for-${dfnID}`, "data-for": dfnID, "aria-labelled-by":`infopaneltitle-for-${dfnID}`, }, mk.span({id:`infopaneltitle-for-${dfnID}`, style:"display:none"}, `Info about the '${dfnText}' ${external?"external":""} reference.`), mk.a({href:url}, url), mk.b({}, "Referenced in:"), mk.ul({}, ...refSections.map(section=> mk.li({}, ...section.refs.map((ref, refI)=> [ mk.a({ href: `#${ref.id}` }, (refI == 0) ? section.title : `(${refI + 1})` ), " ", ] ), ), ), ), ); } function genAllDfnPanels() { for(const panelData of Object.values(window.dfnpanelData)) { const dfnID = panelData.dfnID; const dfn = document.getElementById(dfnID); if(!dfn) { console.log(`Can't find dfn#${dfnID}.`, panelData); } else { const panel = genDfnPanel(panelData); append(document.body, panel); insertDfnPopupAction(dfn, panel) } } } document.addEventListener("DOMContentLoaded", ()=>{ genAllDfnPanels(); // Add popup behavior to all dfns to show the corresponding dfn-panel. var dfns = queryAll('.dfn-paneled'); for(let dfn of dfns) { ; } document.body.addEventListener("click", (e) => { // If not handled already, just hide all dfn panels. hideAllDfnPanels(); }); }) function hideAllDfnPanels() { // Turn off any currently "on" or "activated" panels. queryAll(".dfn-panel.on, .dfn-panel.activated").forEach(el=>hideDfnPanel(el)); } function showDfnPanel(dfnPanel, dfn) { hideAllDfnPanels(); // Only display one at this time. dfn.setAttribute("aria-expanded", "true"); dfnPanel.classList.add("on"); dfnPanel.style.left = "5px"; dfnPanel.style.top = "0px"; const panelRect = dfnPanel.getBoundingClientRect(); const panelWidth = panelRect.right - panelRect.left; if (panelRect.right > document.body.scrollWidth) { // Panel's overflowing the screen. // Just drop it below the dfn and flip it rightward instead. // This still wont' fix things if the screen is *really* wide, // but fixing that's a lot harder without 'anchor()'. dfnPanel.style.top = "1.5em"; dfnPanel.style.left = "auto"; dfnPanel.style.right = "0px"; } } function pinDfnPanel(dfnPanel) { // Switch it to "activated" state, which pins it. dfnPanel.classList.add("activated"); dfnPanel.style.left = null; dfnPanel.style.top = null; } function hideDfnPanel(dfnPanel, dfn) { if(!dfn) { dfn = document.getElementById(dfnPanel.getAttribute("data-for")); } dfn.setAttribute("aria-expanded", "false") dfnPanel.classList.remove("on"); dfnPanel.classList.remove("activated"); } function toggleDfnPanel(dfnPanel, dfn) { if(dfnPanel.classList.contains("on")) { hideDfnPanel(dfnPanel, dfn); } else { showDfnPanel(dfnPanel, dfn); } } function insertDfnPopupAction(dfn, dfnPanel) { // Find dfn panel const panelWrapper = document.createElement('span'); panelWrapper.appendChild(dfnPanel); panelWrapper.style.position = "relative"; panelWrapper.style.height = "0px"; dfn.insertAdjacentElement("afterend", panelWrapper); dfn.setAttribute('role', 'button'); dfn.setAttribute('aria-expanded', 'false') dfn.tabIndex = 0; dfn.classList.add('has-dfn-panel'); dfn.addEventListener('click', (event) => { showDfnPanel(dfnPanel, dfn); event.stopPropagation(); }); dfn.addEventListener('keypress', (event) => { const kc = event.keyCode; // 32->Space, 13->Enter if(kc == 32 || kc == 13) { toggleDfnPanel(dfnPanel, dfn); event.stopPropagation(); event.preventDefault(); } }); dfnPanel.addEventListener('click', (event) => { if (event.target.nodeName == 'A') { pinDfnPanel(dfnPanel); } event.stopPropagation(); }); dfnPanel.addEventListener('keydown', (event) => { if(event.keyCode == 27) { // Escape key hideDfnPanel(dfnPanel, dfn); event.stopPropagation(); event.preventDefault(); } }) } } </script> <script>/* Boilerplate: script-dfn-panel-json */ window.dfnpanelData = {}; window.dfnpanelData['atomic-rules'] = {"dfnID": "atomic-rules", "url": "#atomic-rules", "dfnText": "Atomic rules", "refSections": [{"refs": [{"id": "ref-for-atomic-rules"}], "title": "3. ACT Rule Types"}, {"refs": [{"id": "ref-for-atomic-rules\u2460"}], "title": "4.5. Rule Input"}, {"refs": [{"id": "ref-for-atomic-rules\u2461"}, {"id": "ref-for-atomic-rules\u2462"}], "title": "4.5.1. Input Aspects (Atomic rules only)"}, {"refs": [{"id": "ref-for-atomic-rules\u2463"}], "title": "4.5.2. Input Rules (Composite rules only)"}, {"refs": [{"id": "ref-for-atomic-rules\u2464"}], "title": "4.6.1. Applicability for Atomic Rules"}, {"refs": [{"id": "ref-for-atomic-rules\u2465"}], "title": "4.7.1. Expectations for Atomic Rules"}], "external": false}; window.dfnpanelData['composite-rules'] = {"dfnID": "composite-rules", "url": "#composite-rules", "dfnText": "Composite rules", "refSections": [{"refs": [{"id": "ref-for-composite-rules"}], "title": "4.5. Rule Input"}, {"refs": [{"id": "ref-for-composite-rules\u2460"}], "title": "4.5.2. Input Rules (Composite rules only)"}, {"refs": [{"id": "ref-for-composite-rules\u2461"}], "title": "4.7.2. Expectations for Composite Rules"}], "external": false}; window.dfnpanelData['descriptive-title'] = {"dfnID": "descriptive-title", "url": "#descriptive-title", "dfnText": "Descriptive Title", "refSections": [{"refs": [{"id": "ref-for-descriptive-title"}], "title": "4.5.2. Input Rules (Composite rules only)"}], "external": false}; window.dfnpanelData['conformance-requirements①'] = {"dfnID": "conformance-requirements\u2460", "url": "#conformance-requirements\u2460", "dfnText": "Conformance Requirements", "refSections": [{"refs": [{"id": "ref-for-conformance-requirements\u2460"}], "title": "4.9. Test Cases"}, {"refs": [{"id": "ref-for-conformance-requirements\u2460\u2460"}, {"id": "ref-for-conformance-requirements\u2460\u2461"}], "title": "4.14.1. Consistency"}], "external": false}; window.dfnpanelData['not-satisfied'] = {"dfnID": "not-satisfied", "url": "#not-satisfied", "dfnText": "not satisfied", "refSections": [{"refs": [{"id": "ref-for-not-satisfied"}], "title": "4.4.1.2. Secondary Requirements"}], "external": false}; window.dfnpanelData['satisfied'] = {"dfnID": "satisfied", "url": "#satisfied", "dfnText": "satisfied", "refSections": [{"refs": [{"id": "ref-for-satisfied"}], "title": "4.4.1.1. Conformance Requirements"}], "external": false}; window.dfnpanelData['secondary-requirements①'] = {"dfnID": "secondary-requirements\u2460", "url": "#secondary-requirements\u2460", "dfnText": "Secondary Requirements", "refSections": [{"refs": [{"id": "ref-for-secondary-requirements\u2460"}], "title": "4.14.1. Consistency"}], "external": false}; window.dfnpanelData['consistent'] = {"dfnID": "consistent", "url": "#consistent", "dfnText": "consistent", "refSections": [{"refs": [{"id": "ref-for-consistent"}], "title": "4.14.2. Partial Consistency"}, {"refs": [{"id": "ref-for-consistent\u2460"}, {"id": "ref-for-consistent\u2461"}], "title": "4.14.3. Consistency with multiple checks"}], "external": false}; window.dfnpanelData['true-positives'] = {"dfnID": "true-positives", "url": "#true-positives", "dfnText": "True positives", "refSections": [{"refs": [{"id": "ref-for-true-positives"}], "title": "4.14.2. Partial Consistency"}], "external": false}; window.dfnpanelData['partially-consistent'] = {"dfnID": "partially-consistent", "url": "#partially-consistent", "dfnText": "partially consistent", "refSections": [{"refs": [{"id": "ref-for-partially-consistent"}], "title": "4.14.3. Consistency with multiple checks"}], "external": false}; window.dfnpanelData['set-of-checks'] = {"dfnID": "set-of-checks", "url": "#set-of-checks", "dfnText": "set of checks", "refSections": [{"refs": [{"id": "ref-for-set-of-checks"}], "title": "4.14.3. Consistency with multiple checks"}], "external": false}; window.dfnpanelData['accessibility-requirement'] = {"dfnID": "accessibility-requirement", "url": "#accessibility-requirement", "dfnText": "Accessibility requirement", "refSections": [{"refs": [{"id": "ref-for-accessibility-requirement"}], "title": "1. Introduction"}, {"refs": [{"id": "ref-for-accessibility-requirement\u2460"}], "title": "2. Scope"}, {"refs": [{"id": "ref-for-accessibility-requirement\u2461"}], "title": "3. ACT Rule Types"}, {"refs": [{"id": "ref-for-accessibility-requirement\u2462"}, {"id": "ref-for-accessibility-requirement\u2463"}], "title": "4.4. Accessibility Requirements Mapping"}, {"refs": [{"id": "ref-for-accessibility-requirement\u2464"}], "title": "4.4.2. Mapping Outside WCAG"}, {"refs": [{"id": "ref-for-accessibility-requirement\u2465"}, {"id": "ref-for-accessibility-requirement\u2466"}], "title": "4.4.3. Rules Without Accessibility Requirements"}, {"refs": [{"id": "ref-for-accessibility-requirement\u2467"}], "title": "4.14. Implementations (optional)"}, {"refs": [{"id": "ref-for-accessibility-requirement\u2468"}, {"id": "ref-for-accessibility-requirement\u2460\u24ea"}], "title": "5. Rule Accuracy"}, {"refs": [{"id": "ref-for-accessibility-requirement\u2460\u2460"}, {"id": "ref-for-accessibility-requirement\u2460\u2461"}], "title": "7. Definitions"}], "external": false}; window.dfnpanelData['accessibility-requirements-document'] = {"dfnID": "accessibility-requirements-document", "url": "#accessibility-requirements-document", "dfnText": "Accessibility requirements document", "refSections": [{"refs": [{"id": "ref-for-accessibility-requirements-document"}], "title": "1. Introduction"}, {"refs": [{"id": "ref-for-accessibility-requirements-document\u2460"}, {"id": "ref-for-accessibility-requirements-document\u2461"}, {"id": "ref-for-accessibility-requirements-document\u2462"}], "title": "4.4. Accessibility Requirements Mapping"}, {"refs": [{"id": "ref-for-accessibility-requirements-document\u2463"}], "title": "4.4.2. Mapping Outside WCAG"}, {"refs": [{"id": "ref-for-accessibility-requirements-document\u2464"}, {"id": "ref-for-accessibility-requirements-document\u2465"}], "title": "4.4.3. Rules Without Accessibility Requirements"}, {"refs": [{"id": "ref-for-accessibility-requirements-document\u2466"}], "title": "4.4.4. External Accessibility Requirements Mapping"}, {"refs": [{"id": "ref-for-accessibility-requirements-document\u2467"}], "title": "4.14.1. Consistency"}], "external": false}; window.dfnpanelData['check'] = {"dfnID": "check", "url": "#check", "dfnText": "Check", "refSections": [{"refs": [{"id": "ref-for-check"}, {"id": "ref-for-check\u2460"}, {"id": "ref-for-check\u2461"}], "title": "4.14. Implementations (optional)"}, {"refs": [{"id": "ref-for-check\u2462"}, {"id": "ref-for-check\u2463"}, {"id": "ref-for-check\u2464"}, {"id": "ref-for-check\u2465"}], "title": "4.14.1. Consistency"}, {"refs": [{"id": "ref-for-check\u2466"}], "title": "4.14.2. Partial Consistency"}, {"refs": [{"id": "ref-for-check\u2467"}], "title": "4.14.3. Consistency with multiple checks"}, {"refs": [{"id": "ref-for-check\u2468"}], "title": "7. Definitions"}], "external": false}; window.dfnpanelData['implementation'] = {"dfnID": "implementation", "url": "#implementation", "dfnText": "Implementation", "refSections": [{"refs": [{"id": "ref-for-implementation"}, {"id": "ref-for-implementation\u2460"}], "title": "4.14. Implementations (optional)"}, {"refs": [{"id": "ref-for-implementation\u2461"}], "title": "4.14.3. Consistency with multiple checks"}], "external": false}; window.dfnpanelData['outcome'] = {"dfnID": "outcome", "url": "#outcome", "dfnText": "Outcome", "refSections": [{"refs": [{"id": "ref-for-outcome"}, {"id": "ref-for-outcome\u2460"}, {"id": "ref-for-outcome\u2461"}, {"id": "ref-for-outcome\u2462"}], "title": "3. ACT Rule Types"}, {"refs": [{"id": "ref-for-outcome\u2463"}], "title": "4.4. Accessibility Requirements Mapping"}, {"refs": [{"id": "ref-for-outcome\u2464"}], "title": "4.4.1. Outcome Mapping"}, {"refs": [{"id": "ref-for-outcome\u2465"}], "title": "4.4.3. Rules Without Accessibility Requirements"}, {"refs": [{"id": "ref-for-outcome\u2466"}], "title": "4.5.2. Input Rules (Composite rules only)"}, {"refs": [{"id": "ref-for-outcome\u2467"}], "title": "4.7. Expectations"}, {"refs": [{"id": "ref-for-outcome\u2468"}], "title": "4.7.1. Expectations for Atomic Rules"}, {"refs": [{"id": "ref-for-outcome\u2460\u24ea"}], "title": "4.7.2. Expectations for Composite Rules"}, {"refs": [{"id": "ref-for-outcome\u2460\u2460"}], "title": "4.9. Test Cases"}, {"refs": [{"id": "ref-for-outcome\u2460\u2461"}], "title": "4.12. Glossary"}, {"refs": [{"id": "ref-for-outcome\u2460\u2462"}], "title": "4.13. Issues List (optional)"}, {"refs": [{"id": "ref-for-outcome\u2460\u2463"}], "title": "4.14. Implementations (optional)"}, {"refs": [{"id": "ref-for-outcome\u2460\u2464"}], "title": "4.14.3. Consistency with multiple checks"}, {"refs": [{"id": "ref-for-outcome\u2460\u2465"}], "title": "7. Definitions"}], "external": false}; window.dfnpanelData['test-subject'] = {"dfnID": "test-subject", "url": "#test-subject", "dfnText": "Test Subject", "refSections": [{"refs": [{"id": "ref-for-test-subject"}, {"id": "ref-for-test-subject\u2460"}], "title": "3. ACT Rule Types"}, {"refs": [{"id": "ref-for-test-subject\u2461"}], "title": "4.4.1. Outcome Mapping"}, {"refs": [{"id": "ref-for-test-subject\u2462"}], "title": "4.5. Rule Input"}, {"refs": [{"id": "ref-for-test-subject\u2463"}], "title": "4.5.1. Input Aspects (Atomic rules only)"}, {"refs": [{"id": "ref-for-test-subject\u2464"}], "title": "4.6. Applicability"}, {"refs": [{"id": "ref-for-test-subject\u2465"}], "title": "4.6.1. Applicability for Atomic Rules"}, {"refs": [{"id": "ref-for-test-subject\u2466"}, {"id": "ref-for-test-subject\u2467"}, {"id": "ref-for-test-subject\u2468"}], "title": "7. Definitions"}], "external": false}; window.dfnpanelData['test-target'] = {"dfnID": "test-target", "url": "#test-target", "dfnText": "Test Target", "refSections": [{"refs": [{"id": "ref-for-test-target"}], "title": "3. ACT Rule Types"}, {"refs": [{"id": "ref-for-test-target\u2460"}], "title": "4.5.2. Input Rules (Composite rules only)"}, {"refs": [{"id": "ref-for-test-target\u2461"}], "title": "4.6.1. Applicability for Atomic Rules"}, {"refs": [{"id": "ref-for-test-target\u2462"}, {"id": "ref-for-test-target\u2463"}], "title": "4.7. Expectations"}, {"refs": [{"id": "ref-for-test-target\u2464"}], "title": "4.7.1. Expectations for Atomic Rules"}, {"refs": [{"id": "ref-for-test-target\u2465"}], "title": "4.7.2. Expectations for Composite Rules"}, {"refs": [{"id": "ref-for-test-target\u2466"}, {"id": "ref-for-test-target\u2467"}], "title": "5. Rule Accuracy"}, {"refs": [{"id": "ref-for-test-target\u2468"}, {"id": "ref-for-test-target\u2460\u24ea"}, {"id": "ref-for-test-target\u2460\u2460"}, {"id": "ref-for-test-target\u2460\u2461"}], "title": "7. Definitions"}], "external": false}; </script> <script>/* Boilerplate: script-dom-helper */ function query(sel) { return document.querySelector(sel); } function queryAll(sel) { return [...document.querySelectorAll(sel)]; } function iter(obj) { if(!obj) return []; var it = obj[Symbol.iterator]; if(it) return it; return Object.entries(obj); } function mk(tagname, attrs, ...children) { const el = document.createElement(tagname); for(const [k,v] of iter(attrs)) { if(k.slice(0,3) == "_on") { const eventName = k.slice(3); el.addEventListener(eventName, v); } else if(k[0] == "_") { // property, not attribute el[k.slice(1)] = v; } else { if(v === false || v == null) { continue; } else if(v === true) { el.setAttribute(k, ""); continue; } else { el.setAttribute(k, v); } } } append(el, children); return el; } /* Create shortcuts for every known HTML element */ [ "a", "abbr", "acronym", "address", "applet", "area", "article", "aside", "audio", "b", "base", "basefont", "bdo", "big", "blockquote", "body", "br", "button", "canvas", "caption", "center", "cite", "code", "col", "colgroup", "datalist", "dd", "del", "details", "dfn", "dialog", "div", "dl", "dt", "em", "embed", "fieldset", "figcaption", "figure", "font", "footer", "form", "frame", "frameset", "head", "header", "h1", "h2", "h3", "h4", "h5", "h6", "hr", "html", "i", "iframe", "img", "input", "ins", "kbd", "label", "legend", "li", "link", "main", "map", "mark", "meta", "meter", "nav", "nobr", "noscript", "object", "ol", "optgroup", "option", "output", "p", "param", "pre", "progress", "q", "s", "samp", "script", "section", "select", "small", "source", "span", "strike", "strong", "style", "sub", "summary", "sup", "table", "tbody", "td", "template", "textarea", "tfoot", "th", "thead", "time", "title", "tr", "u", "ul", "var", "video", "wbr", "xmp", ].forEach(tagname=>{ mk[tagname] = (...args) => mk(tagname, ...args); }); function* nodesFromChildList(children) { for(const child of children.flat(Infinity)) { if(child instanceof Node) { yield child; } else { yield new Text(child); } } } function append(el, ...children) { for(const child of nodesFromChildList(children)) { if(el instanceof Node) el.appendChild(child); else el.push(child); } return el; } function insertAfter(el, ...children) { for(const child of nodesFromChildList(children)) { el.parentNode.insertBefore(child, el.nextSibling); } return el; } function clearContents(el) { el.innerHTML = ""; return el; } function parseHTML(markup) { if(markup.toLowerCase().trim().indexOf('<!doctype') === 0) { const doc = document.implementation.createHTMLDocument(""); doc.documentElement.innerHTML = markup; return doc; } else { const el = mk.template({}); el.innerHTML = markup; return el.content; } } </script>