Re: Interfacing iOS App with refreshable braille display
Re: Interfacing iOS App with refreshable braille display
- Subject: Re: Interfacing iOS App with refreshable braille display
- From: Boris Dušek <email@hidden>
- Date: Fri, 01 Aug 2014 09:33:45 +0200
Hi Ray,
31. 7. 2014 v 9:27 dop., Chi Cheung <email@hidden>:
> One way to do this would be to capture the ASCII braille output from the braille display in an UITextField, whereby each key combination would result in a unique ASCII character. Unfortunately the 8-dot uncontracted braille setting does not translate to ASCII braille 100% of the time (e.g. dots 4-5-6 should result in an ASCII underscore symbol, but instead calls a backspace/delete action within the UITextField).
there is other problem: different languages translate certain combinations differently. E.g. in English, combination 2456 is for "w", but in Czech, 2456 is for "ř" (what is more, the character is non-ASCII), "w" in Czech is 12356 (and I don’t know what 12356 is in English :-).
On top of that, as you slightly hinted you have the possibility of the user to choose 6-dot vs. 8-dot input, which complicates things further.
In other words, deducing the braille key combination pressed from the character entered into UITextField is language-dependent and settings-dependent.
> Also, I'm not sure if there is a way to access the output of the braille display prior to it being translated by VoiceOver into text.
I am afraid there is no way you can tap into the layer below - raw events from the braille display. Only idea in my head right now (I cannot and don’t have the time to try it now) is whether there is some information about the actual braille key combination pressed in the corresponding UIEvent - like a "raw key" or "virtual key“ (I played with this once in NSEvent with a normal keyboard).
Other way to operate an app using braille display, which is probably less comfortable to the user, might be to use the router keys (the buttons above each braille cell) to move the text cursor in a UITextField. You could detect this movement in the UITextField (this should be more reliable than deducing key combination from character entered), to (trivially) deduce which router key was pressed, but: 1. does not support multiple such buttons (router keys) pressed at the same time, and 2. is much less comfortable for the user, as the router keys are too close to each other, 3. pressing the same router key again will probably result in no movement of text cursor, so you will not get that event. On the other hand, there can be a letter displayed for each braille cell that would serve as a „hint“ for the respective router key.
But all this is hackish (except maybe for the UIEvent idea above, but still, the superfluous UITextField...).
Cheers,
Boris
--
Boris Dušek
R&D, tech support
A11Y LTD.
a11y.ltd.uk
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Accessibility-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden