Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jnurthen/issue1316 #2042

Closed
wants to merge 2 commits into from
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 9 additions & 6 deletions index.html
Original file line number Diff line number Diff line change
Expand Up @@ -143,7 +143,7 @@

preProcess: [ linkCrossReferences ],
postProcess: [ ariaAttributeReferences ],
xref: ["dom", "accname", "core-aam-1.2", "infra", "HTML"],
xref: ["dom", "accname-1.2", "core-aam-1.2", "infra", "HTML"],
definitionMap: []
};
</script>
Expand Down Expand Up @@ -3345,7 +3345,7 @@ <h2>Definition of Roles</h2>
<p>Authors SHOULD make each <rref>article</rref> in a <code>feed</code> focusable and ensure that the application scrolls an <rref>article</rref> into view when <a>user agent</a> focus is set on the <rref>article</rref> or one of its descendant elements. For example, in HTML, each <rref>article</rref> element should have a <code>tabindex</code> value of either <code>-1</code> or <code>0</code>.</p>
<p> When an <a>assistive technology</a> reading cursor moves from one <rref>article</rref> to another, <a>assistive technologies</a> SHOULD set user agent focus on the <rref>article</rref> that contains the reading cursor. If the reading cursor lands on a focusable element inside the <rref>article</rref>, the assistive technology MAY set focus on that element in lieu of setting focus on the containing <rref>article</rref>.</p>
<p>Because the ability to scroll to another <rref>article</rref> with an <a>assistive technology</a> reading cursor depends on the presence of another <rref>article</rref> in the page, authors SHOULD attempt to load additional <rref data-lt="article">articles</rref> before <a>user agent</a> focus reaches an <rref>article</rref> at either end of the set of <rref data-lt="article">articles</rref> that has been loaded. Alternatively, authors MAY include an <rref>article</rref> at either or both ends of the loaded set of <rref data-lt="article">articles</rref> that includes an element, such as a <rref>button</rref>, that lets the user request more <rref data-lt="article">articles</rref> to be loaded.</p>
<p>In addition to providing a brief label, authors MAY apply <pref>aria-describedby</pref> to <rref>article</rref> elements in a <code>feed</code> to suggest to screen readers which elements to speak after the label when users navigate by <rref>article</rref>. Screen readers MAY provide users with a way to quickly scan <code>feed</code> content by speaking both the label and <a>accessible description</a> when navigating by <rref>article</rref>, enabling the user to ignore repetitive or less important elements, such as embedded interaction widgets, that the author has left out of the description.</p>
<p>In addition to providing a brief label, authors MAY apply <pref>aria-describedby</pref> to <rref>article</rref> elements in a <code>feed</code> to suggest to screen readers which elements to speak after the label when users navigate by <rref>article</rref>. Screen readers MAY provide users with a way to quickly scan <code>feed</code> content by speaking both the label and <a class="informative">accessible description</a> when navigating by <rref>article</rref>, enabling the user to ignore repetitive or less important elements, such as embedded interaction widgets, that the author has left out of the description.</p>
<p> Authors SHOULD provide keyboard commands for moving focus among <rref data-lt="article">articles</rref> in a <code>feed</code> so users who do not utilize an assistive technology that provides <rref>article</rref> navigation features can use the keyboard to navigate the <code>feed</code>.</p>
<p>If the number of articles available in a <code>feed</code> supply is static, authors MAY specify <pref>aria-setsize</pref> on <rref>article</rref> elements in that <code>feed</code>. However, if the total number is extremely large, indefinite, or changes often, authors MAY set <pref>aria-setsize</pref> to <code>-1</code> to communicate the unknown size of the set.</p>
<p>See the <cite><a href="" class="practices"><abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> Authoring Practices</a></cite> for additional details on implementing a feed design pattern.</p>
Expand Down Expand Up @@ -4079,7 +4079,7 @@ <h5>Note regarding the ARIA 1.3 <code>image</code> role.</h5>
<rdef>img</rdef>
<div class="role-description">
<p>A container for a collection of [=elements=] that form an image. See synonym <rref>image</rref>.</p>
<p>An <code>img</code> can contain captions and descriptive text, as well as multiple image files that when viewed together give the impression of a single image. An <code>img</code> represents a single graphic within a document, whether or not it is formed by a collection of drawing <a>objects</a>. In order for an element with a <a>role</a> of <code>img</code> to be <a>perceivable</a>, authors MUST provide the element with an <a>accessible name</a>. This can be done using the <pref>aria-label</pref> or <pref>aria-labelledby</pref> attribute.</p>
<p>An <code>img</code> can contain captions and descriptive text, as well as multiple image files that when viewed together give the impression of a single image. An <code>img</code> represents a single graphic within a document, whether or not it is formed by a collection of drawing <a>objects</a>. In order for an element with a <a>role</a> of <code>img</code> to be <a>perceivable</a>, authors MUST provide the element with an <a class="informative">accessible name</a>. This can be done using the <pref>aria-label</pref> or <pref>aria-labelledby</pref> attribute.</p>
</div>
<table class="role-features">
<caption>Characteristics:</caption>
Expand Down Expand Up @@ -10300,8 +10300,11 @@ <h2>Translatable Attributes</h2>
<p>To be understandable by assistive technology users, the values of the following <a>states</a> and [=ARIA/properties=] are <a data-cite="html/dom.html#translatable-attributes">translatable attributes</a> and should be translated when a page is localized:</p>
<ul>
<li><pref>aria-label</pref></li>
<li><pref>aria-colindextext</pref></li>
<li><pref>aria-description</pref></li>
<li><pref>aria-placeholder</pref></li>
<li><pref>aria-roledescription</pref></li>
<li><pref>aria-rowindextext</pref></li>
<li><pref>aria-valuetext</pref></li>
</ul>
</section>
Expand Down Expand Up @@ -11230,7 +11233,7 @@ <h2>Definitions of States and Properties (all aria-* attributes)</h2>
<div class="property-description">
<p><a>Defines</a> a string value that describes or annotates the current element. See related <pref>aria-describedby</pref>.</p>
<p>The <pref>aria-description</pref> attribute is similar to <pref>aria-label</pref> in that both provide a flat string to associate with the element (an accessible description, and name, respectively). Unlike an accessible name, which is generally preferred to be concise, a description can provide more verbose information, as necessary.</p>
<p>The purpose of <pref>aria-description</pref> is the same as that of <pref>aria-describedby</pref>. It provides the user with additional descriptive text for the object. The most common <a>accessibility <abbr title="Application Programing Interfaces">API</abbr></a> mapping for a description is the <a>accessible description</a> property. User agents MUST give precedence to <pref>aria-describedby</pref> over <pref>aria-description</pref> when computing the accessible description property.</p>
<p>The purpose of <pref>aria-description</pref> is the same as that of <pref>aria-describedby</pref>. It provides the user with additional descriptive text for the object. The most common <a>accessibility <abbr title="Application Programing Interfaces">API</abbr></a> mapping for a description is the <a class="informative">accessible description</a> property. User agents MUST give precedence to <pref>aria-describedby</pref> over <pref>aria-description</pref> when computing the accessible description property.</p>
<p>In cases where providing a visible description is not the desired user experience, authors MAY set the accessible description of the element using <pref>aria-description</pref>. However, if the description text is available in the DOM, authors SHOULD NOT use <pref>aria-description</pref>, but should use one of the following instead:</p>
<ul>
<li>Authors SHOULD use <pref>aria-describedby</pref> when the related description or annotation elements contain a simple, small description that is best experienced as a flat string, rather than by having the user navigate to them.</li>
Expand Down Expand Up @@ -11934,7 +11937,7 @@ <h2>Definitions of States and Properties (all aria-* attributes)</h2>
<pdef>aria-label</pdef>
<div class="property-description">
<p><a>Defines</a> a string value that labels the current element. See related <pref>aria-labelledby</pref>.</p>
<p>The purpose of <pref>aria-label</pref> is the same as that of <pref>aria-labelledby</pref>. It provides the user with a recognizable name of the object. The most common <a>accessibility <abbr title="Application Programing Interfaces">API</abbr></a> mapping for a label is the <a>accessible name</a> property.</p>
<p>The purpose of <pref>aria-label</pref> is the same as that of <pref>aria-labelledby</pref>. It provides the user with a recognizable name of the object. The most common <a>accessibility <abbr title="Application Programing Interfaces">API</abbr></a> mapping for a label is the <a class="informative">accessible name</a> property.</p>
<p>Most host languages provide an attribute that could be used to name the element (e.g., the <code>title</code> attribute in [[HTML]]), yet this could present a browser tooltip. In the cases where DOM content or a tooltip is undesirable, authors MAY set the accessible name of the element using <pref>aria-label</pref>, if the element does not <a href="#prohibitedattributes">prohibit</a> use of the attribute. If the label text is available in the DOM (i.e. typically visible text content), authors SHOULD use <pref>aria-labelledby</pref> and SHOULD NOT use <pref>aria-label</pref>. There may be instances where the name of an element cannot be determined programmatically from the DOM, and there are cases where referencing DOM content is not the desired user experience. Authors MUST NOT specify <code>aria-label</code> on an element which has an explicit or implicit WAI-ARIA role where <code>aria-label</code> is <a href="#prohibitedattributes">prohibited</a>. As required by the <a href="#textalternativecomputation">accessible name and description computation</a>, user agents give precedence to <pref>aria-labelledby</pref> over <pref>aria-label</pref> when computing the accessible name property.</p>
</div>
<table class="property-features">
Expand Down Expand Up @@ -11969,7 +11972,7 @@ <h2>Definitions of States and Properties (all aria-* attributes)</h2>
<pdef>aria-labelledby</pdef>
<div class="property-description">
<p><a>Identifies</a> the <a>element</a> (or elements) that labels the current element. See related <pref>aria-label</pref> and <pref>aria-describedby</pref>.</p>
<p>The purpose of <pref>aria-labelledby</pref> is the same as that of <pref>aria-label</pref>. It provides the user with a recognizable name of the object. The most common <a>accessibility <abbr title="Application Programing Interfaces">API</abbr></a> mapping for a label is the <a>accessible name</a> property.</p>
<p>The purpose of <pref>aria-labelledby</pref> is the same as that of <pref>aria-label</pref>. It provides the user with a recognizable name of the object. The most common <a>accessibility <abbr title="Application Programing Interfaces">API</abbr></a> mapping for a label is the <a class="informative">accessible name</a> property.</p>
<p>If the interface is such that it is not possible to have a visible label on the screen, authors SHOULD use <pref>aria-label</pref> and SHOULD NOT use <pref>aria-labelledby</pref>. Authors MUST NOT specify <code>aria-labelledby</code> on an element which has an explicit or implicit WAI-ARIA role where <code>aria-labelledby</code> is <a href="#prohibitedattributes">prohibited</a>. As required by the <a href="#textalternativecomputation">accessible name and description computation</a>, user agents give precedence to <pref>aria-labelledby</pref> over <pref>aria-label</pref> when computing the accessible name property.</p>
<p>The <pref>aria-labelledby</pref> attribute is similar to <pref>aria-describedby</pref> in that both reference other elements to calculate a text alternative (an accessible name, and description, respectively). While a concise accessible name is preferable, a description can either be concise, or provide more verbose information.</p>
<!-- keep previous sentence synced with the associated description in #aria-describedby -->
Expand Down