From 961de41e5f3626e3df97a4c91fe28b2d72da6e9f Mon Sep 17 00:00:00 2001 From: Peter Krautzberger Date: Tue, 15 Oct 2019 10:37:22 +0200 Subject: [PATCH 01/15] address review comments (part 1) * rephrase opening line - https://github.com/w3c/aria/pull/924#discussion_r334697274 * Braille/braille capitalization - https://github.com/w3c/aria/pull/924#discussion_r334698128 * suffice => overly verbose - https://github.com/w3c/aria/pull/924#discussion_r334698332 * two examples show => example shows - https://github.com/w3c/aria/pull/924#discussion_r334700411 --- index.html | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/index.html b/index.html index 1f21f7de5..1fe22e53d 100644 --- a/index.html +++ b/index.html @@ -12299,17 +12299,17 @@

Definitions of States and Properties (all aria-* attributes)

aria-brailleroledescription
-

Defines a human-readable, author-localized Braille description for the role of an element.

+

Defines a human-readable, author-localized abbreviated description for the role of an element, which is intended to be converted into Braille.

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 group or region, or to providing a more specific description of a widget in a Braille context.

-

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.

+

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 group or region, or to providing a more specific description of a widget in a braille context.

+

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 is excessively verbose when rendered in Braille.

When using aria-brailleroledescription, authors SHOULD also ensure that:

  1. The element to which aria-brailleroledescription is applied has a valid WAI-ARIA role or has an implicit WAI-ARIA role semantic.
  2. The value of aria-brailleroledescription is not empty or does not contain only whitespace characters.
  3. The value of 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. +

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:

    @@ -12324,11 +12324,11 @@

    Definitions of States and Properties (all aria-* attributes)

  1. If the value of aria-brailleroledescription consists only of Unicode characters that are not Unicode Braille Patterns, translate the value according to the user's preferred translation table.
  2. If the value of 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.

+

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" 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".

+

In the previous example, a braille display may display "Jupiter, pln" in Braille rather than the verbose "Jupiter, planet".

From d4bb3a8c5235f6235dc1a207888750b4b0e0a568 Mon Sep 17 00:00:00 2001 From: Peter Krautzberger Date: Wed, 23 Oct 2019 14:42:56 +0200 Subject: [PATCH 02/15] editorial suggestion by @mcking65 Opening: add reference to aria-roledescription. Co-Authored-By: Matt King --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index 1fe22e53d..3e0b0a457 100644 --- a/index.html +++ b/index.html @@ -12299,7 +12299,7 @@

Definitions of States and Properties (all aria-* attributes)

aria-brailleroledescription
-

Defines a human-readable, author-localized abbreviated description for the role of an element, which is intended to be converted into Braille.

+

Defines a human-readable, author-localized abbreviated description for the role of an element, which is intended to be converted into Braille. See related aria-roledescription.

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 group or region, or to providing a more specific description of a widget in a braille context.

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 is excessively verbose when rendered in Braille.

From d43932e5e7291e802a5849f2a54e7fb291d79896 Mon Sep 17 00:00:00 2001 From: Peter Krautzberger Date: Wed, 23 Oct 2019 14:47:11 +0200 Subject: [PATCH 03/15] editorial suggestion by @mcking65 Simplified phrasing for better understanding. Co-Authored-By: Matt King --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index 3e0b0a457..eaa7cb49d 100644 --- a/index.html +++ b/index.html @@ -12301,7 +12301,7 @@

Definitions of States and Properties (all aria-* attributes)

Defines a human-readable, author-localized abbreviated description for the role of an element, which is intended to be converted into Braille. See related aria-roledescription.

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 group or region, or to providing a more specific description of a widget in a braille context.

+

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 understanding or interaction by people who rely on a braille interface. Authors SHOULD limit use of aria-brailleroledescription to clarifying the purpose of non-interactive container roles like group or region, or to providing a more specific description of a widget.

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 is excessively verbose when rendered in Braille.

