Support aria-braille-input to allow web authors to accept unicode braille input

[michaelDCurran]

Link to issue number:

None.

Summary of the issue:

Web authors have asked for a way to have their controls accept raw braille input. An example where this would be useful would be an online math editor that could allow the user to directly type in Nemeth braille input on a Braille display.

Description of how this pull request fixes the issue:

A new aria-braille-input attribute is going to be proposed to the ARIA working group for consideration (see w3c/aria#771). NVDA looks for this property in all web browsers, and maps it to a new requiresUnicodeBrailleInput property on NVDAObjects.
If this property is true on the control with focus, then NVDA will automatically use the unicode braille table for braille input rather than the currently configured input braille table.

Testing performed:

Testcase: https://sinabahram.github.io/aria-playground/BrailleInput.html
The first control takes normal text, the second control takes braille input (as aria-braille-input has a value of "true").
Tested in Firefox and Internet Explorer.

Known issues with pull request:

Although NVDA supports this property in IA2, MSHTML and UIA, it does not currently work in Edge or Chrome due to these browsers not exposing unknown ARIA properties.

Change log entry:

[josephsl]

CC @derekriemer, @LeonarddeR, @dkager

[LeonarddeR]

Is there a particular reason why you did not yet map this to a state, or even a different role?

[michaelDCurran]

For many years now, we have wanted to move away from states, as they are very inefficient as  usually more information is fetched than what you actually need. We could in deed use a role. The ARIA workinggroup may well suggest that it should be an ARIA role rather than an ARIA property. In that case, we too should use a role.

[jcsteh]

At the end of the day, this is still essentially a text box, so I'd suggest a new role isn't appropriate. This is more like HTML <input type="email">, which is a text input specific to email addresses. We're just saying this is a text input specific to Unicode braille. Thus, I've proposed aria-text-input-type="braille".

[feerrenrut]

I think we might need to be careful here, at the most basic level we are talking about getting raw, untranslated braille input from the screenreader. This may be to a text input field or some other element receiving the input. At a low level its about disabling translation of the dots that are input by the user, and says nothing about how this may be displayed to the user in the web page.

[jcsteh]

I'd want to see use cases for non-text inputs accepting raw braille. I understand that's how it's implemented in NVDA, but whether it's appropriate for such a low level concept to be supported by the spec is a different matter. Supporting such a low level concept is bordering on saying that semantics are irrelevant, and that's a dangerous precedent to set for ARIA. FWIW, users can already choose to enter raw braille input into a text box, but they'd have to manually switch their input table. As I see this, it's just a hint to the screen reader saying "this text input accepts braille dots", comparable to "this text input accepts an email address". Still, I guess this is a matter to debate at the spec level.

[feerrenrut]

I'm worried about conflating the semantic information for the final value e.g. "email" with the method used to convey it e.g. "braille". What about handwriting, speech, or sign?

[jcsteh]

That's a fair point. It's tricky because for something like speech or handwriting, the web app would just use web APIs to grab that input directly from the user (via touch events or the WebSpeech API). In this case, there's no "web API" for retrieving dots from a braille keyboard. So, I guess aria-text-input-type might be too specific. However, I still think aria-input-type="braille" might allow for less future attribute clutter than aria-braille-input="true".

[feerrenrut]

I still think aria-input-type="braille" might allow for less future attribute clutter than aria-braille-input="true".

Absolutely with you on that one.

[dpy013]

Is this PR still going on?

[michaelDCurran]

This will go into NVDA when/if the ARIA standards group were to accept this in the standard.

[LeonarddeR]

@michaelDCurran Is this still expected to be used at some point?

[dpy013]

@michaelDCurran Is this still expected to be used at some point?

This function is quite good, I hope to merge to master.
thank

[michaelDCurran]

Again, we will only do something about this if it becomes an ARIA standard. This was a proof of concept.

[LeonarddeR]

Coming across this again, given how we handled pr's like this recently, wouldn't it be better to close this and revisit it when this is ever needed again? Or, at least, make it a draft given the proof of concept state of the work?

[michaelDCurran]

@LeonarddeR I agree. It is now a draft.

[pkra]

I'm trying to revive this idea on the ARIA end (hoping we can still get this into ARIA 1.3) and I've extracted part of this thread at w3c/aria#771 (comment). If you could add or correct what I wrote over there, it would be most helpful!