feat: aria-braillelabel #923
feat: aria-braillelabel #923
8000Conversation
|
This link should always point to the current version, even after more changes are made to Peter's branch: https://raw.githack.com/pkra/aria/braille-props-label/index.html#aria-label-braille (This was edited to remove the old commit-specific link.) |
|
I support the proposal in general. It isn't clear what "uncontracted braille ASCII" means (and I'm very familiar with braille and braille-related technology). I would suggest either eliminating (my preference) or defining that possibility so that assistive technology developers know precisely what to expect in the string. |
|
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) |
|
Thanks for the comments so far! @jasonjgw wrote
Thanks for calling this out - it is something I wanted to bring up in the meeting. I've been trying to capture the previous discussions on the mailing list (in particular with AT developers) and the call in February around this. But I'm not as well versed at Braille Ascii encodings.I got "uncontracted" from RNIB. Would just "Grade 1" make more sense? The basic idea from the discussions was that AT should be able to push the content of the Braille label to a Braille display as directly as possible. A key goal for this SHOULD statement is to avoid additional markup to indicate encoding (in particular to avoid authoring errors). @johnfoliot wrote
I generally agree. However, I left it as before to connect to previous discussions and because the question had come up whether a more general Braille (or tactile) namespace might be preferential. If I remember correctly, this came up in the context of potential outcomes from the APA pronounciation task force which might face similar questions. |
|
@pkra I again caution you on attempting a micro-syntax (i.e. namespacing) in ARIA. I'll +1 Jon Gunderson's suggestions (i.e. aria-braillelabel, aria-brailleroledescription) for addressing the need of signifying braille-centric attributes. |
|
The problem is that there is no single standard mapping even from the printable ASCII subset of Unicode to a braille representation. There are different ASCII->braille tables used in different countries (e.g., the North american ASCII->braille table is different from the German table, and similarly for other locales - and I'm not even sure that either is officially standardized anywhere). "Grade 1" doesn't help in this context, as it wouldn't specify any mapping of ASCII characters to braille cells. The only absolutely standard and unambiguous way to do it is with the Unicode block set aside for this purpose, which is why I would prefer to eliminate the ASCII-based option. The only alternative would be to find a suitable normative reference that specifies the mapping of printable ASCII to six-dot braille. In effect, you would be choosing one of the mappings that have been implemented. |
|
+1 to @johnfoliot's +1 to @jongund's attribute naming suggestions. :) Just looking a bit further down the road, and applying the "remove hyphen; camelcase the rest" pattern, they would be reflected as follows:
which would sort them together in developer tooling (more useful than having "-braille" at the end). cc @cookiecrook for info |
|
+1 to @johnfoliot's and @jongund's suggestions. +1 to @carmacleod's adjustments/formatting. |
|
To be clear... CamelCasing is useful for "instructional" reasons, however attributes SHOULD be case-insensitive, and earlier compounded attributes in the spec have not traditionally been rendered in CamelCase (eg. aria-posinset vs. aria-PosInSet, aria-labeledby vs. aria-LabeledBy, etc.). Consistency in naming conventions should also be considered. |
|
@johnfoliot and @charmarkk: I believe @carmacleod was specifically talking about the "reflected" properties which is for AOM. Thus the official properties added to ARIA would NOT be camel-cased. |
|
I'm having trouble understanding the use case here. Screen reader braille implementations are usually complex, allowing users to customize braille verbosity, use different translation tables in different contexts, etc. Perhaps someone could explain the "proposal" since no description was included above. Whatever the case, this edit should not be included without clear example illustrating the utility of the feature, and a clear description as to when/why/where this should be used instead of letting the screen reader do its thing. PS. This caveat should definitely be removed as it's not internationalizable.
|
|
@cookiecrook thanks for your comment. Some references to previous discussions:
Yes; this was the agreement during last week's meeting. |
|
Commented in detail on #765 |
|
while in general I am not in favor of separate labels I believe this could be useful for situations like a math where we need to show unified English braille or Nemeth code but have something different announced in speech. |
|
I've updated the branch with a re-write that stays close to the language in #1097. |
|
Regarding:
I don't understand why we wouldn't change the accessible name and description computation to allow We have said that:
So it seems kind of strange to me that (Of course, I know very little about Braille, and it is very likely that I am missing something here). |
|
I wish to state an enthusiastic agreement about confusion around why aria-labelledby is overriding aria-braillelabel. Aria-braillelabelledby should absolutely override aria-braillelabel, yes, but cross-modality priority for aria-labelledby seems wrong in my opinion. If we have an element with aria-braillelabel and aria-labelledby, the author has made a clear choice to override the label in braille and to provide an accessible label for non-braille users.
|
|
Thanks, @carmacleod , @sinabahram! I agree that this is a bit confusing (and the first draft had marked this part TBD because I felt the same way). When we discussed it on a WG call, the initial agreement was that we wouldn't need "braille labelled by" (or described by) since a braille label can/should be on the target of the labelledBy. This also makes sense since that is where the element gets its name from. Otherwise, we end up "splitting up" names to come from different elements which might be problematic for implementors and authors alike. That's just to recap -- I'm happy to reconsider. |
Addresses w3c#923 (comment)
Addresses w3c#923 (comment)
|
I've just pushed an update that modifies the code example as per the discussion; I also adjusted the sentence after the pre element to match the changes. I think this addresses all comments so far - with the exception of #1205. Please let me know if I missed a comment and if there are any additional comments we should address before merging. (And #1205 will ensure an opportunity for further comments later on, too.) |
|
@jnurthen I requested a review from you as per yesterday's telco. Should I clean up the branch before or after your review? (I must have rebased badly at some point, introducing more than 100 unrelated commits). |
As per WG discussions.
Addresses w3c#923 (comment)
* removes sentence on accessible name computation * editorial: "should" to "is" in "author should" list; code example fix
Addresses w3c#923 (review)
Update code example
Addresses w3c#923 (comment)
Can you please fix... I can't really review in this state. |
|
@jnurthen this was a bit weird. I tried a new PR from the the same branch and github's preview shows none of those commits. Anyway, I'll force push and see if that improves things. |
16cfa12 to
0605572
Compare
|
@jnurthen the git history should be reasonable now. |
|
@jnurthen is it reviewable now or do you need me to try a completely squashed version? |
Yes - only 1 file changed now so all good. |
…ions (#2039) This adds the following string reflections to ARIAMixin: - `ariaBrailleLabel` -> `aria-braillelabel` - `ariaBrailleRoleDescription` -> `aria-brailleroledescription` These reflections are already implemented in Chromium (see [here](https://source.chromium.org/chromium/chromium/src/+/main:out/fuchsia-Debug/gen/third_party/blink/renderer/bindings/modules/v8/v8_element.cc;l=1201;drc=168fe20dbf8ab7e47e36db5e528ec3c95c2f8af0) and [here](https://source.chromium.org/chromium/chromium/src/+/main:out/fuchsia-Debug/gen/third_party/blink/renderer/bindings/modules/v8/v8_element.cc;l=1228;drc=168fe20dbf8ab7e47e36db5e528ec3c95c2f8af0)), but not yet in WebKit or Firefox. The purpose of this PR is to align with the de-facto behavior of Chromium. I don't see a strong reason for the spec not to include these particular reflections. (If there is one, please let me know!) See also: #923 # PR tracking Check these when the relevant issue or PR has been made, OR after you have confirmed the related change is not necessary (add N/A). Leave unchecked if you are unsure. Read the [Process Document](https://github.com/w3c/aria/wiki/ARIA-WG-Process-Document/_edit) or [Test Overview](https://github.com/w3c/aria/wiki/ARIA-Test-Overview) for more information. * [x] Related Core AAM Issue/PR: does not apply * [x] Related AccName Issue/PR: does not apply * [x] Related APG Issue/PR: does not apply * [x] Any other dependent changes? no. # Implementation tracking * [x] "author MUST" tests: does not apply * [x] "user agent MUST" tests: web-platform-tests/wpt#42751 * [x] Browser implementations (link to issue or when done, link to commit): * WebKit: No (https://bugs.webkit.org/show_bug.cgi?id=263663) * Gecko: No (https://bugzilla.mozilla.org/show_bug.cgi?id=1861201) * Blink: [here](https://source.chromium.org/chromium/chromium/src/+/main:out/fuchsia-Debug/gen/third_party/blink/renderer/bindings/modules/v8/v8_element.cc;l=1201;drc=168fe20dbf8ab7e47e36db5e528ec3c95c2f8af0) and [here](https://source.chromium.org/chromium/chromium/src/+/main:out/fuchsia-Debug/gen/third_party/blink/renderer/bindings/modules/v8/v8_element.cc;l=1228;drc=168fe20dbf8ab7e47e36db5e528ec3c95c2f8af0) * [x] Does this need AT implementations? no.
Preview | Diff