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

Make Benefits consistently a top-level section with h2 in source files #3939

Merged
merged 2 commits into from
Aug 27, 2024
Merged
Show file tree
Hide file tree
Changes from 1 commit
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
29 changes: 14 additions & 15 deletions understanding/21/animation-from-interactions.html
Original file line number Diff line number Diff line change
Expand Up @@ -27,21 +27,20 @@ <h2>Intent</h2>

<p class="note">The impact of animation on people with vestibular disorders can be quite severe. Triggered reactions include nausea, migraine headaches, and potentially needing bed rest to recover.</p>

<p><strong>How can a website reduce the chances of triggering a vestibular disorder?</strong> Choose any one of the following solutions. Avoid using unnecessary animation. Provide a control for users to turn off non-essential animations from user interaction. Take advantage of the reduce motion feature in the user agent or operating system.</p>

<p><strong>What about movement caused by a user scrolling a page?</strong> Moving new content into the viewport is essential for scrolling. The user controls the essential scrolling movement so it is allowed. Only add non-essential animation to the scrolling interaction in a responsible way. Always give users the ability to turn off unnecessary movement.</p>

<section id="benefits">
<h3>Benefits</h3>
<ul>
<li><strong>Vestibular Disorder</strong>
<ul>
<li>People with vestibular disorders need control over movement triggered by interactions. Non-essential movement can trigger vestibular disorder reactions. Vestibular (inner ear) disorder reactions include distraction, dizziness, headaches and nausea.</li>
<li>Persona Quote: "Stop that extra movement! You are making me so dizzy I cannot concentrate. Now I have to turn off my computer and go lie down."</li>
</ul>
</li>
</ul>
</section>
<p><strong>How can a website reduce the chances of triggering a vestibular disorder?</strong> Choose any one of the following solutions. Avoid using unnecessary animation. Provide a control for users to turn off non-essential animations from user interaction. Take advantage of the reduce motion feature in the user agent or operating system.</p>

