search

solex2006 / SELIProject

SELI Project
9 stars 17 forks source link

The Accessible Name of the control contains or match the text of the Visible Label #119

Open ecureuill opened 4 years ago

ecureuill commented 4 years ago

This is a "not-end" requirement. What I want to mean is that this should be considered for any new page you create that Student can access. Also should correct the old pages.

I will use the label Feature Design Notes to this cases

WCAG: 2.5.3

For user interface components with labels that include text or images of text, the name contains the text that is presented visually. So The speech-based navigation could be suscessul.

:warning: When the accessible name is different from the visible label, the speech-based navigation fails because the visible label spoken by the users does not match (or is not part of) the accessible name that is enabled as a speech-input command. In addition, it may function as a hidden command that can be accidentally activated by speech-input users.

:warning: Mismatches create an extra cognitive load for speech-input users, who must remember to say a speech command that is different from the visible label they see on a control. It also creates extra cognitive load for a text-to-speech user to absorb and understand speech output that does not match the visible label.

A best practice is to have the text of the label at the start of the name.

:information_source: In order for the label text and accessible name to be matched, it is first necessary to determine which text on the screen should be considered a label for any given control. There are often multiple text strings in a user interface that may be relevant to a control. However, there are reasons why it is best to conservatively interpret the label as being only the text in close proximity. Conventionally the label for user interface components is the adjacent text string. The typical positioning for left to right languages is (see more):

:warning: Note that placeholder text within an input field is not considered an appropriate means of providing a label. The HTML5 specification states The placeholder attribute should not be used as an alternative to a

Symbolic text characters

For the purposes of this, text should not be considered a visible label if it is used in a symbolic manner, rather than directly expressing something in human language a

image

In such a case, the accessible name should be the function the button serves (e.g., "Spell check" or "Check spelling"), not the visible symbolic characters. A similar text editor is shown in the figure below.

Punctuation and capitalization

The use of punctuation and capitalization in labels may also be considered optional for the same reason. For example, the colon conventionally added at the end of input labels does not express something in human language, and capitals on the first letter of each word in a label do not normally alter the words' meaning. This is particularly relevant in the context of this SC, since it is primarily aimed at users of speech recognition; capitals and most punctuation are frequently ignored when a user speaks a label as a means of interacting with a control.

While it is certainly not an error to include the colon and capitalization in the accessible name, a computed name of "First name" should not be considered a failure of "First Name:". image Likewise, "Next…" visibly shown on a button could have "Next" as the accessible name. When in doubt, where a meaningful visible label exists, match the string exactly for the accessible name. image

Mathematical expressions and formulae

Mathematical expressions are an exception to the previous subsection about symbolic characters. Math symbols can be used as labels; for example "11×3=33" and "A>B" convey meaning. The label should not be overwritten in the accessible name, and substitutions of words where a formula is used should be avoided since there are multiple ways to express the same equation. (...) The name should match the label's formula text. Note that a consideration for authors is to use the proper symbol in the formula. For instance 11x3 (with a lower or upper case letter X), 11*3 (with the asterisk symbol), and 11×3 (with the × symbol) are all easy for sighted users to interpret as meaning the same formula, but may not all be matched to "11 times 3" by the speech recognition software. The proper operator symbol (in this case the times symbol) should be used.

Accessible Name and Description Computation specification

It is important to understand how the accessible name is derived. The Accessible Name and Description Computation 1.1 and the HTML Accessibility API Mappings 1.0 describe how the accessible name is computed, including which attributes are considered in its calculation, and in what order of preference. If a component has multiple possible attribute values that could be used for its accessible name, only the most preferred of those values will be computed. None of the other, less preferred values will be part of the name. For the most part, existing established programmatic relationships between labels and controls are reinforced by the specification.

Other text displayed on the screen that is correctly coded to meet #76 is not normally factored into the calculation for the accessible name of a UI component without author intervention (via ARIA labeling techniques). The most common of these are:

Such textual information may constitute part of the component's description. 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 labels for the purpose of this Success Criterion.

