How to simulate a missing DPAD? (blind use of Alcatel OT-980)

[blindfold]

One of my blind users bought an Alcatel OT-980, which is an Android
2.1 budget phone with a physical QWERTY keyboard, but no d-pad (a bit
like the Motorola Droid Pro). The lack of physical navigation controls
here greatly impairs accessibility through TalkBack. To offer blind
access to menu and dialogs at least for my own app, I am trying to
remap the physical up and down volume keys to simulated up and down d-
pad keys using code like

@Override
public boolean onKeyDown(int keyCode, KeyEvent event) {
if (keyCode == KeyEvent.KEYCODE_VOLUME_DOWN) {
KeyEvent ke = new KeyEvent(KeyEvent.ACTION_DOWN,
KeyEvent.KEYCODE_DPAD_UP);
dispatchKeyEvent(ke);
return true;
}
return super.onKeyDown(keyCode, event);
}

However, although this works fine with a ListView and with activity
views that become *scrollable* because they are too large to fit on
the physical screen, it does not work at all for activity views that
remain small enough to fit on the screen. I can test this by
increasing the number of radio buttons in some activity view and then
see how the above key mapping begins to work fine as soon as there are
more controls than fit on the screen. I have tried all sorts of things
with setting focus after making things focusable using
setFocusable(true), setFocusableInTouchMode(true), requestFocus(),
requestFocusFromTouch() and so on, but nothing seems to help. Of
course the focus and selection event model of Android is not (yet)
designed with blind accessibility in mind, but this behavior is
counterintuitive at best. Am I missing some subtle trick? I am using
an HTC Desire with Android 2.2 for development and testing, but also
use an ADP1 with Android 1.6 for testing on a device with a physical
keyboard. Both devices show the indicated problem.

So what is a recommended and reliable way to remap physical keys to
perform key functions for which there are no physical keys on the
device?

Thanks


The vOICe for Android
http://www.seeingwithsound.com/android.htm

[blindfold]

This group did not yield any response. However, I finally found a
workaround myself after a similar inquiry on the android-developers
group indicated that it was uncertain if it could be done at all, and
you can find an outline of my solution in the discussion thread at

https://groups.google.com/group/android-developers/browse_thread/thread/e6fd851cf36d52ee/

Still, there currently remain a few user interface quirks when users
alternate between touch/keyboard mode navigation and volume key
navigation after entering a dialog, but this is not a big deal since
most users are expected (?) to use either one or the other. For
instance, when first using touch to navigate then there will be no
responsiveness to volume key navigation, and when first using volume
key navigation then touching a control (such as a radiobutton or
checkbox) will only change focus and a second tap is needed to change
the selection state of the control. I'm not aware of good
documentation on how Android deals with going in and out of touch mode
- as Dianne Hackborn put it.

Regards,

The vOICe for Android
http://www.seeingwithsound.com/android.htm

[Kirk Reiser]

Thanks Peter: it was a very interesting and enlightening discussion.
That looks like a good list to follow if most postings are as well
tended as yours.

Kirk

--
Well that's it then, colour me gone!

[blindfold]

You're welcome, Kirk. It seems that my remaining quirks with having to
touch controls twice to change their state are "by design" in Android,
so I consider them Android quirks:

http://code.google.com/p/android/issues/detail?id=3040
http://groups.google.com/group/android-developers/msg/f08563ea03d25bf6

Basically Android discourages mixing touch mode with key mode input,
even though we have good reasons to want to support both, for
different categories of users (blind and sighted).

Peter

On Dec 21, 7:36 pm, Kirk Reiser <k...@reisers.ca> wrote:
> Thanks Peter: it was a very interesting and enlightening discussion.
> That looks like a good list to follow if most postings are as well
> tended as yours.
>
>    Kirk
>
>
>
> On Tue, 21 Dec 2010, blindfold wrote:
> > This group did not yield any response. However, I finally found a
> > workaround myself after a similar inquiry on the android-developers
> > group indicated that it was uncertain if it could be done at all, and
> > you can find an outline of my solution in the discussion thread at
>

