From 30b5a067d1a56ce0c36272281ad65f4c2a2dc7eb Mon Sep 17 00:00:00 2001 From: Peter Krautzberger Date: Thu, 18 Jun 2020 12:28:15 +0200 Subject: [PATCH 1/2] aria-braille properties: improve authoring note Adds clarifying language to the note for aria-braillelabel and aria-roledescription to help authors understand what they need to consider when using these properties. --- index.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/index.html b/index.html index 5fc2c1208..b89ed6d8e 100644 --- a/index.html +++ b/index.html @@ -10539,7 +10539,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 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. +

    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 for localizing the attribute value so that it aligns with the document language. In addition, authors need to design a way to clearly communicate the use of this attribute to the user. For example, this could be in an aria-description, or in a section referenced by aria-details, or as part of the product documentation. 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:

      @@ -11903,7 +11903,7 @@

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

    1. The value of aria-braillelabel 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 containing only Braille Pattern dots-0 (U+2800).
    2. The value of aria-braillelabel is not identical to the element's accessible name.
    -

    Note that Assistive Technologies with braille support can convert the accessible name to Braille. In addition, assistive technologies will be able to customize such braille output according to user preferences. Using only the accessible name, e.g., from content or via aria-label is almost always the better user experience and authors are strongly discouraged from using aria-braillelabel to replicate aria-label. Instead, aria-braillelabel is meant to be used only if the accessible name 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-braillelabel 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-braillelabel. +

    Note that Assistive Technologies with braille support can convert the accessible name to Braille. In addition, assistive technologies will be able to customize such braille output according to user preferences. Using only the accessible name, e.g., from content or via aria-label is almost always the better user experience and authors are strongly discouraged from using aria-braillelabel to replicate aria-label. Instead, aria-braillelabel is meant to be used only if the accessible name 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-braillelabel authors are solely responsible for localizing the attribute value so that it aligns with the document language. In addition, authors need to design a way to clearly communicate the use of this attribute to the user. For example, this could be in an aria-description, or in a section referenced by aria-details, or as part of the product documentation. 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-braillelabel.

    Assistive technologies SHOULD use the value of aria-braillelabel when presenting the accessible name of an element in Braille, but SHOULD NOT change other functionality. For example, an assistive technology that provides aural rendering SHOULD use the accessible name.

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

    From 0e9008c0a87731efc5e003d5fe834e36a162cadb Mon Sep 17 00:00:00 2001 From: Peter Krautzberger Date: Thu, 18 Jun 2020 17:46:13 +0200 Subject: [PATCH 2/2] braille properties note: address review comments remove references to description or details as example. --- index.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/index.html b/index.html index b89ed6d8e..901b7b08b 100644 --- a/index.html +++ b/index.html @@ -10539,7 +10539,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 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 for localizing the attribute value so that it aligns with the document language. In addition, authors need to design a way to clearly communicate the use of this attribute to the user. For example, this could be in an aria-description, or in a section referenced by aria-details, or as part of the product documentation. 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 for localizing the attribute value so that it aligns with the document language. In addition, authors need to design a way to clearly communicate the use of this attribute to the user. For example, this could be done in the product documentation. 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:

      @@ -11903,7 +11903,7 @@

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

    1. The value of aria-braillelabel 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 containing only Braille Pattern dots-0 (U+2800).
    2. The value of aria-braillelabel is not identical to the element's accessible name.
    -

    Note that Assistive Technologies with braille support can convert the accessible name to Braille. In addition, assistive technologies will be able to customize such braille output according to user preferences. Using only the accessible name, e.g., from content or via aria-label is almost always the better user experience and authors are strongly discouraged from using aria-braillelabel to replicate aria-label. Instead, aria-braillelabel is meant to be used only if the accessible name 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-braillelabel authors are solely responsible for localizing the attribute value so that it aligns with the document language. In addition, authors need to design a way to clearly communicate the use of this attribute to the user. For example, this could be in an aria-description, or in a section referenced by aria-details, or as part of the product documentation. 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-braillelabel. +

    Note that Assistive Technologies with braille support can convert the accessible name to Braille. In addition, assistive technologies will be able to customize such braille output according to user preferences. Using only the accessible name, e.g., from content or via aria-label is almost always the better user experience and authors are strongly discouraged from using aria-braillelabel to replicate aria-label. Instead, aria-braillelabel is meant to be used only if the accessible name 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-braillelabel authors are solely responsible for localizing the attribute value so that it aligns with the document language. In addition, authors need to design a way to clearly communicate the use of this attribute to the user. For example, this could be done in the product documentation. 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-braillelabel.

    Assistive technologies SHOULD use the value of aria-braillelabel when presenting the accessible name of an element in Braille, but SHOULD NOT change other functionality. For example, an assistive technology that provides aural rendering SHOULD use the accessible name.

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