feat: aria-brailleroledescription #924
Conversation
|
(This was edited to update the link to the latest location within the spec.) |
|
I have the same comment as in #923. |
|
(Duplicate from #923) I have a small concern about introducing a new "pattern" into the aria lexicon - specifically "double-hyphenated" attributes (i.e. aria-label-braille and aria-roledescription-braille). A quick check of the existing ARIA attributes, and this will be the first time that this WG would be introducing that pattern, and so more than anything else - why? Previously, even "multi-name" attributes have all been concatenated into one string (ref: Position In Set = aria-posinset), and I would strongly encourage the ARIA WG to maintain that pattern (aria-labelbraille, aria-roledescriptionbraille) if these new attributes are to move forward. Additionally, if the only reason for the double-hyphen is "readability", the values can always be presented (instructionally) in CamelCase, as elements and attributes are case insensitive: (aria-LabelBraille, aria-RoleDescriptionBraille - although that goes counter to existing attributes as well) |
|
I've responded at #923 (comment) |
|
Responsed on #923. |
As per WG discussions.
Rename to aria-brailleroledescription as per suggestion from @johnfoliot
* add note on braille conversio of roledescription. * require roledescription different from (implicit) role
Replace plain text aria-brailleroledescription with Unicode braille.
|
Apologies if this has already been discussed... The spec currently has these two clauses about the value of
These seem partially redundant as '3' says whitespace characters should not be part of the value.
Also, I'm a little dubious that the phrase "Unicode Braille Patterns" is proper. The block is called "Braille Patterns" and the characters have names that include that phrase, but technically, a string consists of characters, so "Unicode Braille Pattern characters" would be more correct. Also correct would be "characters from the Unicode Braille Patterns block". I suggest the current two clauses should be replaced with:
|
Happy to change if the WG agrees but they don't seem redundant to me. Point 2 is (essentially) a MUST (cf. also AT guidance to ignore it otherwise), point 3 is a SHOULD.
Sounds good to me but happy to get more feedback. |
Avoids RFC-2119 key words. Addresses feedback from @joanmarie.
* removes (redundant) SHOULD * adds clarification to treat u+2800 like whitespace
pkra
changed the title
joanmarie
added
the
F2FCandidate
* value can now be either all non-braille or all-braille * UA SHOULD's: translate non-braille and pass all-braille through * adjust example
|
@joanmarie I've incorporated the changes from TPAC (as per #765 (comment)). Please take a look. |
joanmarie
added
Agenda
and removed
F2FCandidate
|
At TPAC we agreed that this should not require (and should actively discourage) using "characters from the Unicode Braille Patterns block" because, in almost all instances, the web author will not know what these should be, even if they are an expert in braille. As the simplest example, the web author has no way of knowing whether the user reads uncontracted (Grade 1) or contracted (Grade 2) braille, so this attribute would be formatted as a non-braille unicode string. For example, the screen reader could translate Other examples author-encoded braille strings include when a user is fluent in multiple languages, but only fluent in one variant of braille. For example, a member of my team is fluent in reading, typing, and speaking English, but only reads braille using his native German braille table. VoiceOver can provide that to him, but a web author cannot. |
|
We also agreed that it may be okay to allow unicode braille with sufficient warnings, and no examples of this usage. The only context I can think of where this is necessary is testing, where a user may be learning tactile braille through remote instruction. E.g. a student learning the differences between US English versus UEB, in Grade 1 or 2. |
|
I am skeptical of suggesting the unicode braille block is necessary even in the case of Math polyfills like MathJax. For the same reasons listed above, the polyfill can't know whether the user prefers to read Math in Nemeth, UEB Math, or Computer Braille. |
|
@cookiecrook thanks for re-iterating those points from TPAC. Is there a particular change you have in mind for the latest changes in this PR? |
|
@cookiecrook It does make a difference for polyfills like MathJax. |
* fix html markup * change "user agents should" to "assistive technologies should" * move below the first AT SHOULD * move Note * add warnings on aligning lanugage, alertin user and avoiding braille patterns
| <div class="property" id="aria-brailleroledescription"> | ||
| <pdef>aria-brailleroledescription</pdef> | ||
| <div class="property-description"> | ||
| <p>Defines a human-readable, author-localized Braille description for the <a>role</a> of an <a>element</a>.</p> |
There was a problem hiding this comment.
I think this could be better described as: "Defines a human-readable, author-localized short description for the role of an element, which is intended to be converted into Braille."
There was a problem hiding this comment.
Perhaps "abbreviated role description"
There was a problem hiding this comment.
Thanks, @cookiecrook, I'll make a new PR to address this.
| <div class="property-description"> | ||
| <p>Defines a human-readable, author-localized Braille description for the <a>role</a> of an <a>element</a>.</p> | ||
| <p>Some <a>assistive technologies</a>, 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.</p> | ||
| <p>The <code>aria-brailleroledescription</code> property gives authors the ability to override how <a>assistive technologies</a> localize and express the name of a role in Braille. Thus inappropriately using <code>aria-brailleroledescription</code> may inhibit users' ability to understand or interact with an element on Braille interfaces. Authors SHOULD limit use of <code>aria-brailleroledescription</code> to clarifying the purpose of non-interactive container roles like <rref>group</rref> or <rref>region</rref>, or to providing a <em>more specific</em> description of a <rref>widget</rref> in a Braille context.</p> |
There was a problem hiding this comment.
Editorial nit: The proper nouns: Braille, Web, Internet, should be capitalized, however, their adjective counterparts should not. E.g. "A web page on the Web." "She read Braille on a braille display." IOW, the first use of the word on this line ("…the role in Braille.") is capitalized correctly. The second instance ("…in a Braille context.") should be lowercased.
There was a problem hiding this comment.
There are a bunch of other instances of this throughout the PR.
| <p>Defines a human-readable, author-localized Braille description for the <a>role</a> of an <a>element</a>.</p> | ||
| <p>Some <a>assistive technologies</a>, 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.</p> | ||
| <p>The <code>aria-brailleroledescription</code> property gives authors the ability to override how <a>assistive technologies</a> localize and express the name of a role in Braille. Thus inappropriately using <code>aria-brailleroledescription</code> may inhibit users' ability to understand or interact with an element on Braille interfaces. Authors SHOULD limit use of <code>aria-brailleroledescription</code> to clarifying the purpose of non-interactive container roles like <rref>group</rref> or <rref>region</rref>, or to providing a <em>more specific</em> description of a <rref>widget</rref> in a Braille context.</p> | ||
| <p>Authors MUST NOT use <code>aria-brailleroledescription</code> without providing a <em>more specific</em> <code>aria-roledescription</code>. In general, <code>aria-brailleroledescription</code> should only be used in rare cases when a <code>aria-roledescription</code> does not suffice.</p> |
There was a problem hiding this comment.
s/does not suffice/is excessively verbose when rendered in Braille./
| <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> 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).</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 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>. |
There was a problem hiding this comment.
I don't really understand this note. It seems to be burying the fact that most authors should never use EITHER aria-roledescription OR aria-brailleroledescription.
There was a problem hiding this comment.
This note has been expanded several times over the lifetime of this PR. I agree it's a bit long-winded. I'll think about possible improvements (first guess: moving the second part to the front), but I'd be happy for any suggestions.
There was a problem hiding this comment.
What about:
As a general rule, representing an object's role is a job best left to the assistive technologies which have been configured by the user based on their specific needs and preferences. Because
aria-roledescriptionoverrides this representation, it should only be used when absolutely necessary.
aria-brailleroledescriptionmakes it possible for authors who are knowledgeable about Braille in general, and about their users' needs in particular, to provide a better experience than would be had from a braille translation of thearia-roledescriptionvalue. Authors who lack this knowledge should not usearia-brailleroledescriptionbecause a long, but correctly-translated, braille string is preferable to a shorter, but incorrect one.Authors are also strongly discouraged from using Unicode Braille Patterns. Providing the value of
aria-brailleroledescriptionas text makes it possible for assistive technologies to apply the user's preferred translation tables thus increasing the likelihood that the result will be closer to what the user expects.
There was a problem hiding this comment.
Sounds good to me. @cookiecrook what do you think?
| <li>The element to which <code>aria-brailleroledescription</code> is applied does not have a valid WAI-ARIA <code>role</code> or does not have an implicit WAI-ARIA role semantic.</li> | ||
| <li>The value of <code>aria-brailleroledescription</code> is empty or contains only whitespace characters or contains only Braille Pattern dots-0 (U+2800).</li> | ||
| <li>The element to which <code>aria-brailleroledescription</code> is applied does not have a valid WAI-ARIA <code>aria-roledescription</code>.</li> | ||
| <li>The element to which <code>aria-brailleroledescription</code> is applied has a valid WAI-ARIA <code>aria-roledescription</code> that is identical to a WAI-ARIA <code>role</code> or an implicit WAI-ARIA role semantic.</li> |
There was a problem hiding this comment.
This line invalidates using img as a short braille description. Was that intentional? Same thing with "toc" if that one makes it from the DPUB module into the core spec.
There was a problem hiding this comment.
I admit I struggle to answer that. The relevant commit is from June and the commit message explicitly mentions this change. I would have said I added it after feedback from the group, but I can't find any minutes around the time that match this idea.
| <li>The element to which <code>aria-brailleroledescription</code> is applied does not have a valid WAI-ARIA <code>aria-roledescription</code>.</li> | ||
| <li>The element to which <code>aria-brailleroledescription</code> is applied has a valid WAI-ARIA <code>aria-roledescription</code> that is identical to a WAI-ARIA <code>role</code> or an implicit WAI-ARIA role semantic.</li> | ||
| </ol> | ||
| <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> |
There was a problem hiding this comment.
I don't understand the relevance of the example.
There was a problem hiding this comment.
This was copied from aria-roledescription. Does it make sense there but not here?
There was a problem hiding this comment.
Okay, I think I understand now. I might suggest something that references the comment in the context of the non-braille roledescription. ~"As with aria-roledescription, [change the role presentation, but don't change the functionality…]"
There was a problem hiding this comment.
Thanks, @cookiecrook. I'll add that.
| <li>If the value of <code>aria-brailleroledescription</code> consists only of Unicode characters that are not Unicode Braille Patterns, translate the value according to the user's preferred translation table.</li> | ||
| <li>If the value of <code>aria-brailleroledescription</code> consists only of Unicode Braille Patterns characters, pass the value to the user without translation.</li> | ||
| </ol> | ||
| <p>The following two examples show the use of <code>aria-brailleroledescription</code> to indicate that a button's description has a particular Braille contraction.</p> |
There was a problem hiding this comment.
"the following two examples"
"the following example"
* rephrase opening line - w3c#924 (comment) * Braille/braille capitalization - w3c#924 (comment) * suffice => overly verbose - w3c#924 (comment) * two examples show => example shows - w3c#924 (comment)
* rephrase opening line - w3c#924 (comment) * Braille/braille capitalization - w3c#924 (comment) * suffice => overly verbose - w3c#924 (comment) * two examples show => example shows - w3c#924 (comment)
* rephrase opening line - w3c#924 (comment) * Braille/braille capitalization - w3c#924 (comment) * suffice => overly verbose - w3c#924 (comment) * two examples show => example shows - w3c#924 (comment)
|
@cookiecrook I've created #1097 with the first couple of changes. |
|
I commented on the use of the phrase "Unicode Braille Patterns" earlier and the distinction between the block name and an individual character -- strings consist of characters not patterns, symbols, or glyphs. I'm happy to see that in one instance that distinction is properly used. However, since the time of my comment, there have been several changes to text and I think improper usage has creeped in again. Examples where I think changes are warranted so that the sentence is technically correct:
I suggest these become:
|
|
@NSoiffer copied to #1097 (comment) |
* rephrase opening line - w3c#924 (comment) * Braille/braille capitalization - w3c#924 (comment) * suffice => overly verbose - w3c#924 (comment) * two examples show => example shows - w3c#924 (comment)
Preview | Diff