No subject
Mon Oct 24 06:20:31 PDT 2011
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 at 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 at suse.com <><, Pseudo Engineer, itinerant idiot
>
>
--90e6ba1efd3ad3399304b00be33b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi Michael, Christophe,<br><br>The accessibility issue is =
important indeed. I think a solution could be to automatically move the foc=
us only in response to mouse click, and not keys (either tab or up/down arr=
ow). This could solve the problem of keyboard / screen reader users.<br>
<br>From the technical point of view, maybe a global solution would be most=
appropriate here. I mean, the function GrabFocus() could be modified to wo=
rk only for mouse clicks. I think it is mostly responsible for such focus m=
ovements.<br>
<br>Thank you,<br>=C2=A0-- Maxim.<br><br><div class=3D"gmail_quote">On Mon,=
Oct 24, 2011 at 3:24 PM, Michael Meeks <span dir=3D"ltr"><<a href=3D"ma=
ilto:michael.meeks at suse.com" target=3D"_blank">michael.meeks at suse.com</a>&g=
t;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde=
r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Hi Maxime,<br>
<br>
On Mon, 2011-10-24 at 14:52 +0200, Christophe Strobbe wrote:<br>
<div>> At 06:<a href=3D"tel:50%2022-10-2011" value=3D"+15022102011" targ=
et=3D"_blank">50 22-10-2011</a>, Maxim Iorsh wrote:<br>
> >When the user selects "Pages" radio button in the Range =
section, it is very<br>
> >reasonable to expect that she would now want to specify the range.=
Thus moving<br>
> >the focus automatically to the page range edit box would save the =
user a mouse<br>
> >click.<br>
<br>
</div> =C2=A0 =C2=A0 =C2=A0 =C2=A0Which looks nice ! :-)<br>
<br>
> Unrequested focus changes that are not announced in advance are not<br=
>
> good practice for accessibility reasons.<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0Unfortunately, I suspect Christophe is right, s=
o - presumably we need<br>
to do this in a slightly more cunning fashion (ditto for the PDF case).<br>
I wonder what ways those could be - personally I love the easier to use,<br=
>
more ergonomic UI change you suggest - and surely it'd help improve lif=
e<br>
for impaired people too if they could find out about it.<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0The tab navigation ordering is already somewhat=
strange in the print<br>
dialog with the "Print in reverse page order" appearing in the ch=
ain<br>
before the radio buttons above it - which might be worth fixing too.<br>
<br>
On Mon, 2011-10-24 at 14:52 +0200, Christophe Strobbe wrote:<br>
> 1. When a screen reader user (typically a blind user) encounters a<br>
> set of radio buttons, the only way to find out what the buttons are,<b=
r>
> is going through them with the up/down arrow.<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0Surely the screen reader knows these are part o=
f a radio button group<br>
and has relations it can use to read out the options ?<br>
<br>
> 2. Keyboard users (not only blind users) move through dialogs like<br>
> the Print dialog with the Tab key and the Shift+Tab key. The latter<br=
>
> is for navigating backwards. With this patch, what happens when the<br=
>
> user presses Shift+Tab from the Page Range field in order to move<br>
> back to the radio buttons ?<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0It works fine; you go from the entry back to th=
e Pages button (which is<br>
already selected so we don't get a new selection event) and then you ca=
n<br>
use up and down arrows.<br>
<br>
> Does the focus immediately get pushed back<br>
> to the edit field, making backwards navigation impossible?<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0So no, this is fine, but good to check.<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0For what it is worth the current situation for =
a blind user tabbing<br>
through that dialog is pretty horrible too - the 'tab' goes from &#=
39;All<br>
Pages' to the 'Pages' entry field (which is not insensitive whe=
n the<br>
Page range thing is unselected), and so on.<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 So - IMHO, if the Pages entry (which we auto-f=
ocus) has a suitable<br>
label (saying 'Page range') that a screen reader can read, and we h=
andle<br>
insensitivity better there - we already made the UI rather better for<br>
the impaired. More ideally, if we can clobber the up/down arrow on the<br>
keyboard to move to previous / next radio button in the group we improve<br=
>
things all around - right ? [ and fixing the tab chain looks like it<br>
would be nice too - but I'm not clear on the APIs for doing that - is i=
t<br>
really just the order of instantiation of the widgets in<br>
vcl/source/window/printdlg.cxx eg. ? ].<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0How does that sound ? and thanks Maxim for cari=
ng enough to improve<br>
these rough edges ! :-)<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0All the best,<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Michael.<br>
<font color=3D"#888888"><br>
--<br>
<a href=3D"mailto:michael.meeks at suse.com" target=3D"_blank">michael.meeks at s=
use.com</a> =C2=A0<><, Pseudo Engineer, itinerant idiot<br>
<br>
</font></blockquote></div><br></div>
--90e6ba1efd3ad3399304b00be33b--
More information about the LibreOffice
mailing list