When using aria-brailleroledescription, authors SHOULD also ensure that:

    From 01fe41d50a2ebccddc226da92ee9f984a2c8ceda Mon Sep 17 00:00:00 2001 From: Peter Krautzberger Date: Wed, 23 Oct 2019 14:49:20 +0200 Subject: [PATCH 04/15] editorial suggestion by @mcking65 remove "rare", replace "excessively verbose" with phrasing more appropriate for braille displays. Co-Authored-By: Matt King --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index eaa7cb49d..3cce71dbb 100644 --- a/index.html +++ b/index.html @@ -12302,7 +12302,7 @@

    Definitions of States and Properties (all aria-* attributes)

    Defines a human-readable, author-localized abbreviated description for the role of an element, which is intended to be converted into Braille. See related aria-roledescription.

    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 understanding or interaction by people who rely on a braille interface. Authors SHOULD limit use of aria-brailleroledescription to clarifying the purpose of non-interactive container roles like group or region, or to providing a more specific description of a widget.

    -

    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 is excessively verbose when rendered in Braille.

    +

    Authors MUST NOT use aria-brailleroledescription without providing a more specific aria-roledescription. In general, aria-brailleroledescription should only be used in cases where the braile rendering of a aria-roledescription would require significantly more cells than are usually allocated for displaying the role of an element.

    When using aria-brailleroledescription, authors SHOULD also ensure that:

    1. The element to which aria-brailleroledescription is applied has a valid WAI-ARIA role or has an implicit WAI-ARIA role semantic.
      2. From 018b35f447457e92f914a5876cf64c58d2dfdd01 Mon Sep 17 00:00:00 2001 From: Peter Krautzberger Date: Wed, 23 Oct 2019 14:52:12 +0200 Subject: [PATCH 05/15] editorial suggestion by @mcking65 fix "either" position; clarify "string of empty cells" Co-Authored-By: Matt King --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index 3cce71dbb..7f92220a3 100644 --- a/index.html +++ b/index.html @@ -12307,7 +12307,7 @@

      Definitions of States and Properties (all aria-* attributes)

      1. The element to which aria-brailleroledescription is applied has a valid WAI-ARIA role or has an implicit WAI-ARIA role semantic.
      2. The value of aria-brailleroledescription is not empty or does not contain only whitespace characters.
        3. -
      3. The value of 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).
        4. +
      4. The value of aria-brailleroledescription either consists of a string of Unicode that does not include any Unicode Braille Patterns (U+2800..U+28FF) or consists of a string including only Unicode Braille Patterns (U+2800..U+28FF) that would not be an empty string if all Braille Pattern dots-0 (U+2800) were removed.

      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.

      From 3264995b523abe8552fb0349f640d2229524ba45 Mon Sep 17 00:00:00 2001 From: Peter Krautzberger Date: Wed, 23 Oct 2019 14:58:44 +0200 Subject: [PATCH 06/15] editorial suggestion by @mcking65 Improve grammar and language in author warning. Co-Authored-By: Matt King --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index 7f92220a3..5cba349b9 100644 --- a/index.html +++ b/index.html @@ -12309,7 +12309,7 @@

      Definitions of States and Properties (all aria-* attributes)

    2. The value of aria-brailleroledescription is not empty or does not contain only whitespace characters.
    3. The value of aria-brailleroledescription either consists of a string of Unicode that does not include any Unicode Braille Patterns (U+2800..U+28FF) or consists of a string including only Unicode Braille Patterns (U+2800..U+28FF) that would not be an empty string if all Braille Pattern dots-0 (U+2800) were removed.
    -

    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. +

    Assistive technologies that support braille output can convert aria-roledescription values to Braille. In addition, assistive technologies may also apply user preferences, such as for a specific grade of braille, to the conversion. Using only aria-roledescription will almost always provide the best 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 an ideal braille description would be very different from a text description converted to Braille. It is very important to note that when using aria-brailleroledescription, authors are solely responsible for aligning the attribute value with the document language and clearly communicating 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 translation preferences. 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:

      From f44324b950d9fe9ddfac47c1aca169d87e5a3879 Mon Sep 17 00:00:00 2001 From: Peter Krautzberger Date: Wed, 23 Oct 2019 15:04:46 +0200 Subject: [PATCH 07/15] editorial correction from @mcking65 Move section to be just before the aria-busy section as these sections are arranged alphabetically. --- index.html | 170 ++++++++++++++++++++++++++--------------------------- 1 file changed, 85 insertions(+), 85 deletions(-) diff --git a/index.html b/index.html index 5cba349b9..6e16021ee 100644 --- a/index.html +++ b/index.html @@ -527,7 +527,7 @@

      Roles Supporting Name from Encapsulation

      Roles Supporting Name from Legend

      - +

      Roles which cannot be named (Name prohibited)

      @@ -1481,7 +1481,7 @@

      Definition of Roles

 - + @@ -1683,9 +1683,9 @@

