aria-braille properties: improve authoring note (#1291)

pkra · web-flow · commit fc91e5519a03 · 2020-11-05T09:58:39.000-08:00
* 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.

* braille properties note: address review comments
remove references to description or details as example.
diff --git a/index.html b/index.html
@@ -10539,7 +10539,7 @@ <h2>Definitions of States and Properties (all aria-* attributes)</h2>
 					<li>The value of <code>aria-brailleroledescription</code> 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).</li>
 					<li>The value of <code>aria-brailleroledescription</code> should not be identical to the element's WAI-ARIA <code>aria-roledescription</code>, WAI-ARIA <code>role</code> or implicit WAI-ARIA role semantic.</li>
 				</ol>
-				<p class="note">Note that <a>Assistive Technologies</a> with braille support can convert <code>aria-roledescription</code> content to Braille. In addition, assistive technologies will be able to customize such braille output according to user preferences. Using only <code>aria-roledescription</code> is <strong>almost always</strong> the better user experience and authors are <strong>strongly discouraged</strong> from using <code>aria-brailleroledescription</code> to replicate <code>aria-roledescription</code>. Instead, <code>aria-brailleroledescription</code> is meant to be used only when <code>aria-roledescription</code> 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 <code>aria-brailleroledescription</code> 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 <a>Assistive Technologies</a> will pass such content directly to the user without applying user specific braille translations; in general, authors are <strong>strongly discouraged</strong> from using Unicode Braille Patterns in <code>aria-brailleroledescription</code>.
+				<p class="note">Note that <a>Assistive Technologies</a> with braille support can convert <code>aria-roledescription</code> content to Braille. In addition, assistive technologies will be able to customize such braille output according to user preferences. Using only <code>aria-roledescription</code> is <strong>almost always</strong> the better user experience and authors are <strong>strongly discouraged</strong> from using <code>aria-brailleroledescription</code> to replicate <code>aria-roledescription</code>. Instead, <code>aria-brailleroledescription</code> is meant to be used only when <code>aria-roledescription</code> 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 <code>aria-brailleroledescription</code> 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 <a>Assistive Technologies</a> will pass such content directly to the user without applying user specific braille translations; in general, authors are <strong>strongly discouraged</strong> from using Unicode Braille Patterns in <code>aria-brailleroledescription</code>.
 				</p>
 				<p>User agents MUST NOT expose the <code>aria-brailleroledescription</code> property if any of the following conditions exist:</p>
 				<ol>
@@ -11908,7 +11908,7 @@ <h2>Definitions of States and Properties (all aria-* attributes)</h2>
 					<li>The value of <code>aria-braillelabel</code> 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).</li>
 					<li>The value of <code>aria-braillelabel</code> is not identical to the element's accessible name.</li>
 				</ol>
-				<p class="note">Note that <a>Assistive Technologies</a> 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 <code>aria-label</code> is <strong>almost always</strong> the better user experience and authors are <strong>strongly discouraged</strong> from using <code>aria-braillelabel</code> to replicate <code>aria-label</code>. Instead, <code>aria-braillelabel</code> 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 <code>aria-braillelabel</code> 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 <a>Assistive Technologies</a> will pass such content directly to the user without applying user specific braille translations; in general, authors are <strong>strongly discouraged</strong> from using Unicode Braille Patterns in <code>aria-braillelabel</code>.
+				<p class="note">Note that <a>Assistive Technologies</a> 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 <code>aria-label</code> is <strong>almost always</strong> the better user experience and authors are <strong>strongly discouraged</strong> from using <code>aria-braillelabel</code> to replicate <code>aria-label</code>. Instead, <code>aria-braillelabel</code> 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 <code>aria-braillelabel</code> 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 <a>Assistive Technologies</a> will pass such content directly to the user without applying user specific braille translations; in general, authors are <strong>strongly discouraged</strong> from using Unicode Braille Patterns in <code>aria-braillelabel</code>.
 				</p>
 				<p><a>Assistive technologies</a> SHOULD use the value of <code>aria-braillelabel</code> 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.</p>
 				<p><a>Assistive technologies</a> SHOULD expose the <code>aria-braillelabel</code> property as follows:</p>