It is important to note that the specification allows authors to override the name calculated through native semantics. Both aria-label and aria-labelledbytake 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, aria-label should be avoided or used carefully, and aria-labelledby should be used as a supplement with care.

Finally, aria-describedby 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 aria-describedby 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.

Examples for including the text of the visible...

Example 1: Link text matches the beginning of the accessible name

A link contains visible text and hidden link text. Both together make up the link's accessible name. The visible text comes first. The idea is to make the link more descriptive for users of assistive technologies.

<p>Go to <a href="code-of-conduct.html">Code of conduct <span class="hidden_accessibly"> of ACME Corporation</span></a><p>

Example 2: Generic link text concatenated with heading

A generic link is combined with the heading of the paragraph to give context. It is a variation on the first example, this time using aria-labelledby. The advantage of this implementation is that it uses existing visible text on the page, and so is more likely to be properly translated during any localization transformations.

<h4 id="poor">Insufficient Link Names Invade Community</h4>
<p>Citizens are reeling from the growing invasion of useless "read more" links appearing in their online resources. <a href="poor.html" aria-labelledby="generic poor"><span id="generic">More...</span></a>

Insufficient Link Names Invade Community [The following link opens nothing] Citizens are reeling from the growing invasion of useless "read more" links appearing in their online resources. More...

Example 3: Link text included in aria-label

Where two strings cannot be grammatically or seamlessly combined using aria-labelledby, aria-label can be used to make a new name which includes the visible label.

...end of news story. <a href="poor.html" aria-label="Read more about Insufficient link names">Read more</a>

Example 4: The visible button text matches the beginning of the accessible name

The visible text inside a button element matches the beginning of accessible name, which also includes hidden text. The idea of the hidden text is to make the button more descriptive for users of assistive technologies. <button>Send <span class="accessibly-hidden"> Mail</span></button>

Examples for matching

Example 1: Anchor text provides both the link's label and its accessible name

Using conventional HTML, the text between the anchor element's tags provides both the link's visible text and the accessible name "Code of conduct": <p>Go to our <a href="url-to-page-about-code.html">Code of conduct</a></p>

Example 2: Text in label element provides name for input via for attribute

The text between the label tags also serves as the checkbox input's accessible name "Notify me of delays" by using the for attribute which references the id of the input.

<input type="checkbox" id="notification" name="notify" value="delays">
<label for="notification">Notify me of delays</label>

Example 3: The button text provides the accessible name

