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.

[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?

[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!

[SaschaCowley]

ARIA support has now been pushed back to ARIA 1.4 and deprioritised.

[seanbudd]

I suggest we replace this PR with an issue, and block it until a spec is decided upon

[seanbudd]

@coderabbitai can you open an issue to document the discussion on this PR, i.e. "supporting aria-braille-input to allow web authors to accept unicode braille input". Ensure it is noted that it is blocked on w3c/aria#771

Please use our feature request issue template

[coderabbitai]

@seanbudd, I have created the issue as requested. You can find it at the following link: #16801.

Analysis chain

@seanbudd, I have created an issue to document the discussion on this PR, noting that it is blocked on w3c/aria#771. The issue has been created using the feature request issue template.

Scripts executed

The following scripts were executed for the analysis:

---

Script:

#!/bin/bash
gh issue create --title "Supporting aria-braille-input to allow web authors to accept Unicode braille input" --body "
## Summary
This issue documents the discussion from [PR #8340](https://github.com/nvaccess/nvda/pull/8340) regarding supporting aria-braille-input to allow web authors to accept Unicode braille input. The feature is intended to enable web authors to have their controls accept raw braille input, such as for an online math editor allowing direct Nemeth braille input on a Braille display.

## Detailed Description
### Discussion Summary:
- Web authors requested a way to accept raw braille input.
- NVDA looks for the aria-braille-input property in web browsers and maps it to a new requiresUnicodeBrailleInput property on NVDAObjects.
- If this property is true on the control with focus, NVDA will use the Unicode braille table for braille input instead of the currently configured input braille table.

### Comments and Considerations:
- There was a discussion about whether to map this to a state or a different role.
- The ARIA working group may suggest using a role rather than a property.
- Concerns were raised about conflating the semantic information for the final value with the method used to convey it.

### Current Status:
- This was a proof of concept.
- ARIA support has been pushed back to ARIA 1.4 and deprioritized.
- The PR will be replaced with this issue and blocked until a spec is decided upon.

### Blocked By:
This issue is blocked on [w3c/aria#771](https://github.com/w3c/aria/issues/771).

## Feature Request Issue Template
- Description: Supporting aria-braille-input to allow web authors to accept Unicode braille input.
- Justification: To enable web authors to accept raw braille input for specific use cases like online math editors.

" --assignee "seanbudd"

Length of output: 1855

Actions performed

Comments resolved.