Definition of Roles

+ - + @@ -1971,9 +1971,9 @@

Definition of Roles

+ - + @@ -2695,9 +2695,9 @@

Definition of Roles

+ - + @@ -3022,9 +3022,9 @@

Definition of Roles

+ - + @@ -3221,7 +3221,7 @@

Definition of Roles

A landmark region that contains a collection of items and objects that, as a whole, combine to create a form. See related search.

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 search role instead of the generic 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 aria-labelledby if a visible label is present. Authors SHOULD include the label inside of a heading whenever possible. The heading MAY be an instance of the standard host language heading element or an instance of an element with role heading.

+

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 aria-labelledby if a visible label is present. Authors SHOULD include the label inside of a heading whenever possible. The heading MAY be an instance of the standard host language heading element or an instance of an element with role heading.

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.

@@ -3361,9 +3361,9 @@

Definition of Roles

+ - + @@ -3970,7 +3970,7 @@

Definition of Roles

- + @@ -3981,9 +3981,9 @@

Definition of Roles

+ - + @@ -6132,9 +6132,9 @@
Note regarding the ARIA 1.1 none role.
+ - + @@ -6292,9 +6292,9 @@
Presentational Roles Conflict Resolution
+ - + @@ -6329,7 +6329,7 @@
Presentational Roles Conflict Resolution
  • If aria-valuemax is missing or not a number, it defaults to 100.

    • -

    The author SHOULD supply a value for aria-valuenow unless the value is indeterminate, in which case the author SHOULD omit the aria-valuenow attribute. +

    The author SHOULD supply a value for aria-valuenow unless the value is indeterminate, in which case the author SHOULD omit the aria-valuenow attribute. Authors SHOULD update this value when the visual progress indicator is updated. If the progressbar is describing the loading progress of a particular region of a page, the author SHOULD use aria-describedby to point to the status, and set the aria-busy attribute to 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 aria-valuenow as a percent of a range between the value of aria-valuemin and aria-valuemax, unless aria-valuetext is specified.

    @@ -8105,9 +8105,9 @@
    Presentational Roles Conflict Resolution
    + - + @@ -8267,9 +8267,9 @@
    Presentational Roles Conflict Resolution
    + - + @@ -8354,9 +8354,9 @@
    Presentational Roles Conflict Resolution
    + - + @@ -10253,6 +10253,64 @@

    Definitions of States and Properties (all aria-* attributes)

    Characteristics:
    Inherited States and Properties: Placeholder
    Name From: author
    Name From: prohibited
    Name From: prohibited
    Name From: prohibited
    Name From: prohibited
    Name From: prohibited
    Supported States and Properties:
    Inherited States and Properties: Placeholder
    Name From: prohibited
    Name From: prohibited
    Name From: prohibited
    Name From: prohibited
    Name From: prohibited
    Name From: prohibited
    +
    + aria-brailleroledescription +
    +

    Defines a human-readable, author-localized abbreviated description for the role of an element, which is intended to be converted into Braille. See related aria-roledescription.

    +

    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 group or region, or to providing a more specific description of a widget in a braille context.

    +

    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 is excessively verbose when rendered in Braille.

    +

    When using aria-brailleroledescription, authors SHOULD also ensure that:

    +
      +
    1. The element to which aria-brailleroledescription is applied has a valid WAI-ARIA role or has an implicit WAI-ARIA role semantic.
      2. +
    2. The value of aria-brailleroledescription is not empty or does not contain only whitespace characters.
      3. +
    3. The value of 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).
      4. +
    +

    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:

    +
      +
    1. The element to which aria-brailleroledescription is applied does not have a valid WAI-ARIA role or does not have an implicit WAI-ARIA role semantic.
      2. +
    2. The value of aria-brailleroledescription is empty or contains only whitespace characters or contains only Braille Pattern dots-0 (U+2800).
      3. +
    3. The element to which aria-brailleroledescription is applied does not have a valid WAI-ARIA aria-roledescription.
      4. +
    4. The element to which 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.
      5. +
    +

    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 region or button SHOULD allow those functions to navigate to regions and buttons that have an aria-brailleroledescription.

    +

    Assistive technologies SHOULD expose the aria-brailleroledescription property as follows:

    +
      +
    1. If the value of aria-brailleroledescription consists only of Unicode characters that are not Unicode Braille Patterns, translate the value according to the user's preferred translation table.
      2. +
    2. If the value of aria-brailleroledescription consists only of Unicode Braille Patterns characters, pass the value to the user without translation.
      3. +
    +

    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" 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".

    +
    + + + + + + + + + + + + + + + + + + + + + + +
    Characteristics:
    CharacteristicValue
    Used in Roles:All elements of the base markup
    Inherits into Roles:Placeholder
    Value:string
    +
    aria-busy
    @@ -12296,64 +12354,6 @@

    Definitions of States and Properties (all aria-* attributes)

    -
    - aria-brailleroledescription -
    -

    Defines a human-readable, author-localized abbreviated description for the role of an element, which is intended to be converted into Braille. See related aria-roledescription.

    -

    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 understanding or interaction by people who rely on a braille interface. Authors SHOULD limit use of aria-brailleroledescription to clarifying the purpose of non-interactive container roles like group or region, or to providing a more specific description of a widget.

    -

    Authors MUST NOT use aria-brailleroledescription without providing a more specific aria-roledescription. In general, aria-brailleroledescription should only be used in cases where the braile rendering of a aria-roledescription would require significantly more cells than are usually allocated for displaying the role of an element.

    -

    When using aria-brailleroledescription, authors SHOULD also ensure that:

    -
      -
    1. The element to which aria-brailleroledescription is applied has a valid WAI-ARIA role or has an implicit WAI-ARIA role semantic.
      2. -
    2. The value of aria-brailleroledescription is not empty or does not contain only whitespace characters.
      3. -
    3. The value of aria-brailleroledescription either consists of a string of Unicode that does not include any Unicode Braille Patterns (U+2800..U+28FF) or consists of a string including only Unicode Braille Patterns (U+2800..U+28FF) that would not be an empty string if all Braille Pattern dots-0 (U+2800) were removed.
      4. -
    -

    Assistive technologies that support braille output can convert aria-roledescription values to Braille. In addition, assistive technologies may also apply user preferences, such as for a specific grade of braille, to the conversion. Using only aria-roledescription will almost always provide the best 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 an ideal braille description would be very different from a text description converted to Braille. It is very important to note that when using aria-brailleroledescription, authors are solely responsible for aligning the attribute value with the document language and clearly communicating 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 translation preferences. 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:

    -
      -
    1. The element to which aria-brailleroledescription is applied does not have a valid WAI-ARIA role or does not have an implicit WAI-ARIA role semantic.
      2. -
    2. The value of aria-brailleroledescription is empty or contains only whitespace characters or contains only Braille Pattern dots-0 (U+2800).
      3. -
    3. The element to which aria-brailleroledescription is applied does not have a valid WAI-ARIA aria-roledescription.
      4. -
    4. The element to which 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.
      5. -
    -

    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 region or button SHOULD allow those functions to navigate to regions and buttons that have an aria-brailleroledescription.

    -

    Assistive technologies SHOULD expose the aria-brailleroledescription property as follows:

    -
      -
    1. If the value of aria-brailleroledescription consists only of Unicode characters that are not Unicode Braille Patterns, translate the value according to the user's preferred translation table.
      2. -
    2. If the value of aria-brailleroledescription consists only of Unicode Braille Patterns characters, pass the value to the user without translation.
      3. -
    -

    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" 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".

    -
    - - - - - - - - - - - - - - - - - - - - - - -
    Characteristics:
    CharacteristicValue
    Used in Roles:All elements of the base markup
    Inherits into Roles:Placeholder
    Value:string
    -
    aria-rowcount
    From 45e826ad044aee596dbb5c4bf60a8e2de28c794b Mon Sep 17 00:00:00 2001 From: Peter Krautzberger Date: Tue, 10 Dec 2019 12:48:31 +0100 Subject: [PATCH 08/15] fix: integrate editorial fixes Addresses comments from NSoiffer --- index.html | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/index.html b/index.html index 6e16021ee..ccfcdea7e 100644 --- a/index.html +++ b/index.html @@ -10264,7 +10264,7 @@

    Definitions of States and Properties (all aria-* attributes)

    1. The element to which aria-brailleroledescription is applied has a valid WAI-ARIA role or has an implicit WAI-ARIA role semantic.
    2. The value of aria-brailleroledescription is not empty or does not contain only whitespace characters.
      3. -
    3. The value of 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).
      4. +
    4. The value of 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).

    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.

    @@ -10278,8 +10278,8 @@

    Definitions of States and Properties (all aria-* attributes)

    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 region or button SHOULD allow those functions to navigate to regions and buttons that have an aria-brailleroledescription.

    Assistive technologies SHOULD expose the aria-brailleroledescription property as follows:

      -
    1. If the value of aria-brailleroledescription consists only of Unicode characters that are not Unicode Braille Patterns, translate the value according to the user's preferred translation table.
      2. -
    2. If the value of aria-brailleroledescription consists only of Unicode Braille Patterns characters, pass the value to the user without translation.
      3. +
    3. If the value of 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.
      4. +
    4. Otherwise, pass the value to the user without translation.

    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" aria-label="jupiter">

