improve wording for braille patterns (#1287)

pkra · web-flow · commit 42417cea9fce · 2020-11-05T09:59:23.000-08:00
diff --git a/index.html b/index.html
@@ -10536,7 +10536,7 @@ <h2>Definitions of States and Properties (all aria-* attributes)</h2>
 				<ol>
 					<li>The element to which <code>aria-brailleroledescription</code> is applied has a valid <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> role or has an implicit WAI-ARIA role semantic.</li>
 					<li>The value of <code>aria-brailleroledescription</code> is not empty or does not contain only whitespace characters.</li>
-					<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> does not contain any characters in <a>Unicode Braille Patterns</a> or consists of only characters in <a>Unicode Braille Patterns</a>; the value does not only contain Braille Pattern dots-0.</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 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>.
@@ -10550,7 +10550,7 @@ <h2>Definitions of States and Properties (all aria-* attributes)</h2>
 				<p><a>Assistive technologies</a> SHOULD use the value of <code>aria-brailleroledescription</code> 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 <code>aria-brailleroledescription</code>. For example, an assistive technology that provides functions for navigating to the next <rref>region</rref> or <rref>button</rref> SHOULD allow those functions to navigate to regions and buttons that have an <code>aria-brailleroledescription</code>.</p>
 				<p><a>Assistive technologies</a> SHOULD expose the <code>aria-brailleroledescription</code> property as follows:</p>
 				<ol>
-					<li>If the value of <code>aria-brailleroledescription</code> does not contain characters in Unicode Braille Patterns (U+2800..U+28FF), translate the value according to the user's preferred translation table.</li>
+					<li>If the value of <code>aria-brailleroledescription</code> does not contain characters in <a>Unicode Braille Patterns</a>, translate the value according to the user's preferred translation table.</li>
 					<li>Otherwise, pass the value to the user without translation.</li>
 				</ol>
 				<p>The following example shows the use of <code>aria-brailleroledescription</code> to indicate that a button's description has a particular braille contraction.</p>
@@ -11905,15 +11905,15 @@ <h2>Definitions of States and Properties (all aria-* attributes)</h2>
 				<ol>
 					<li>The element to which <code>aria-braillelabel</code> is applied has a valid accessible name.</li>
 					<li>The value of <code>aria-braillelabel</code> is not empty or does not contain only whitespace characters.</li>
-					<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> does not contain any characters in <a>Unicode Braille Patterns</a> or consists of only characters in <a>Unicode Braille Patterns</a>; the value does not only contain Braille Pattern dots-0.</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 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>
 				<ol>
-					<li>If the value of <code>aria-braillelabel</code> does not contain characters in Unicode Braille Patterns (U+2800..U+28FF), translate the value according to the user's preferred translation table.</li>
+					<li>If the value of <code>aria-braillelabel</code> does not contain characters in <a>Unicode Braille Patterns</a>, translate the value according to the user's preferred translation table.</li>
 					<li>Otherwise, pass the value to the user without translation.</li>
 				</ol>
 				<p>The following example shows the use of <code>aria-braillelabel</code> to customize a button's name in braille output.</p>
