A
A form may contain a mix of host language form controls, scripted controls, and hyperlinks. Authors are reminded to use native host language semantics to create form controls whenever possible. If the purpose of a form is to submit search criteria, authors SHOULD use the form role.
Authors MUST give each element with role form a brief label that describes the purpose of the form. Authors SHOULD reference a visible label with
Authors MUST give each element with role form a brief label that describes the purpose of the form. Authors SHOULD reference a visible label with
If an author uses a script to submit a form based on a user action that would otherwise not trigger an onsubmit event (for example, a form submission triggered by the user changing a form element's value), the author SHOULD provide the user with advance notification of the behavior.
User agents SHOULD treat elements with the role of form as navigational landmarks.
none role.aria-valuemax is missing or not a number, it defaults to 100.The author SHOULD supply a value for
The author SHOULD supply a value for progressbar is describing the loading progress of a particular region of a page, the author SHOULD use true on the region until it is finished loading. It is not possible for the user to alter the value of a progressbar because it is always read-only.
Assistive technologies generally will render the value of
Defines a human-readable, author-localized abbreviated description for the role of an element, which is intended to be converted into Braille. See related
Some assistive technologies, such as screen readers, present the role of an element as part of the user experience. Such assistive technologies typically localize the name of the role, and they may customize it as well. Users of these assistive technologies depend on the presentation of the role name, such as "region," "button," or "slider," for an understanding of the purpose of the element and, if it is a widget, how to interact with it.
+The aria-brailleroledescription property gives authors the ability to override how assistive technologies localize and express the name of a role in Braille. Thus inappropriately using aria-brailleroledescription may inhibit users' ability to understand or interact with an element on braille interfaces. Authors SHOULD limit use of aria-brailleroledescription to clarifying the purpose of non-interactive container roles like
Authors MUST NOT use aria-brailleroledescription without providing aria-roledescription. In general, aria-brailleroledescription should only be used in rare cases when a aria-roledescription is excessively verbose when rendered in Braille.
When using aria-brailleroledescription, authors SHOULD also ensure that:
aria-brailleroledescription is applied has a valid WAI-ARIA role or has an implicit WAI-ARIA role semantic.aria-brailleroledescription is not empty or does not contain only whitespace characters.aria-brailleroledescription does not contain any characters in Unicode Braille Patterns (U+2800..U+28FF) or consists of only characters in Unicode Braille Patterns (U+2800..U+28FF) while not only containing Braille Pattern dots-0 (U+2800).aria-brailleroledescription should not be identical to the element's WAI-ARIA aria-roledescription, WAI-ARIA role or implicit WAI-ARIA role semantic.Note that Assistive Technologies with braille support can convert aria-roledescription content to Braille. In addition, assistive technologies will be able to customize such braille output according to user preferences. Using only aria-roledescription is almost always the better user experience and authors are strongly discouraged from using aria-brailleroledescription to replicate aria-roledescription. Instead, aria-brailleroledescription is meant to be used only when aria-roledescription cannot provide an adequate braille representation, i.e., when a specialized braille description is very different from a text description converted to Braille. It is very important to note that when using aria-brailleroledescription authors are solely responsible to align the attribute value with the document language and clearly communicate the use of this attribute to the user. This is even more important when the value consists of Unicode Braille Patterns because Assistive Technologies will pass such content directly to the user without applying user specific braille translations; in general, authors are strongly discouraged from using Unicode Braille Patterns in aria-brailleroledescription.
+
User agents MUST NOT expose the aria-brailleroledescription property if any of the following conditions exist:
aria-brailleroledescription is applied does not have a valid WAI-ARIA role or does not have an implicit WAI-ARIA role semantic.aria-brailleroledescription is empty or contains only whitespace characters or contains only Braille Pattern dots-0 (U+2800).aria-brailleroledescription is applied does not have a valid WAI-ARIA aria-roledescription.Assistive technologies SHOULD use the value of aria-brailleroledescription when presenting the role of an element in Braille, but SHOULD NOT change other functionality based on the role of an element that has a value for aria-brailleroledescription. For example, an assistive technology that provides functions for navigating to the next aria-brailleroledescription.
Assistive technologies SHOULD expose the aria-brailleroledescription property as follows:
aria-brailleroledescription does not contain characters in Unicode Braille Patterns (U+2800..U+28FF), translate the value according to the user's preferred translation table.The following example shows the use of aria-brailleroledescription to indicate that a button's description has a particular braille contraction.
<button aria-roledescription="planet" aria-brailleroledescription="pln" id="jupiter"> +<img alt="jupiter" src="images/jupiter.jpg"/> +</button>+
In the previous example, a braille display may display "pln Jupiter" in Braille rather than the verbose "planet Jupiter".
+| Characteristic | +Value | +
|---|---|
| Used in Roles: | +All elements of the base markup | +
| Inherits into Roles: | +Placeholder | +
| Value: | +string | +
Defines a human-readable, author-localized Braille description for the role of an element.
-Some assistive technologies, such as screen readers, present the role of an element as part of the user experience. Such assistive technologies typically localize the name of the role, and they may customize it as well. Users of these assistive technologies depend on the presentation of the role name, such as "region," "button," or "slider," for an understanding of the purpose of the element and, if it is a widget, how to interact with it.
-The aria-brailleroledescription property gives authors the ability to override how assistive technologies localize and express the name of a role in Braille. Thus inappropriately using aria-brailleroledescription may inhibit users' ability to understand or interact with an element on Braille interfaces. Authors SHOULD limit use of aria-brailleroledescription to clarifying the purpose of non-interactive container roles like
Authors MUST NOT use aria-brailleroledescription without providing a more specific aria-roledescription. In general, aria-brailleroledescription should only be used in rare cases when a aria-roledescription does not suffice.
When using aria-brailleroledescription, authors SHOULD also ensure that:
aria-brailleroledescription is applied has a valid WAI-ARIA role or has an implicit WAI-ARIA role semantic.aria-brailleroledescription is not empty or does not contain only whitespace characters.aria-brailleroledescription consists of a string of either Unicode with no Unicode Braille Patterns (U+2800..U+28FF) or consists of a string of only Unicode Braille Patterns (U+2800..U+28FF) while not only containing Braille Pattern dots-0 (U+2800).Note that Assistive Technologies with Braille support can convert aria-roledescription content to Braille. In addition, assistive technologies will be able to customize such Braille output according to user preferences. Using only aria-roledescription is almost always the better user experience and authors are strongly discouraged from using aria-brailleroledescription to replicate aria-roledescription. Instead, aria-brailleroledescription is meant be used only when aria-roledescription cannot provide an adequate Braille representation, i.e., when a specialized Braille description is very different from a text description converted to Braille. It is very important to note that when using aria-brailleroledescription authors are solely responsible to align the attribute value with the document language and clearly communicate the use of this attribute to the user. This is even more important when the value consists of Unicode Braille Patterns because Assistive technologies will pass such content directly to the user without applying user specific Braille translations; in general, authors are strongly discouraged from using Unicode Braille Patterns in aria-brailleroledescription.
-
User agents MUST NOT expose the aria-brailleroledescription property if any of the following conditions exist:
aria-brailleroledescription is applied does not have a valid WAI-ARIA role or does not have an implicit WAI-ARIA role semantic.aria-brailleroledescription is empty or contains only whitespace characters or contains only Braille Pattern dots-0 (U+2800).aria-brailleroledescription is applied does not have a valid WAI-ARIA aria-roledescription.aria-brailleroledescription is applied has a valid WAI-ARIA aria-roledescription that is identical to a WAI-ARIA role or an implicit WAI-ARIA role semantic.Assistive technologies SHOULD use the value of aria-brailleroledescription when presenting the role of an element in Braille, but SHOULD NOT change other functionality based on the role of an element that has a value for aria-brailleroledescription. For example, an assistive technology that provides functions for navigating to the next aria-brailleroledescription.
Assistive technologies SHOULD expose the aria-brailleroledescription property as follows:
aria-brailleroledescription consists only of Unicode characters that are not Unicode Braille Patterns, translate the value according to the user's preferred translation table.aria-brailleroledescription consists only of Unicode Braille Patterns characters, pass the value to the user without translation.The following two examples show the use of aria-brailleroledescription to indicate that a button's description has a particular Braille contraction.
<button aria-roledescription="planet" aria-brailleroledescription="pln" id="jupiter" aria-label="jupiter"> -<img alt\="" src\="images/jupiter.jpg"/> -</button>-
In the previous example, a Braille display may display "Jupiter, pln" in Braille rather than the verbose "Jupiter, planet".
-| Characteristic | -Value | -
|---|---|
| Used in Roles: | -All elements of the base markup | -
| Inherits into Roles: | -Placeholder | -
| Value: | -string | -