Re: [Libreoffice] [PATCH] vcl: Printing UI "page range" autofocus

Hi Michael, Christophe,

The accessibility issue is important indeed. I think a solution could be to
automatically move the focus only in response to mouse click, and not keys
(either tab or up/down arrow). This could solve the problem of keyboard /
screen reader users.

From the technical point of view, maybe a global solution would be most
appropriate here. I mean, the function GrabFocus() could be modified to work
only for mouse clicks. I think it is mostly responsible for such focus
movements.

Thank you,
 -- Maxim.

On Mon, Oct 24, 2011 at 3:24 PM, Michael Meeks <michael.meeks@suse.com>wrote:

> Hi Maxime,
>
> On Mon, 2011-10-24 at 14:52 +0200, Christophe Strobbe wrote:
> > At 06:50 22-10-2011, Maxim Iorsh wrote:
> > > When the user selects "Pages" radio button in the Range section, it is
> very
> > > reasonable to expect that she would now want to specify the range. Thus
> moving
> > > the focus automatically to the page range edit box would save the user a
> mouse
> > > click.
>
>         Which looks nice ! :-)
>
> > Unrequested focus changes that are not announced in advance are not
> > good practice for accessibility reasons.
>
>        Unfortunately, I suspect Christophe is right, so - presumably we
> need
> to do this in a slightly more cunning fashion (ditto for the PDF case).
> I wonder what ways those could be - personally I love the easier to use,
> more ergonomic UI change you suggest - and surely it'd help improve life
> for impaired people too if they could find out about it.
>
>        The tab navigation ordering is already somewhat strange in the print
> dialog with the "Print in reverse page order" appearing in the chain
> before the radio buttons above it - which might be worth fixing too.
>
> On Mon, 2011-10-24 at 14:52 +0200, Christophe Strobbe wrote:
> > 1. When a screen reader user (typically a blind user) encounters a
> > set of radio buttons, the only way to find out what the buttons are,
> > is going through them with the up/down arrow.
>
>        Surely the screen reader knows these are part of a radio button
> group
> and has relations it can use to read out the options ?
>
> > 2. Keyboard users (not only blind users) move through dialogs like
> > the Print dialog with the Tab key and the Shift+Tab key. The latter
> > is for navigating backwards. With this patch, what happens when the
> > user presses Shift+Tab from the Page Range field in order to move
> > back to the radio buttons ?
>
>        It works fine; you go from the entry back to the Pages button (which
> is
> already selected so we don't get a new selection event) and then you can
> use up and down arrows.
>
> > Does the focus immediately get pushed back
> > to the edit field, making backwards navigation impossible?
>
>        So no, this is fine, but good to check.
>
>        For what it is worth the current situation for a blind user tabbing
> through that dialog is pretty horrible too - the 'tab' goes from 'All
> Pages' to the 'Pages' entry field (which is not insensitive when the
> Page range thing is unselected), and so on.
>
>         So - IMHO, if the Pages entry (which we auto-focus) has a suitable
> label (saying 'Page range') that a screen reader can read, and we handle
> insensitivity better there - we already made the UI rather better for
> the impaired. More ideally, if we can clobber the up/down arrow on the
> keyboard to move to previous / next radio button in the group we improve
> things all around - right ? [ and fixing the tab chain looks like it
> would be nice too - but I'm not clear on the APIs for doing that - is it
> really just the order of instantiation of the widgets in
> vcl/source/window/printdlg.cxx eg. ? ].
>
>        How does that sound ? and thanks Maxim for caring enough to improve
> these rough edges ! :-)
>
>        All the best,
>
>                Michael.
>
> --
> michael.meeks@suse.com  <><, Pseudo Engineer, itinerant idiot