Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index


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



Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.