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

[Christophe Strobbe]

Hi Maxim, Michael,

At 15:24 24-10-2011, Michael Meeks 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.

I also noticed this and was going to register a bug for this.



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

When you get to a set of radio buttons, the screen reader tells you, e.g.
"All pages, selected radio button" but it does not tell you how many radio
buttons there are in the set (unless there is a shortcut for this that I'm
not aware of). You need to move the focus to the next radio buttons to find
out their values and how many there are in the set. (I tested this with both
NVDA on Windows and Orca on Ubuntu 11.04.)
Navigating through the radio buttons with the arrow keys also moves the
selection, i.e. the one you are reading is always in a "checked" state.



> > 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.

Ah, OK, this sounds good. :-)


> > Does the focus immediately get pushed back
> > to the edit field, making backwards navigation impossible?
>
>         So no, this is fine, but good to check.

This sounds good. :-)



>         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.

The page range edit field has some kind of invisible label (NVDA and Orca
speak something that is not visible in the dialog); unfortunately
it contains the text "Number of copies" (or there is a bug that causes
the label for the "Number of copies" field to be read again).


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

The up/down arrows already do that, unless you meant something that I
missed?


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

(Reminder to self: start reading that book on C++ you bought last Saturday.)



>         How does that sound ?

Looks like some nice improvements.
I had not thought of the modification to listen only to mouse clicks, which
Maxim just suggested.


>and thanks Maxim for caring enough to improve
>these rough edges ! :-)

+1!

Best regards,

Christophe



>         All the best,
>
>                 Michael.
>
>--
>michael.meeks at suse.com  <><, Pseudo Engineer, itinerant idiot


-- 
Christophe Strobbe
K.U.Leuven - Dept. of Electrical Engineering - SCD
Research Group on Document Architectures
Kasteelpark Arenberg 10 bus 2442
B-3001 Leuven-Heverlee
BELGIUM
tel: +32 16 32 85 51
http://www.docarch.be/
Twitter: @RabelaisA11y
---
Open source for accessibility: results from the AEGIS project 
www.aegis-project.eu
---
Please don't invite me to Facebook, Quechup or other "social 
networks". You may have agreed to their "privacy policy", but I haven't.