<p><strong>What about movement caused by a user scrolling a page?</strong> Moving new content into the viewport is essential for scrolling. The user controls the essential scrolling movement so it is allowed. Only add non-essential animation to the scrolling interaction in a responsible way. Always give users the ability to turn off unnecessary movement.</p>
</section>
<section id="benefits">
patrickhlauke marked this conversation as resolved.
Show resolved Hide resolved
<h2>Benefits</h2>
<ul>
<li><strong>Vestibular Disorder</strong>
<ul>
<li>People with vestibular disorders need control over movement triggered by interactions. Non-essential movement can trigger vestibular disorder reactions. Vestibular (inner ear) disorder reactions include distraction, dizziness, headaches and nausea.</li>
<li>Persona Quote: "Stop that extra movement! You are making me so dizzy I cannot concentrate. Now I have to turn off my computer and go lie down."</li>
</ul>
</li>
</ul>
</section>
<section id="examples">
<h2>Examples</h2>
Expand Down
16 changes: 8 additions & 8 deletions understanding/21/character-key-shortcuts.html
Original file line number Diff line number Diff line change
Expand Up @@ -30,14 +30,14 @@ <h3>Background on the mechanics of speech input:</h3>
<p>Single-key shortcuts are the exception. While using single letter keys as controls might be appropriate and efficient for many keyboard users, single-key shortcuts are disastrous for speech users. The reason for this is that when only a single key is used to trip a command, a spoken word can become a barrage of single-key commands if the cursor focus happens to be in the wrong place.</p>
<p>For example, a speech-input user named Kim has her cursor focus in the main window of a web mail application that uses common keyboard shortcuts to navigate ("k"), archive ("y") and mute messages ("m"). A coworker named Mike enters her office and says "Hey Kim" and her microphone picks that up. The Y of "hey" archives the current message. K in "Kim" moves down one conversation and M mutes a message or thread. And, if Kim looks up and says "Hey Mike" without remembering to turn off the microphone, the same three things happen in a different sequence.</p>
<p>A user interacting with a webpage or web app that doesn't use single-character shortcuts doesn't have this problem. Inadvertent strings of characters from the speech application are not interpreted as shortcuts if a modifier key is required. A speech user filling in a text input form may find that a phrase that is accidentally picked up by the speech microphone results in stray text being entered into the field, but that is easily seen and undone. The Resources section of this page contains links to videos demonstrating these types of issues.</p>
<section id="benefits">
<h3>Benefits</h3>
<ul>
<li>Speech users will be able to turn off single-key shortcuts so they can avoid accidentally firing batches of them at once. This will allow speech users to make full use of programs that offer single-key shortcuts to keyboard users.</li>
<li>Keyboard-only users who have dexterity challenges can also be prone to accidentally hitting keys. Those users would be able to avoid problematic single character shortcuts by turning them off or modifying them to include at least one non-character key.</li>
<li>Allowing <em>all</em> shortcut keys to be remapped can help users with some cognitive disabilities, since the same shortcuts can be assigned to perform the same actions across different applications.</li>
</ul>
</section>
</section>
<section id="benefits">
<h2>Benefits</h2>
<ul>
<li>Speech users will be able to turn off single-key shortcuts so they can avoid accidentally firing batches of them at once. This will allow speech users to make full use of programs that offer single-key shortcuts to keyboard users.</li>
<li>Keyboard-only users who have dexterity challenges can also be prone to accidentally hitting keys. Those users would be able to avoid problematic single character shortcuts by turning them off or modifying them to include at least one non-character key.</li>
<li>Allowing <em>all</em> shortcut keys to be remapped can help users with some cognitive disabilities, since the same shortcuts can be assigned to perform the same actions across different applications.</li>
</ul>
</section>
<section id="examples">
<h2>Examples</h2>
Expand Down
2 changes: 1 addition & 1 deletion understanding/21/concurrent-input-mechanisms.html
Original file line number Diff line number Diff line change
Expand Up @@ -26,7 +26,7 @@ <h2>Intent</h2>
<p>Note: A touch-typing web application, which teaches users how to touch-type on a keyboard and/or measures their proficiency and speed, would be an example of an essential limitation to a particular input mechanism. </p>
</section>
<section id="benefits">
<h3>Benefits</h3>
<h2>Benefits</h2>
<ul>
<li>Users can interact with web content with whichever input mechanism is preferred and available to them.</li>
<li>Users may switch between input mechanisms when they desire or the circumstances require it.</li>
Expand Down
16 changes: 8 additions & 8 deletions understanding/21/identify-changes.html
Original file line number Diff line number Diff line change
Expand Up @@ -10,13 +10,13 @@ <h1>Understanding {Shortname}</h1>
<section id="intent">
<h2>Intent</h2>
<p class="instructions">This section contains the main explanatory content of the Understanding. It explains why the Guideline or Success Criterion exists and, at a high level, how to meet it.</p>
<section id="benefits">
<h3>Benefits</h3>
<p class="instructions">This explains how following the success criterion benefits particular types of users with disabilities.</p>
<ul>
<li>Benefit</li>
</ul>
</section>
</section>
<section id="benefits">
<h2>Benefits</h2>
<p class="instructions">This explains how following the success criterion benefits particular types of users with disabilities.</p>
<ul>
<li>Benefit</li>
</ul>
</section>
<section id="examples">
<h2>Examples</h2>
Expand Down Expand Up @@ -74,4 +74,4 @@ <h2>Failure</h2>
</section>
</section>
</body>
</html>
</html>
13 changes: 0 additions & 13 deletions understanding/21/label-in-name.html
Original file line number Diff line number Diff line change
Expand Up @@ -90,19 +90,6 @@ <h4>Text in parentheses</h4>
<p>It is important to mention parenthetical text in labels in the context of accessible name versus description. In common usage, text in parentheses is considered secondary but relevant to meaning. Users of speech recognition would not typically announce text in parentheses as part of the input name. For that reason, parenthetical text may be optionally considered a description and left out of the accessible name.</p>
<p>However, where parenthetical information provides important context, such as indication of a required field or limitations on what is allowed for input, this information must be provided programmatically in some other way to the user if that information is not included as part of the accessible name. For example, "Name (required)" and "Date (YYYY-MM-DD)" could accept "Name" and "Date" as the accessible names. However, in order to pass 1.3.1 Info &amp; Relationships, authors would need to programmatically surface both the required state and the limit on the allowed data formatting (in this example, eight integers fitting the YYYY-MM-DD pattern). The "required" state could be surfaced through the HTML <code>required</code> attribute or by using <code>aria-required="true"</code>. The allowed data formatting could be surfaced by being referenced using the <code>aria-describedby</code>) attribute.</p>
</section>


<section id="benefits">
<h2>Benefits</h2>

