Skip to content

Commit

Permalink
🤖 Deploy to GitHub Pages: 5d51bfb from branch refs/heads/main
Browse files Browse the repository at this point in the history
  • Loading branch information
w3cgruntbot committed Jul 25, 2024
1 parent 0e9b1d5 commit 78bf4bd
Show file tree
Hide file tree
Showing 11 changed files with 393 additions and 20 deletions.
4 changes: 2 additions & 2 deletions techniques/aria/ARIA22.html
Original file line number Diff line number Diff line change
Expand Up @@ -108,7 +108,7 @@ <h2 class="box-h box-h-icon">About this Technique</h2>
<section id="description">
<h2>Description</h2>
<p>
This technique uses the <code>status</code> role from the ARIA specification to notify Assistive Technologies (AT) when content has been updated with information about the user's or application's status. This is done by adding <code>role="status"</code> to the element that contains the <a href="/TR/WCAG/#dfn-status-messages">status message</a>. The aria live region role of <code>status</code> has an implicit <code>aria-live</code> value of <code>polite</code>, which allows a user to be notified via AT (such as a screen reader) when status messages are added. The role of <code>status</code> also has a default <code>aria-atomic</code> value of <code>true</code>, so that updates to the container marked with a role of <code>status</code> will result in the AT presenting the entire contents of the container to the user, including any author-defined labels (or additional nested elements). Such additional context can be critical where the status message text alone will not provide an equivalent to the visual experience. The content of the aria-live container is automatically read by the AT, without the AT having to focus on the place where the text is displayed. See <a href="https://www.w3.org/TR/wai-aria/#status">WAI-ARIA status (role)</a> for more details.</p>
This technique uses the <code>status</code> role from the ARIA specification to notify Assistive Technologies (AT) when content has been updated with information about the user's or application's status. This is done by adding <code>role="status"</code> to the element that contains the <a href="https://w3c.github.io/wcag/guidelines/22/#dfn-status-messages" target="terms">status message</a>. The aria live region role of <code>status</code> has an implicit <code>aria-live</code> value of <code>polite</code>, which allows a user to be notified via AT (such as a screen reader) when status messages are added. The role of <code>status</code> also has a default <code>aria-atomic</code> value of <code>true</code>, so that updates to the container marked with a role of <code>status</code> will result in the AT presenting the entire contents of the container to the user, including any author-defined labels (or additional nested elements). Such additional context can be critical where the status message text alone will not provide an equivalent to the visual experience. The content of the aria-live container is automatically read by the AT, without the AT having to focus on the place where the text is displayed. See <a href="https://www.w3.org/TR/wai-aria/#status">WAI-ARIA status (role)</a> for more details.</p>

</section>
<section id="examples">
Expand Down Expand Up @@ -140,7 +140,7 @@ <h3>Example 2: Updating the shopping cart status</h3>
<h2>Tests</h2>
<section class="test-procedure" id="procedure">
<h3>Procedure</h3>
<p>For each <a href="/TR/WCAG/#dfn-status-messages">status message</a>:</p>
<p>For each <a href="https://w3c.github.io/wcag/guidelines/22/#dfn-status-messages" target="terms">status message</a>:</p>
<ol>
<li>Check that the container destined to hold the status message has a <code class="language-html">role</code> attribute with a value of <code class="language-html">status</code> <em>before</em> the status message occurs.</li>
<li>Check that when the status message is triggered, it is inside the container.</li>
Expand Down
2 changes: 1 addition & 1 deletion techniques/client-side-script/SCR19.html
Original file line number Diff line number Diff line change
Expand Up @@ -203,7 +203,7 @@ <h2 class="box-h box-h-icon">About this Technique</h2>
<a href="http://usability.com.au/2008/09/accessible-forms-using-wcag-2-0/">Accessible Forms using WCAG 2.0</a>
</li>
<li>
<a href="/TR/WCAG/#dfn-change-of-context">Change of context definition</a>
<a href="https://w3c.github.io/wcag/guidelines/22/#dfn-change-of-context" target="terms">Change of context</a> definition
</li>
</ul>

