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.me...@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.me...@suse.com <><, Pseudo Engineer, itinerant idiot > >
_______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