> >https://groups.google.com/group/android-developers/browse_thread/thre...

>
> > Still, there currently remain a few user interface quirks when users
> > alternate between touch/keyboard mode navigation and volume key
> > navigation after entering a dialog, but this is not a big deal since
> > most users are expected (?) to use either one or the other. For
> > instance, when first using touch to navigate then there will be no
> > responsiveness to volume key navigation, and when first using volume
> > key navigation then touching a control (such as a radiobutton or
> > checkbox) will only change focus and a second tap is needed to change
> > the selection state of the control. I'm not aware of good
> > documentation on how Android deals with going in and out of touch mode
> > - as Dianne Hackborn put it.
>
> > Regards,
>
> > The vOICe for Android
> >http://www.seeingwithsound.com/android.htm
>

> > On Dec 17, 9:17�am, blindfold <seeingwithso...@gmail.com> wrote:
> >> One of my blind users bought an Alcatel OT-980, which is an Android
> >> 2.1 budget phone with a physical QWERTY keyboard, but no d-pad (a bit
> >> like the Motorola Droid Pro). The lack of physical navigation controls
> >> here greatly impairs accessibility through TalkBack. To offer blind
> >> access to menu and dialogs at least for my own app, I am trying to
> >> remap the physical up and down volume keys to simulated up and down d-
> >> pad keys using code like
>

> >> � @Override
> >> � �public boolean onKeyDown(int keyCode, KeyEvent event) {
> >> � � � if (keyCode == KeyEvent.KEYCODE_VOLUME_DOWN) {
> >> � � � � �KeyEvent ke = new KeyEvent(KeyEvent.ACTION_DOWN,
> >> KeyEvent.KEYCODE_DPAD_UP);
> >> � � � � �dispatchKeyEvent(ke);
> >> � � � � �return true;
> >> � � � }
> >> � � � return super.onKeyDown(keyCode, event);
> >> � �}

[Kirk Reiser]

Interesting. Please understand my actual experience level thus far
is zilch so possibly my question is in appropriate, however is the
track-ball on some devices handled differently than arrow keys on a
phone with arrow keys on the keyboard? The reason I ask is I was
playing around with a colleagues Nexus-1 the other day which has a
track-ball and when I wanted to go back a level from the application I
was in just one touch on the back button which was a touch mode button
immediately performed the action. The same with other virtual buttons
on the screen so how is this different then what they are discussing
in the thread you provided?

>>> On Dec 17, 9:17�am, blindfold <seeingwithso...@gmail.com> wrote:
>>>> One of my blind users bought an Alcatel OT-980, which is an Android
>>>> 2.1 budget phone with a physical QWERTY keyboard, but no d-pad (a bit
>>>> like the Motorola Droid Pro). The lack of physical navigation controls
>>>> here greatly impairs accessibility through TalkBack. To offer blind
>>>> access to menu and dialogs at least for my own app, I am trying to
>>>> remap the physical up and down volume keys to simulated up and down d-
>>>> pad keys using code like
>>

>>>> � @Override
>>>> � �public boolean onKeyDown(int keyCode, KeyEvent event) {
>>>> � � � if (keyCode == KeyEvent.KEYCODE_VOLUME_DOWN) {
>>>> � � � � �KeyEvent ke = new KeyEvent(KeyEvent.ACTION_DOWN,
>>>> KeyEvent.KEYCODE_DPAD_UP);

>>>> � � � � �dispatchKeyEvent(ke);
>>>> � � � � �return true;
>>>> � � � }
>>>> � � � return super.onKeyDown(keyCode, event);
>>>> � �}
>>

[blindfold]

A trackball gives MotionEvents, which in turn can map to d-pad
KeyEvents,

http://developer.android.com/reference/android/view/View.html#onTrackballEvent%28android.view.MotionEvent
http://developer.motorola.com/docstools/library/Navigating_Around_Your_Application/