Expand Down
2 changes: 1 addition & 1 deletion techniques/failures/F103.html
Original file line number Diff line number Diff line change
Expand Up @@ -104,7 +104,7 @@ <h2>Description</h2>
<li>the new content does not take focus (does not change context);</li>
<li>the new content provides information to the user on the outcome of an action, the state of an application, the progress of a process, or the existence of errors.</li>
</ol>
Where updated content does not conform to the <a href="/TR/WCAG/#dfn-status-messages">definition of status message</a>, a failure of 4.1.3 has not taken place.<p></p>
Where updated content does not conform to the definition of <a href="https://w3c.github.io/wcag/guidelines/22/#dfn-status-messages" target="terms">status messages</a>, a failure of 4.1.3 has not taken place.<p></p>
<p>The second step in this failure technique involves examining code. Where dynamic content meets the definition of a status message, its container can be examined for an appropriate WAI-ARIA role or property which allows it to be programmatically determinable as a status message. Currently there are only a small number of techniques available to indicate status messages to assistive technologies. They are:
</p><ul>
<li>the HTML <code class="language-html">output</code> element</li>
Expand Down
2 changes: 1 addition & 1 deletion techniques/failures/F109.html
Original file line number Diff line number Diff line change
Expand Up @@ -113,7 +113,7 @@ <h2>Description</h2>

<p>Requiring users to authenticate by entering a password or code in a different format from which it was originally created is a failure to meet Success Criteria 3.3.8 and 3.3.9 (unless alternative authentication methods are available). The string to be entered could include a password, verification code, or any string of characters the user has to remember or record to authenticate.</p>

<p>If a user is required to enter individual characters across multiple fields in a way that prevents pasting the password in a single action, it prevents use of a password manager or pasting from local copy of the password. This means users cannot avoid transcription, resulting in a <a href="https://w3c.github.io/wcag/understanding/accessible-authentication-minimum.html#dfn-cognitive-function-test">cognitive function test</a>. This applies irrespective of whether users are required to enter all characters in the string, or just a subset.</p>
<p>If a user is required to enter individual characters across multiple fields in a way that prevents pasting the password in a single action, it prevents use of a password manager or pasting from local copy of the password. This means users cannot avoid transcription, resulting in a <a href="https://w3c.github.io/wcag/guidelines/22/#dfn-cognitive-function-test" target="terms">cognitive function test</a>. This applies irrespective of whether users are required to enter all characters in the string, or just a subset.</p>

</section>

Expand Down
2 changes: 1 addition & 1 deletion techniques/failures/F61.html
Original file line number Diff line number Diff line change
Expand Up @@ -86,7 +86,7 @@ <h2 class="box-h box-h-icon">About this Technique</h2>