<ul>
<li>headings and instructions</li>
<li>group labels for sets of components (i.e., used with <code>legend</code>/<code>fieldset</code> or with role of <code>group</code> or <code>radiogroup</code>)</li>
</ul>
<p>Such textual information may constitute part of the component's <em>description</em>. So from both a programmatic viewpoint, and from the conservative tactic of only considering a label to be "adjacent text," neither headings, instructions, nor group 'labels' should normally be considered <strong>labels</strong> for the purpose of this Success Criterion.</p>
<p>It is important to note that the specification allows authors to override the name calculated through native semantics. Both <code>aria-label</code> and <code>aria-labelledby</code> take precedence in the name calculation, overriding the visible text as the accessible name even when the visible text label is programmatically associated with the control. For this reason, when a visible label already exists, <code>aria-label</code> should be avoided or used carefully, and <code>aria-labelledby</code> should be used as a supplement with care.</p>
<p>Finally, <code>aria-describedby</code> is not included in the Accessible Name computation (instead it is part of the Accessible Description computation). By convention, text associated with a control through <code>aria-describedby</code> is announced immediately after the accessible name by screen readers. Therefore, the context of headings, instructions, and group labels can be provided through the accessible description to assist users of screen readers without affecting the experience of those who navigate using speech recognition software.</p>
</section>
</section>

<section id="benefits">
Expand Down
17 changes: 7 additions & 10 deletions understanding/21/motion-actuation.html
Original file line number Diff line number Diff line change
Expand Up @@ -28,16 +28,13 @@ <h2>Intent of this Success Criterion</h2>
<p>Devices often have sensors that can act as inputs, such as accelerometer and gyroscope sensors on a phone or tablet device. These sensors can allow the user to control something by simply changing the orientation or moving the device in particular ways. In other situations, web content can interpret user gestures via the camera or other sensors to actuate functions. For example, shaking the device might issue an "Undo" command, or a gentle hand wave might be used to move forward or backward in a sequence of pages. Some users with disabilities are not able to operate these device sensors (either not at all, or not precisely enough) because the device is on a fixed mount (perhaps a wheelchair) or due to motor impairments. Therefore, functionality offered through motion must also be available by another mechanism.</p>
<p>In addition, some users may accidentally activate sensors due to tremors or other motor impairments. The user must have the ability to turn off motion actuation to prevent such accidental triggering of functions. Applications may be able to meet this requirement by supporting operating system settings which allow the user to disable motion detection at the system level.</p>
<p>There is an exception where motion is essential for the function or not using motions or gestures would invalidate the activity. Some applications are specifically created to use device sensor data. Examples of content that are exempt from this requirement include a pedometer that relies on device motion to count steps.</p>


<section id="benefits">
<h3>Benefits</h3>

<ul>
<li>This Success Criterion helps people who may be unable to perform particular motions (such as tilting, shaking, or gesturing) because the device may be mounted or users may be physically unable to perform the necessary movement. This success criterion ensures that users can still operate all functionality by other means such as touch or via assistive technologies.</li>
<li>Other users will benefit in situations where they are unable to move their devices.</li>
</ul>
</section>
</section>
<section id="benefits">
<h2>Benefits</h2>
<ul>
<li>This Success Criterion helps people who may be unable to perform particular motions (such as tilting, shaking, or gesturing) because the device may be mounted or users may be physically unable to perform the necessary movement. This success criterion ensures that users can still operate all functionality by other means such as touch or via assistive technologies.</li>
<li>Other users will benefit in situations where they are unable to move their devices.</li>
</ul>
</section>
<section id="examples">
<h2>Examples of Success Criterion 2.6.1</h2>
Expand Down
15 changes: 7 additions & 8 deletions understanding/21/orientation.html
Original file line number Diff line number Diff line change
Expand Up @@ -42,14 +42,13 @@ <h3>Locking a device to an orientation</h3>
<p>This Success Criterion complements device "lock orientation" settings. A web page that does not restrict its display orientation will always support the system-level orientation setting, since the system setting is picked up by the user agent. Alternatively, where a device-level orientation lock is not in place, the user agent should display the page according to the orientation of the device (either its default, or the current orientation determined by any device sensors).</p>

<p>The exception for things considered essential is aimed at situations where the content would only be understood in a particular orientation, or where the technology restricts the possible orientations. If content is aimed at a specific environment which is only available in one orientation (such as a television) then the content can restrict the orientation. Technologies such as virtual reality use screens within goggles that cannot change orientation relative to the user's eyes.</p>

