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

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.

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 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).
...
I would strongly encourage the ARIA WG to maintain that pattern (aria-labelbraille,
aria-roledescriptionbraille) if these new attributes are to move forward.

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.

@johnfoliot

@pkra I again caution you on attempting a micro-syntax (i.e. namespacing) in ARIA.

FWIW I agree. I'm documenting the discussion in the WG here.

@jasonjgw wrote

I would prefer to eliminate the ASCII-based option.

FWIW I would prefer that as well. I'm documenting the discussion in the WG here.

+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:

• aria-braillelabel = ariaBrailleLabel
• aria-brailleroledescription = ariaBrailleRoleDescription

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.

or of a string of uncontracted (Grade 1) Braille ASCII.

@cookiecrook thanks for your comment.

Some references to previous discussions:

• Consider addition of property(ies) to expose braille string #765
• meeting minutes from meetings where this topic was discussed
  • https://lists.w3.org/Archives/Public/public-aria/2019Jan/0028.html
  • https://lists.w3.org/Archives/Public/public-aria/2019Apr/0015.html
• other email discussions
  • https://lists.w3.org/Archives/Public/public-aria/2019Feb/0003.html
  • https://lists.w3.org/Archives/Public/public-aria/2019Apr/0005.html

PS. This caveat should definitely be removed as it's not internationalizable.

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:

As required by the accessible name and description computation, user agents give precedence to aria-labelledby over aria-braillelabel when computing the accessible Braille name property.

I don't understand why we wouldn't change the accessible name and description computation to allow aria-braillelabel to override aria-labelledby?

We have said that:

The aria-braillelabel property gives authors the ability to override how assistive technologies localize and express the accessible name of an element in Braille.

So it seems kind of strange to me that aria-braillelabel can override the accessible name if it was provided by content, or by an aria-label, or presumably by host language labelling techniques such as <label>, but we wouldn't allow it to override the one case where the accessible name happens to come from aria-labelledby? Why is that?

(Of course, I know very little about Braille, and it is very likely that I am missing something here).

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.

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).

@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).

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.

@jnurthen the git history should be reasonable now.

@jnurthen is it reviewable now or do you need me to try a completely squashed version?

@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.