From 2600877986cedcb0819cfbc5f75ded07cb33da5c Mon Sep 17 00:00:00 2001
From: Peter Krautzberger 
Date: Tue, 10 Dec 2019 13:22:48 +0100
Subject: [PATCH 09/15] update after 2019/12/05 telco * removes UA requirement
 on identical role/role-description; cf. #1131 * Adds @mcking65 comment to not
 be identical to role/role-description

---
 index.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/index.html b/index.html
index ccfcdea7e..cbdb96436 100644
--- a/index.html
+++ b/index.html
@@ -10265,6 +10265,7 @@ 
    Definitions of States and Properties (all aria-* attributes)
    
 					
  • The element to which aria-brailleroledescription is applied has a valid WAI-ARIA role or has an implicit WAI-ARIA role semantic.
    • 
 					
  • The value of aria-brailleroledescription is not empty or does not contain only whitespace characters.
    • 
 					
  • The value of 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).
    • 
+					
  • The value of 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 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.
 				
    
@@ -10273,7 +10274,6 @@ 
    Definitions of States and Properties (all aria-* attributes)
    
 					
  • The element to which aria-brailleroledescription is applied does not have a valid WAI-ARIA role or does not have an implicit WAI-ARIA role semantic.
    • 
 					
  • The value of aria-brailleroledescription is empty or contains only whitespace characters or contains only Braille Pattern dots-0 (U+2800).
    • 
 					
  • The element to which aria-brailleroledescription is applied does not have a valid WAI-ARIA aria-roledescription.
    • 
