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

Fixes to WCAG 2.1 Understanding 2.4.6 and 3.3.2 #612

Merged
merged 15 commits into from
Feb 19, 2019
Merged
Show file tree
Hide file tree
Changes from 10 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
51 changes: 24 additions & 27 deletions understanding/20/headings-and-labels.html
Original file line number Diff line number Diff line change
Expand Up @@ -26,46 +26,43 @@ <h2>Intent of Headings and Labels</h2>

<div class="note">

<p>This success criterion does not require headings or labels. This success criterion
requires that if headings or labels are provided, they be descriptive. Also note that,
if headings or labels are provided, they must meet
<a href="info-and-relationships">1.3.1: Info and Relationships</a>.
<p>This Success Criterion does not require headings or labels. This Success Criterion
requires that if headings or labels are provided, they be descriptive. This Success Criterion also
does not require that content acting as a heading or label be correctly marked up or
identified - this aspect is covered separately by
<a href="info-and-relationships">1.3.1: Info and Relationships</a>. It is possible for content
to pass this Success Criterion (providing descriptive content that acts as headings or labels) while failing
Success Criterion 1.3.1 (if the headings or labels aren't correctly marked up/identified). Conversely,
it is also possible for content to pass Success Criterion 1.3.1 (with headings or labels correctly
marked up/identified), while failing this Success Criterion (if those headings or labels are not
sufficiently clear or descriptive).
</p>

<p>Further, in the case of labels, this Success Criterion does not take into consideration whether or not
alternative methods of providing an accessible name for form controls and inputs has been
used - this aspect is covered separately by <a href="name-role-value">4.1.2: Name, Role and Value</a>. It is possible
for controls and inputs to have an appropriate accessible name (e.g. using <code>aria-label="..."</code>)
and therefore pass Success Criterion 4.1.2, but to still fail this Success Criterion (if the label is not
sufficiently clear or descriptive).
</p>
<p>While this Success Criterion does not <em>require</em> the use of labels (only ensuring that if labels
are present, they must be sufficiently clear or descriptive), this aspect is covered separately by
<a href="labels-or-instructions">3.3.2: Labels or Instructions</a>.
</p>
</div>


</section>
<section id="benefits">
<h2>Benefits of Headings and Labels</h2>


<ul>

<li>Descriptive headings are especially helpful for users who have disabilities that make
reading slow and for people with limited short-term memory. These people benefit when
section titles make it possible to predict what each section contains.
</li>

<li>People who have difficulty using their hands or who experience pain when doing so
will benefit from techniques that reduce the number of keystrokes required to reach
the content they need.
</li>

<li>

<p>This Success Criterion helps people who use screen readers by ensuring that labels
and headings are meaningful when read out of context, for example, in a Table of Contents,
or when jumping from heading to heading within a page.
</p>

<p>This Success Criterion may also help users with low vision who can see only a few
words at a time.

</p>

</li>


<li>When headings and labels are also correctly marked up and identified in accordance with <a href="info-and-relationships">1.3.1: Info and Relationships</a>, this Success Criterion helps people who use screen readers by ensuring that labels and headings are meaningful when read out of context, for example, in an automatically generated list of headings/table of contents, or when jumping from heading to heading within a page.</li>

patrickhlauke marked this conversation as resolved.
Show resolved Hide resolved
</ul>

</section>
Expand Down
53 changes: 30 additions & 23 deletions understanding/20/labels-or-instructions.html
Original file line number Diff line number Diff line change
Expand Up @@ -13,7 +13,7 @@ <h1>Understanding Labels or Instructions</h1>
<h2>Intent of Labels or Instructions</h2>


<p>The intent of this success criterion is to have content authors place instructions
<p>The intent of this Success Criterion is to have content authors place instructions
or labels that identify the controls in a form so that users know what input data
is expected. Instructions or labels may also specify data formats for fields especially
if they are out of the customary formats or if there are specific rules for correct
Expand All @@ -31,12 +31,24 @@ <h2>Intent of Labels or Instructions</h2>

<div class="note">

<p>When labels are provided for input objects, the input object's relationship to the
label (or to redundant text serving as the label) must be programmatically determinable
or available in text per
<a href="info-and-relationships">1.3.1: Info and Relationships</a>.
<p>This Success Criterion does not require that labels or instructions be correctly marked up or
identified/associated with their respective controls - this aspect is covered separately by
<a href="info-and-relationships">1.3.1: Info and Relationships</a>. It is possible for content
to pass this Success Criterion (providing relevant labels and instructions) while failing
Success Criterion 1.3.1 (if the labels or instructions aren't correctly marked up/identified/associated).
</p>

<p>Further, this Success Criterion does not take into consideration whether or not alternative methods of
providing an accessible name or description for form controls and inputs has been used - this aspect is
covered separately by <a href="name-role-value">4.1.2: Name, Role and Value</a>. It is possible
for controls and inputs to have an appropriate accessible name or description (e.g. using <code>aria-label="..."</code>)
and therefore pass Success Criterion 4.1.2, but to still fail this Success Criterion (if the labels or instructions
aren't presented to all users, not just those using assistive technologies).
</p>
<p>While this Success Criterion <em>requires</em> the use of labels for controls and inputs, whether or not
these labels are sufficiently clear or descriptive is covered separately by
<a href="labels-or-instructions">2.4.6: Headings and Labels</a>.
</p>

</div>


Expand All @@ -47,24 +59,14 @@ <h2>Benefits of Labels or Instructions</h2>

<ul>

<li>When label elements are associated with input elements the label is spoken by screen
readers when the field receives focus and users with impaired motor control are helped
by a larger clickable area for the control, since clicking on the label or the control
will activate the control.
</li>

<li>Field labels located in close proximity to the associated field assist users of screen
magnifiers because the field and label are more likely to visible within the magnified
area of the page.
<li>Providing clear and unambiguous labels and instructions (including examples of expected
data formats) helps all users - but particularly those with cognitive, language and learning
patrickhlauke marked this conversation as resolved.
Show resolved Hide resolved
disabilities - to enter information correctly.
</li>

<li>Providing examples of expected data formats help users with cognitive, language and
learning disabilities to enter information correctly.
</li>

<li>Clearly identifying required fields prevents a keyboard only user from submitting
an incomplete form and having to navigate the redisplayed form to find the uncompleted
field and provide the missing information.
<li>Providing clear and unambiguous labels and instructions (including clear identification of required
fields) can prevent users from making incomplete or incorrect form submissions, which prevents
users from having to navigate once more through a page/form in order to fix submission errors.
</li>

</ul>
Expand Down Expand Up @@ -95,11 +97,16 @@ <h2>Examples of Labels or Instructions</h2>
fields. While the punctuation provides visual clues to those familiar with the U.S.
telephone number format, the punctuation is not sufficient to label the fields. The
single "Phone number" label also cannot label all three fields. To address this, the
three fields are grouped in a fieldset with the legend "Phone number". Visual labels for the fields (beyond the punctuation) cannot be provided
three fields are grouped in a fieldset with the legend "Phone number". Visual labels for
the fields (beyond the punctuation) cannot be provided
in the design, so invisible labels are provided with the "title" attribute to each
of the three fields. The value of this attribute for the three fields are, respectively,
"Area Code", "Exchange", and "Number".
</li>

<li>In a form which contains both required and optional fields, the required fields and/or the
optional fields are clearly labeled as such.
</li>

</ul>

Expand Down