The text inside a button element becomes both its visible label and its accessible name: `

Example 4: Simple Radio Button Group

Radio buttons typically appear in a group, where each button is labelled and the group of buttons is preceded by information which explains or categorizes the group.

Call me when balance exceeds $10,000, Yes No

The label for each component should be restricted to "Yes" and "No". To meet #76 and #132, the "Call me…" text can be coded to convey the relationship to ATs, in this example by using a fieldset and legend.

If the label is not restricted to the string adjacent to the radio button, multiple interpretations of what constitutes the label can result in less uniform functionality. If "Yes" alone is not the label for the first radio button, is it "Call me when balance exceeds $10,000"? Or is it a combination of text strings, in which case is the order "Call me when balance exceeds $10,000 Yes" or "Yes, Call me when balance exceeds $10,000"? Decisions to combine text strings can have negative effects on screen reader users since the order of concatenation can affect meaning. In this example, "No, call me when balance exceeds $10,000" could be very confusing to a screen reader user.

<fieldset>
<legend>Call me when balance exceeds $10,000?</legend><br />
<input type="radio" id="yes" name="callme" value="yes">
<label for="yes">Yes</label>
<input type="radio" id="no" name="callme" value="no">
<label for="no">No</label>
</fieldset>

Live-demo

Example 5: Checkbox Groupings

For checkbox groupings, implementations that attempt to incorporate more than just the immediate checkbox label into the accessible name can also be problematic if not isolated to the adjacent text string. What do you value in our service? (Check all that apply) Courtesy, Promptness, Store Hours, Knowledge In Figure 2, there is a long text string that combines a group label and instruction, "What do you value in our service (check all that apply)?" Each of the checkboxes also has its own one- or two-word label. In regard to #119, the labels for the components should be restricted to "Courtesy", "Promptness", "Store Hours" and "Knowledge".

Attempting to include the preceding text as part of the accessible name can potentially make it more difficult to isolate a control by spoken commands for speech-input users. Such a construction will also negatively increase verbosity for screen reader users (with the combined text strings read out for each of the inputs before the input's state). The simplest solution is to restrict the accessible name to the text immediately beside the checkboxes, using similar techniques to those for the standard radio button group.

Example 6: Stacked Labels

Although labels for comboboxes, dropdown lists, text inputs, and other widgets are typically oriented immediately to the left of the component, there is an alternative established convention where labels are stacked above the inputs, aligned with their left edge. two inputs labelled Email and Password In Figure 3, the inputs are stacked and left-aligned, with the labels immediately preceding each input, also left-aligned. There is additional white space between the label and the preceding input so that the label is closest to its associated text input. Stacked labels are relatively common in mobile designs, where horizontal space is constrained.

Figure 4 shows a variation on stacked labels, where hints and guidance are included between the label and the input. This design does not provide an adjacent label. However, the "New Password" label is still considered to be in close enough proximity, especially given its size and boldness relative to the smaller and lower-contrast guidance text. The associations are reinforced programmatically, where the hint text is given a role of aria-describedby and the label is properly associated with the input. New Password. Passwords must be 10 or more characters, and contain at least one capital, numeric and non-alphanumeric.' The hint text in such implementations should be kept to a single line where possible, since accessibility issues can arise where a more lengthy hint separates the label from its input. Figure 4 illustrates that the concept of "adjacent text" is a guide for label interpretation, but cannot always serve as a hard rule.

<form>
<label class="label" for="example-2">
Password
</label>
<span id="example-2-hint" class="hint">
Passwords must be 10 or more characters, and contain at least one capital, numeric and non-alphanumeric.
</span>
<input class="input" id="example-2" name="example-2" type="text" aria-describedby="example-2-hint">
</form>

Live-demo

Example 7: Range of inputs with few labels

A less common disparity between labels and inputs can occur when a group of radio buttons is set up to elicit a choice across a range. The labels may only be located at each end of the range or may be interspersed at various points in the range. Rate your response, Hated it, Loved it The two labels, "Hated it" and "Loved it", are adjacent to the first and last radio buttons, and should be their accessible names. Speech-input users can speak either of these labels to select a radio button, and then use arrow navigation (e.g., "Press right arrow") to modify the selection. "Rate your response" is the text describing the whole widget and can be associated as the group label (here using legend). The three middle radio buttons do not have visible labels. In the code example they are given title attributes of "Disliked", "So-so" and "Liked" in order to meet #132 

<fieldset>
<legend>Rate your response</legend>
<label for="hated">Hated it</label>
<input type="radio" name="meal" id="hated" value="hated">
<input type="radio" name="meal" id="poor" value="poor" title="Disliked">
<input type="radio" name="meal" id="neutral" value="neutral" title="So-so">
<input type="radio" name="meal" id="okay" value="okay" title="Liked">
<input type="radio" name="meal" id="loved" value="loved">
<label for="loved">Loved it</label>
</fieldset>

Live-demo

Tests Procedure

  1. For input controls, examine each input that has adjacent text which serves as its label
    1. For each input, check that the entire string of text (disregarding letter case and punctuation) matches the accessible name for the input, according to the accessible name computation
  2. For buttons, links, menus and other non-input controls, examine each control that contains text which serves as its label
    1. For each non-input control, check that the entire string of text (disregarding letter case and punctuation) matches the accessible name for the input; OR
      1. The accessible name of the control contains the same letters in the same order as the visible label.

Expected Results: Check 1 or 2 are true.

github-actions[bot] commented 4 years ago

This Feature is ready to be implemented.

ecureuill commented 3 years ago

Failures

Course Conten