-					
  • The element to which 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 region or button SHOULD allow those functions to navigate to regions and buttons that have an aria-brailleroledescription.
    
 				
    Assistive technologies SHOULD expose the aria-brailleroledescription property as follows:
    

From a6ccb29b2f5c594dfd53d0d9248cfb98a027ca49 Mon Sep 17 00:00:00 2001
From: Peter Krautzberger 
Date: Thu, 16 Jan 2020 09:25:00 +0100
Subject: [PATCH 10/15] chore: removed some whitespace

---
 index.html | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/index.html b/index.html
index cbdb96436..d666e048c 100644
--- a/index.html
+++ b/index.html
@@ -334,7 +334,7 @@ 
    Information for Authors
    
 	    
    User agents that support WAI-ARIA expand the usage of host language mechanisms such as tabindex, focus, and blur to allow them on all elements. Where the host language supports it, authors MAY add any element such as a div, span, or img to the default tab order by setting tabindex="0". In addition, any item with tabindex equal to a negative integer is focusable via script or a mouse click, but is not part of the default tab order. This is supported in both [[HTML]] and [[SVG2]].
    
 	    
    
         Authors MAY use aria-activedescendant to inform assistive technologies which descendant of a widget element is treated as having keyboard focus in the user interface if the role of the widget element supports aria-activedescendant.