Unfortunately, some phones have neither a physical d-pad nor a
physical trackball, so one then needs still other physical controls
(e.g. remap the volume keys) since the touch screen is not currently
accessible to blind users.

On Dec 22, 12:20 am, Kirk Reiser <k...@reisers.ca> wrote:
> Interesting.  Please understand my actual experience level thus far
> is zilch so possibly my question is in appropriate, however is the
> track-ball on some devices handled differently than arrow keys on a
> phone with arrow keys on the keyboard?  The reason I ask is I was
> playing around with a colleagues Nexus-1 the other day which has a
> track-ball and when I wanted to go back a level from the application I
> was in just one touch on the back button which was a touch mode button
> immediately performed the action.  The same with other virtual buttons
> on the screen so how is this different then what they are discussing
> in the thread you provided?
>
>    Kirk
>
>
>
> On Tue, 21 Dec 2010, blindfold wrote:
> > You're welcome, Kirk. It seems that my remaining quirks with having to
> > touch controls twice to change their state are "by design" in Android,
> > so I consider them Android quirks:
>
> >http://code.google.com/p/android/issues/detail?id=3040
> >http://groups.google.com/group/android-developers/msg/f08563ea03d25bf6
>
> > Basically Android discourages mixing touch mode with key mode input,
> > even though we have good reasons to want to support both, for
> > different categories of users (blind and sighted).
>
> > Peter
>

> > On Dec 21, 7:36�pm, Kirk Reiser <k...@reisers.ca> wrote:
> >> Thanks Peter: it was a very interesting and enlightening discussion.
> >> That looks like a good list to follow if most postings are as well
> >> tended as yours.
>

> >> � �Kirk

>
> >> On Tue, 21 Dec 2010, blindfold wrote:
> >>> This group did not yield any response. However, I finally found a
> >>> workaround myself after a similar inquiry on the android-developers
> >>> group indicated that it was uncertain if it could be done at all, and
> >>> you can find an outline of my solution in the discussion thread at
>
> >>>https://groups.google.com/group/android-developers/browse_thread/thre...
>
> >>> Still, there currently remain a few user interface quirks when users
> >>> alternate between touch/keyboard mode navigation and volume key
> >>> navigation after entering a dialog, but this is not a big deal since
> >>> most users are expected (?) to use either one or the other. For
> >>> instance, when first using touch to navigate then there will be no
> >>> responsiveness to volume key navigation, and when first using volume
> >>> key navigation then touching a control (such as a radiobutton or
> >>> checkbox) will only change focus and a second tap is needed to change
> >>> the selection state of the control. I'm not aware of good
> >>> documentation on how Android deals with going in and out of touch mode
> >>> - as Dianne Hackborn put it.
>
> >>> Regards,
>
> >>> The vOICe for Android
> >>>http://www.seeingwithsound.com/android.htm
>

> >>> On Dec 17, 9:17�am, blindfold <seeingwithso...@gmail.com> wrote:
> >>>> One of my blind users bought an Alcatel OT-980, which is an Android
> >>>> 2.1 budget phone with a physical QWERTY keyboard, but no d-pad (a bit
> >>>> like the Motorola Droid Pro). The lack of physical navigation controls
> >>>> here greatly impairs accessibility through TalkBack. To offer blind
> >>>> access to menu and dialogs at least for my own app, I am trying to
> >>>> remap the physical up and down volume keys to simulated up and down d-
> >>>> pad keys using code like
>

> >>>> � @Override
> >>>> � �public boolean onKeyDown(int keyCode, KeyEvent event) {
> >>>> � � � if (keyCode == KeyEvent.KEYCODE_VOLUME_DOWN) {

> >>>> � � � � �KeyEvent ke = new KeyEvent(KeyEvent.ACTION_DOWN,
> >>>> KeyEvent.KEYCODE_DPAD_UP);

> >>>> � � � � �dispatchKeyEvent(ke);
> >>>> � � � � �return true;
> >>>> � � � }
> >>>> � � � return super.onKeyDown(keyCode, event);
> >>>> � �}
>