<section id="benefits">
<h3>Benefits</h3>
<ul>
<li>Users with dexterity impairments, who have a mounted device will be able to use the content in their fixed orientation.</li>
<li>Users with low-vision will be able to view content in the orientation that works best for them, for example to increase the text size by viewing content in landscape.</li>
</ul>
</section>
</section>
<section id="benefits">
<h2>Benefits</h2>
<ul>
<li>Users with dexterity impairments, who have a mounted device will be able to use the content in their fixed orientation.</li>
<li>Users with low-vision will be able to view content in the orientation that works best for them, for example to increase the text size by viewing content in landscape.</li>
</ul>
</section>
<section id="examples">
<h2>Examples</h2>
Expand Down
14 changes: 7 additions & 7 deletions understanding/21/pointer-cancellation.html
Original file line number Diff line number Diff line change
Expand Up @@ -56,13 +56,13 @@ <h3>Down-Event</h3>
</ul>
</section>
</section>
<section id="benefits">
<h3>Benefits</h3>
<ul>
<li>Makes it easier for all users to recover from hitting the wrong target.</li>
<li>Helps people with visual disabilities, cognitive limitations, and motor impairments by reducing the chance that a control will be accidentally activated or an action will occur unexpectedly, and also ensures that where complex controls are activated, a means of Undoing or Aborting the action is available.</li>
<li>Individuals who are unable to detect changes of context are less likely to become disoriented while navigating a site.</li>
</ul>
<section id="benefits">
<h2>Benefits</h2>
<ul>
<li>Makes it easier for all users to recover from hitting the wrong target.</li>
<li>Helps people with visual disabilities, cognitive limitations, and motor impairments by reducing the chance that a control will be accidentally activated or an action will occur unexpectedly, and also ensures that where complex controls are activated, a means of Undoing or Aborting the action is available.</li>
<li>Individuals who are unable to detect changes of context are less likely to become disoriented while navigating a site.</li>
</ul>
</section>
<section id="examples">
<h2>Examples</h2>
Expand Down
17 changes: 8 additions & 9 deletions understanding/21/pointer-gestures.html
Original file line number Diff line number Diff line change
Expand Up @@ -73,15 +73,14 @@ <h3>Challenges for people with disabilities</h3>
<p>An exception is made for functionality that is inherently and necessarily based on complex paths or multipoint gestures. For example, entering your signature may be inherently path-based (although acknowledging something or confirming your identity need not be).</p>

<p>This Success Criterion <em>does not apply</em> to gestures that involve dragging in any direction because only the start and end points matter in a dragging operation. However, such gestures do require fine motor control. Authors are encouraged to provide non-dragging methods, for instance, a drag and drop operation could also be achieved by selecting an item (with a tap or keyboard interaction) and then selecting its destination as a second step.</p>

<section id="benefits">
<h3>Benefits</h3>
<ul>
<li><p>Users who cannot (accurately) perform path-based pointer gestures - on a touchscreen, or with a mouse - will have alternative means for operating the content.</p></li>
<li><p>Users who cannot perform multi-pointer gestures on a touchscreen (for instance, because they are operating the touchscreen with an alternative input such as a head pointer) will have a single-pointer alternative for operating the content.</p></li>
<li><p>Users who may not understand the custom gesture interaction intended by the author will be able to rely on simple, frequently used gestures to interact. This can be especially beneficial for users with cognitive or learning disabilities.</p></li>
</ul>
</section>
</section>
<section id="benefits">
<h2>Benefits</h2>
<ul>
<li><p>Users who cannot (accurately) perform path-based pointer gestures - on a touchscreen, or with a mouse - will have alternative means for operating the content.</p></li>
<li><p>Users who cannot perform multi-pointer gestures on a touchscreen (for instance, because they are operating the touchscreen with an alternative input such as a head pointer) will have a single-pointer alternative for operating the content.</p></li>
<li><p>Users who may not understand the custom gesture interaction intended by the author will be able to rely on simple, frequently used gestures to interact. This can be especially beneficial for users with cognitive or learning disabilities.</p></li>
</ul>
</section>
<section id="examples">
<h2>Examples</h2>
Expand Down
2 changes: 1 addition & 1 deletion understanding/21/reflow.html
Original file line number Diff line number Diff line change
Expand Up @@ -71,7 +71,7 @@ <h3>Browsers on mobile operating systems</h3>
</section>

<section id="benefits">
<h3>Benefits</h3>
<h2>Benefits</h2>
<ul>
<li>This Success Criterion helps people with low vision who require text enlargement by enabling them to read the content seamlessly, eliminating the necessity to scroll in multiple directions.</li>
</ul>
Expand Down
Loading