-        This is often a more convenient way of providing keyboard navigation within widgets, such as a listbox, where the widget occupies only one stop in the page Tab sequence and other keys, typically arrow keys, are used to focus elements inside the widget.  
+        This is often a more convenient way of providing keyboard navigation within widgets, such as a listbox, where the widget occupies only one stop in the page Tab sequence and other keys, typically arrow keys, are used to focus elements inside the widget.
       
    
 	    
    Typically, the author will use host language semantics to put the widget in the Tab sequence (e.g., tabindex="0" in HTML) and aria-activedescendant to point to the ID of the currently active descendant. The author, not the user agent, is responsible for styling the currently active descendant to show it has keyboard focus. The author cannot use :focus to style the currently active descendant since the actual focus is on the container.
    
 	    
    More information on managing focus can be found in the Developing a Keyboard Interface section of the WAI-ARIA Authoring Practices [[WAI-ARIA-PRACTICES-1.1]].
    
@@ -2150,7 +2150,7 @@ 
    Definition of Roles
    
 			The ARIA 1.0 specification describes a combobox pattern where the input element with the combobox role references the popup element with aria-owns instead of aria-controls.
 			User agents, assistive technologies, and conformance checkers SHOULD continue to support the ARIA 1.0 pattern so that existing implementations of the ARIA 1.0 pattern remain functional.
 			The ARIA 1.1 specification describes a combobox pattern where the element with role combobox is a composite container instead of a focusable input.
-			User agents and assistive technologies did not adequately support the ARIA 1.1 pattern, so the ARIA 1.2 pattern supersedes the ARIA 1.1 pattern, which authors SHOULD abandon. 
+			User agents and assistive technologies did not adequately support the ARIA 1.1 pattern, so the ARIA 1.2 pattern supersedes the ARIA 1.1 pattern, which authors SHOULD abandon.
 		  
    
 				
    The features and behaviors of combobox implementations vary widely. Consequently, there are many important authoring considerations. See the WAI-ARIA Authoring Practices Guide [[WAI-ARIA-PRACTICES-1.1]] for additional details on implementing combobox design patterns.
    @@ -2204,7 +2204,7 @@

    Definition of Roles

    Supported States and Properties: - +
    • aria-activedescendant
    • aria-autocomplete
      • @@ -4895,9 +4895,9 @@

      Definition of Roles

      • aria-label
      • aria-labelledby
        • -
      +
    - + Name From: prohibited @@ -11112,7 +11112,7 @@

    Definitions of States and Properties (all aria-* attributes)

    Inherits into Roles: Placeholder - + Value: ID reference @@ -13484,8 +13484,8 @@

    Substantive changes since the last public working draft

  • 11-Oct-2019: Remove allowance of group in list
  • 09-Oct-2019: Add missing implicit value for progressbar
  • 09-Oct-2019: Remove accessible name required from log and timer
    • -
  • 22-Aug-2019: Remove aria-level from grid
    • -
  • 23-Jul-2019: Add generic role
    • +
  • 22-Aug-2019: Remove aria-level from grid
    • +
  • 23-Jul-2019: Add generic role
  • 11-Jul-2019: Remove advice against changing roles
  • 11-Jul-2019: Set Accessible Name Required to false on gridcell
  • 11-Jul-2019: Add associationlist, associationlistitemkey, and associationlistitemvalue roles
    • From 444fccc103eb0c5694c6c383b530818cb3d21c87 Mon Sep 17 00:00:00 2001 From: Peter Krautzberger Date: Thu, 16 Jan 2020 09:26:30 +0100 Subject: [PATCH 11/15] prohibit aria-brailleroledescription on role=generic Cf. https://github.com/w3c/aria/pull/1142#issuecomment-574983257 --- index.html | 1 + 1 file changed, 1 insertion(+) diff --git a/index.html b/index.html index d666e048c..01a0084f4 100644 --- a/index.html +++ b/index.html @@ -3359,6 +3359,7 @@

    Definition of Roles

    Prohibited States and Properties:
      +
    • aria-brailleroledescription
    • aria-label
    • aria-labelledby
    From 39af2b360f4f549166f9ca7189ddcb8ec191f7f7 Mon Sep 17 00:00:00 2001 From: Peter Krautzberger Date: Thu, 16 Jan 2020 09:36:39 +0100 Subject: [PATCH 12/15] editorial fixes Addresses points 5.-8. raised in https://github.com/w3c/aria/pull/1097#issuecomment-574486030 --- index.html | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/index.html b/index.html index 01a0084f4..e763784cc 100644 --- a/index.html +++ b/index.html @@ -10268,7 +10268,7 @@

    Definitions of States and Properties (all aria-* attributes)

  • The value of 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).
  • The value of 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 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. +

    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:

      @@ -10284,9 +10284,9 @@

      Definitions of States and Properties (all aria-* attributes)

    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" aria-label="jupiter">