<section id="description"><h2>Description</h2>
<p> This document describes a failure that occurs when the content in the main <a href="/TR/WCAG/#dfn-viewport">viewport</a> viewport is automatically updated, and there is no option for a user to disable this behavior. </p>
<p> This document describes a failure that occurs when the content in the main <a href="https://w3c.github.io/wcag/guidelines/22/#dfn-viewport" target="terms">viewport</a> is automatically updated, and there is no option for a user to disable this behavior. </p>
<p>Two procedures are presented below to test for the existence of a failure against Success Criterion 3.2.5. Procedure 1 is the preferred procedure and assumes that content authors have access to the code that generates the viewport content.</p>
<p>However there may be instances where this may not be possible (eg: in certain content management systems, application environments such as django or ruby-on-rails, or content generated through scripting languages such as AJAX or PHP that are generated by third parties.) To that end, the second procedure is supplied to allow testing in these instances. Note that timeframes are indicative only, and that any change after any amount of time should be treated as a failure if the test otherwise does not pass the other step evaluations. </p>
</section><section id="examples"><h2>Examples</h2>
Expand Down
4 changes: 2 additions & 2 deletions techniques/general/G212.html
Original file line number Diff line number Diff line change
Expand Up @@ -121,7 +121,7 @@ <h3>Example 3: Using a native button in iOS or Android</h3>
<p>In native buttons in iOS and Android onclick events are triggered on the up-event by default.</p>
<div class="note">
<p class="note-title marker">Note</p>
<p>The WCAG standard itself applies to <a href="/TR/WCAG/#dfn-web-page-s">web pages at a URL</a>, and therefore this example is provided as helpful supplementary advice for those looking to implement the <a href="https://www.w3.org/WAI/standards-guidelines/wcag/non-web-ict/">WCAG2ICT</a> for native applications.</p>
<p>The WCAG standard itself applies to <a href="https://w3c.github.io/wcag/guidelines/22/#dfn-web-page-s" target="terms">web pages</a>, and therefore this example is provided as helpful supplementary advice for those looking to implement the <a href="https://www.w3.org/WAI/standards-guidelines/wcag/non-web-ict/">WCAG2ICT</a> for native applications.</p>
</div>
</section>
</section>
Expand All @@ -148,7 +148,7 @@ <h3>Procedure</h3>
<ol>
<li>Activate the down-event then move the pointer outside the target before triggering the up-event, and then release the pointer to trigger the up-event.</li>
<li>Check that the action was not triggered when the pointer is released outside of the hit area for the target.</li>
<li>If the action is triggered, check that the action is reversible.</li>
<li>If the action is triggered, check that the action is reversible.</li>
</ol>
</section>
<section class="test-results" id="expected-results">
Expand Down
2 changes: 1 addition & 1 deletion techniques/server-side-script/SVR3.html
Original file line number Diff line number Diff line change
Expand Up @@ -90,7 +90,7 @@ <h2 class="box-h box-h-icon">About this Technique</h2>
<section id="description">
<h2>Description</h2>
<p>The objective of this technique is to ensure that users can obtain an accessible version of content where both non-conforming and conforming versions are provided.</p>
<p><a href="https://w3c.github.io/wcag/understanding/conformance#conf-req1">Conformance Requirement 1</a> allows non-conforming pages to be included within the scope of conformance as long as they have a "<a href="/TR/WCAG/#dfn-conforming-alternate-versions">conforming alternate version</a>". It is not always possible for authors to include accessibility supported links to conforming content from within non-conforming content. Therefore, authors may need to rely on the use of Server Side Scripting technologies (ex. <abbr title="PHP: Hypertext Preprocessor">PHP</abbr>, <abbr title="Active Server Pages">ASP</abbr>, <abbr title="Java Server Pages">JSP</abbr>) to ensure that the non-conforming version can only be reached from a conforming page.</p>
<p><a href="https://w3c.github.io/wcag/understanding/conformance#conf-req1">Conformance Requirement 1</a> allows non-conforming pages to be included within the scope of conformance as long as they have a <a href="https://w3c.github.io/wcag/guidelines/22/#dfn-conforming-alternate-versions" target="terms">conforming alternate version</a>. It is not always possible for authors to include accessibility supported links to conforming content from within non-conforming content. Therefore, authors may need to rely on the use of Server Side Scripting technologies (ex. <abbr title="PHP: Hypertext Preprocessor">PHP</abbr>, <abbr title="Active Server Pages">ASP</abbr>, <abbr title="Java Server Pages">JSP</abbr>) to ensure that the non-conforming version can only be reached from a conforming page.</p>
<p>This technique describes how to use information provided by the HTTP referer to ensure that non-conforming content can only be reached from a conforming page. The HTTP referer header is set by the user agent and contains the <abbr title="Uniform Resource Identifier">URI</abbr> of the page (if any) which referred the user agent to the non-conforming page.</p>
<p>To implement this technique, an author identifies the URI for the conforming version of the content, for each non-conforming page. When a request for the non-conforming version of a page is received, the server compares the value of the HTTP referer header against the URI of the conforming version to determine whether the link to the non-conforming version came from the conforming version. The non-conforming version is only served if the HTTP referer matches the URI of the non-conforming version. Otherwise, the user is redirected to the conforming version of the content. Note that when comparing the URI in the HTTP referer header, non-relevant variations in the URI, such as in the query and target, should be taken into account.</p>
</section>
Expand Down
Loading

0 comments on commit 78bf4bd

Please sign in to comment.