-<img alt\="" src\="images/jupiter.jpg"/>
+<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".

    +

    In the previous example, a braille display may display "pln Jupiter" in Braille rather than the verbose "planet Jupiter".

    From a9a9c9e220019a21d02f53c664f390369b28d3bb Mon Sep 17 00:00:00 2001 From: Peter Krautzberger Date: Tue, 18 Feb 2020 16:56:47 +0100 Subject: [PATCH 13/15] editorial fix Addresses https://github.com/w3c/aria/pull/1097#issuecomment-577973376 --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index e763784cc..d04506d1f 100644 --- a/index.html +++ b/index.html @@ -10260,7 +10260,7 @@

    Definitions of States and Properties (all aria-* attributes)

    Defines a human-readable, author-localized abbreviated description for the role of an element, which is intended to be converted into Braille. See related aria-roledescription.

    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 group or region, or to providing a more specific description of a widget in a braille context.

    -

    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 is excessively verbose when rendered in Braille.

    +

    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:

    1. The element to which aria-brailleroledescription is applied has a valid WAI-ARIA role or has an implicit WAI-ARIA role semantic.
      2. From 9b132eca39b567b9faaa21ee4e750c3dc90d2151 Mon Sep 17 00:00:00 2001 From: Peter Krautzberger Date: Tue, 18 Feb 2020 16:57:55 +0100 Subject: [PATCH 14/15] editorial fix Addresses https://github.com/w3c/aria/pull/1097#issuecomment-587525724 --- index.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/index.html b/index.html index d04506d1f..6853c5101 100644 --- a/index.html +++ b/index.html @@ -10283,8 +10283,8 @@

      Definitions of States and Properties (all aria-* attributes)

    2. Otherwise, pass the value to the user without translation.

    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" aria-label="jupiter">
-<img alt="" src="images/jupiter.jpg"/>
+				
    <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".
    
 			

From c6db17fdad0ac54d44ac3f2c84b6a3d1805bb1c9 Mon Sep 17 00:00:00 2001
From: Peter Krautzberger 
Date: Tue, 18 Feb 2020 17:00:12 +0100
Subject: [PATCH 15/15] Revert "chore: removed some whitespace"

This reverts commit a6ccb29b2f5c594dfd53d0d9248cfb98a027ca49.
---
 index.html | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/index.html b/index.html
index 6853c5101..3ee3c7309 100644
--- a/index.html
+++ b/index.html
@@ -334,7 +334,7 @@ 
    Information for Authors
    
 	    
    User agents that support WAI-ARIA expand the usage of host language mechanisms such as tabindex, focus, and blur to allow them on all elements. Where the host language supports it, authors MAY add any element such as a div, span, or img to the default tab order by setting tabindex="0". In addition, any item with tabindex equal to a negative integer is focusable via script or a mouse click, but is not part of the default tab order. This is supported in both [[HTML]] and [[SVG2]].
    
 	    
    
         Authors MAY use aria-activedescendant to inform assistive technologies which descendant of a widget element is treated as having keyboard focus in the user interface if the role of the widget element supports aria-activedescendant.
-        This is often a more convenient way of providing keyboard navigation within widgets, such as a listbox, where the widget occupies only one stop in the page Tab sequence and other keys, typically arrow keys, are used to focus elements inside the widget.
+        This is often a more convenient way of providing keyboard navigation within widgets, such as a listbox, where the widget occupies only one stop in the page Tab sequence and other keys, typically arrow keys, are used to focus elements inside the widget.  
       
    
 	    
    Typically, the author will use host language semantics to put the widget in the Tab sequence (e.g., tabindex="0" in HTML) and aria-activedescendant to point to the ID of the currently active descendant. The author, not the user agent, is responsible for styling the currently active descendant to show it has keyboard focus. The author cannot use :focus to style the currently active descendant since the actual focus is on the container.
    
 	    
    More information on managing focus can be found in the Developing a Keyboard Interface section of the WAI-ARIA Authoring Practices [[WAI-ARIA-PRACTICES-1.1]].
    
@@ -2150,7 +2150,7 @@ 
    Definition of Roles
    
 			The ARIA 1.0 specification describes a combobox pattern where the input element with the combobox role references the popup element with aria-owns instead of aria-controls.
 			User agents, assistive technologies, and conformance checkers SHOULD continue to support the ARIA 1.0 pattern so that existing implementations of the ARIA 1.0 pattern remain functional.
 			The ARIA 1.1 specification describes a combobox pattern where the element with role combobox is a composite container instead of a focusable input.
-			User agents and assistive technologies did not adequately support the ARIA 1.1 pattern, so the ARIA 1.2 pattern supersedes the ARIA 1.1 pattern, which authors SHOULD abandon.
+			User agents and assistive technologies did not adequately support the ARIA 1.1 pattern, so the ARIA 1.2 pattern supersedes the ARIA 1.1 pattern, which authors SHOULD abandon. 
 		  
    
 				
    The features and behaviors of combobox implementations vary widely. Consequently, there are many important authoring considerations. See the WAI-ARIA Authoring Practices Guide [[WAI-ARIA-PRACTICES-1.1]] for additional details on implementing combobox design patterns.
    
 			
@@ -2204,7 +2204,7 @@ 
    Definition of Roles
    - - + @@ -11113,7 +11113,7 @@

    Definitions of States and Properties (all aria-* attributes)

    - + @@ -13485,8 +13485,8 @@

    Substantive changes since the last public working draft

  • 11-Oct-2019: Remove allowance of group in list
  • 09-Oct-2019: Add missing implicit value for progressbar
  • 09-Oct-2019: Remove accessible name required from log and timer
    • -
  • 22-Aug-2019: Remove aria-level from grid
    • -
  • 23-Jul-2019: Add generic role
    • +
  • 22-Aug-2019: Remove aria-level from grid
    • +
  • 23-Jul-2019: Add generic role
  • 11-Jul-2019: Remove advice against changing roles
  • 11-Jul-2019: Set Accessible Name Required to false on gridcell
  • 11-Jul-2019: Add associationlist, associationlistitemkey, and associationlistitemvalue roles
    • Characteristics:
    Supported States and Properties: +
    • aria-activedescendant
    • aria-autocomplete
      • @@ -4896,9 +4896,9 @@

      Definition of Roles

      • aria-label
      • aria-labelledby
        • -
      +
    Name From: prohibited
    Inherits into Roles: Placeholder
    Value: ID reference