Bug 107625 - Envelope dialog: Make dialog more a11y friendly
Summary: Envelope dialog: Make dialog more a11y friendly
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsUXEval
Depends on:
Blocks: a11y Dialog Envelope
  Show dependency treegraph
 
Reported: 2017-05-04 12:58 UTC by Alex ARNAUD
Modified: 2019-04-24 14:26 UTC (History)
15 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alex ARNAUD 2017-05-04 12:58:20 UTC
Description:
Dear all,

Tested environment :
- LibreOfficeDev 5.4 on Debian GNU/Linux 8.7
- LibreOffice 5.3.2 on Windows 8.1

I'm a low-vision person so I'm a keyboard-only user. At this time it is not possible to use the envelope dialog only with the keyboard because

it's not possible to leave the texts fields with tab. 

Steps to Reproduce:
Steps to reproduce :
1) Open the envelope dialog (insert => envelope)
2) Press tab or ctrl+tab 

Actual Results:  
LibreOffice writes the tab character or switches to the next tab 

Expected Results:
LibreOffice should leave the text field when I press tab


Reproducible: Always

User Profile Reset: No

Additional Info:
Best regards.


User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0
Comment 1 Yousuf Philips (jay) (retired) 2017-05-04 13:16:12 UTC
(In reply to Alex ARNAUD from comment #0)
> it's not possible to leave the texts fields with tab. 

As its is a multiline textbox and not a single line textbox, tabs are treated as tabs, but shift+tab works as it should. Ctrl+tab is for switching tabs of the dialog.

@Stuart: If you disagree, please reopen.
Comment 2 Xisco Faulí 2017-05-04 13:21:29 UTC
As Jay mentioned, shift + tab does the trick here.
Comment 3 Alex ARNAUD 2017-05-04 13:48:06 UTC
(In reply to Yousuf Philips (jay) from comment #1)
> (In reply to Alex ARNAUD from comment #0)
> > it's not possible to leave the texts fields with tab. 
> 
> As its is a multiline textbox and not a single line textbox, tabs are
> treated as tabs, but shift+tab works as it should. Ctrl+tab is for switching
> tabs of the dialog.
> 
> @Stuart: If you disagree, please reopen.

Your mind is correct for a sighted persons.

Do you really think that a blind person should read the content of the dialog in reverse order ? It's already quite complicated to understand the screen for the blinds persons so IMO it isn't user-friendly.

The envelope dialog is important for persons unable to write sender on the enveloper themselves.

Best regards.
Comment 4 Raphaël POITEVIN 2017-05-04 15:04:23 UTC
Hi!

I totally agree with Alexarnaud. I'm blind to. Reverse navigating through the dialog takes a while!

Regards,

Raphaël
Comment 5 Yousuf Philips (jay) (retired) 2017-05-04 15:37:33 UTC
(In reply to Alex ARNAUD from comment #3)
> Do you really think that a blind person should read the content of the
> dialog in reverse order ? It's already quite complicated to understand the
> screen for the blinds persons so IMO it isn't user-friendly.

The bug report was opened about not being able to leave the textbox, which was incorrect, which is a different issue of the dialog not being a11y friendly. If you'd like to suggests ways to improve the dialog to make it easier for a11y users to work in it, i'm always up to hearing them. So let's use this bug for that rather than opening up a new one.

So in other apps, when a user arrives at a multiline textbox that is to contain tab characters in it, how does navigation work there? I've checked some apps and some do not permit you to press tab in them (e.g. thunderbird's new contact dialog's other tab), while others do (qbittorrent's options dialog's bittorrent tab).
Comment 6 Xisco Faulí 2017-05-04 15:44:26 UTC
Can be also reproduced in

LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-3.3.0.4
Comment 7 Alex ARNAUD 2017-05-04 16:36:45 UTC
(In reply to Yousuf Philips (jay) from comment #5)
> The bug report was opened about not being able to leave the textbox, which
> was incorrect, which is a different issue of the dialog not being a11y
> friendly. If you'd like to suggests ways to improve the dialog to make it
> easier for a11y users to work in it, i'm always up to hearing them. So let's
> use this bug for that rather than opening up a new one.

You are completely right.

> So in other apps, when a user arrives at a multiline textbox that is to
> contain tab characters in it, how does navigation work there? I've checked
> some apps and some do not permit you to press tab in them (e.g.
> thunderbird's new contact dialog's other tab), while others do
> (qbittorrent's options dialog's bittorrent tab).

I propose this two behavior : 
- Disabling the usage of tab in theses fields
or
- ctrl+tab in theses fields leave them, switching between tabs could be done with ctrl+tab when the user keyboard focus is on an other item.

Best regards.
Comment 8 Yousuf Philips (jay) (retired) 2017-05-04 16:53:45 UTC
(In reply to Alex ARNAUD from comment #7)
> > So in other apps, when a user arrives at a multiline textbox that is to
> > contain tab characters in it, how does navigation work there? I've checked
> > some apps and some do not permit you to press tab in them (e.g.
> > thunderbird's new contact dialog's other tab), while others do
> > (qbittorrent's options dialog's bittorrent tab).
> 
> I propose this two behavior : 
> - Disabling the usage of tab in theses fields

This would be the safest thing to do as long as the fields dont need the use of a tab character in them. @Regina, @Cor, @Heiko: Input please.

> - ctrl+tab in theses fields leave them, switching between tabs could be done
> with ctrl+tab when the user keyboard focus is on an other item.

Not sure you can overwrite the default handling of ctrl+tab, but we'd have to ask a dev if its possible. @Maxim, @Szymon, @Bubli: Input please.
Comment 9 Heiko Tietze 2017-05-04 19:16:26 UTC
(In reply to Yousuf Philips (jay) from comment #8)
> (In reply to Alex ARNAUD from comment #7)
> > I propose this two behavior : 
> > - Disabling the usage of tab in theses fields
> 
> This would be the safest thing to do as long as the fields dont need the use
> of a tab character in them. @Regina, @Cor, @Heiko: Input please.

The labels have accelerators so you get out of this input field with alt+D/T/F... in case of English. Disabling tabs makes it impossible to simulate columns, which might be interesting for envelopes. -> WONTFIX

Another observation in this dialog is at the Printer tab where the first selection with icons is not labeled. It is part of the tab sequence but without a focus frame so hardly to recognize.
Comment 10 Alex ARNAUD 2017-07-13 15:25:57 UTC
(In reply to Yousuf Philips (jay) from comment #8)
> (In reply to Alex ARNAUD from comment #7)
> > > So in other apps, when a user arrives at a multiline textbox that is to
> > > contain tab characters in it, how does navigation work there? I've checked
> > > some apps and some do not permit you to press tab in them (e.g.
> > > thunderbird's new contact dialog's other tab), while others do
> > > (qbittorrent's options dialog's bittorrent tab).
> > 
> > I propose this two behavior : 
> > - Disabling the usage of tab in theses fields
> 
> This would be the safest thing to do as long as the fields dont need the use
> of a tab character in them. @Regina, @Cor, @Heiko: Input please.
> 
> > - ctrl+tab in theses fields leave them, switching between tabs could be done
> > with ctrl+tab when the user keyboard focus is on an other item.
> 
> Not sure you can overwrite the default handling of ctrl+tab, but we'd have
> to ask a dev if its possible. @Maxim, @Szymon, @Bubli: Input please.

Any input ? It's a major issue for keyboard-only users as visual-impaired people.

Best regards.
Comment 11 Szymon Kłos 2017-07-13 15:52:58 UTC
(In reply to Yousuf Philips (jay) from comment #8)
> 
> > - ctrl+tab in theses fields leave them, switching between tabs could be done
> > with ctrl+tab when the user keyboard focus is on an other item.
> 
> Not sure you can overwrite the default handling of ctrl+tab, but we'd have
> to ask a dev if its possible. @Maxim, @Szymon, @Bubli: Input please.

I think it is possible using IsMod1() to check if ctrl is used and KEY_TAB code. It could be an easy hack :)

Useful links:
http://opengrok.libreoffice.org/xref/core/include/vcl/keycod.hxx#34
http://opengrok.libreoffice.org/xref/core/offapi/com/sun/star/awt/KeyModifier.idl#37

Example of using key codes:
http://opengrok.libreoffice.org/xref/core/svx/source/tbxctrls/itemwin.cxx#419

Envelope dialog:
http://opengrok.libreoffice.org/xref/core/sw/source/ui/envelp/envlop1.cxx#192
Comment 12 QA Administrators 2018-10-02 02:55:08 UTC Comment hidden (obsolete)
Comment 13 Patrick ZAJDA 2018-11-16 17:28:41 UTC
This bug is still present on LibreOffice 6.1.2.1. Tab is not really useful for these field so looks like a good solution to not allow writting tab in these fields, in this case we could be able to jump to the next field instead of reading all the dialog in reverse order using tab key.
Comment 14 Thorsten Behrens (CIB) 2019-02-23 00:19:21 UTC
Task might have become a tad harder now with welded controls on Linux. Also perhaps a clarified definition of what should be done might be needed (modify multiline text behaviour, or just the global tab travelling)?
Comment 15 Heiko Tietze 2019-02-23 08:36:46 UTC
(In reply to Thorsten Behrens (CIB) from comment #14)
> ...clarified definition of what should be done...

Alex & UX people, please elaborate the planned changes.
Comment 16 Alex ARNAUD 2019-02-25 09:51:27 UTC
(In reply to Heiko Tietze from comment #15)
> (In reply to Thorsten Behrens (CIB) from comment #14)
> > ...clarified definition of what should be done...
> 
> Alex & UX people, please elaborate the planned changes.

I propose to stay consistent to what Java Swing and Microsoft does, see there for the Microsoft way: https://docs.microsoft.com/fr-fr/dotnet/api/system.windows.forms.textboxbase.acceptstab?view=netframework-4.7.2
- Let tab behavior as it is 
- Fix shift tab because shift+tab does the same as tab
- Control + tab would be used to leave the multi-lines elements

Best regards,
Alex.
Comment 17 Heiko Tietze 2019-02-25 11:01:21 UTC
Just for clarification, we talk about File > Wizards > Letter, right?

The dialog has hotkeys (alt+B/F/P on the first step) and you can tab through active controls (though feedback of current focus is not correct for me). And shift-tab traverse the opposite way. What exactly is missing?
Comment 18 Alex ARNAUD 2019-02-25 13:41:40 UTC
(In reply to Heiko Tietze from comment #17)
> Just for clarification, we talk about File > Wizards > Letter, right?

No, we're talking about Envelope dialog inside the insert menu. See comment #1.

Best regards,
Alex.
Comment 19 Alex ARNAUD 2019-02-25 13:42:43 UTC
(In reply to Alex ARNAUD from comment #18)
> (In reply to Heiko Tietze from comment #17)
> > Just for clarification, we talk about File > Wizards > Letter, right?
> 
> No, we're talking about Envelope dialog inside the insert menu. See comment
> #1.

Oops, comment #1 is not the description. See my initial description.

Best regards,
Alex.
Comment 20 Heiko Tietze 2019-02-28 08:56:40 UTC
Okay, this dialog looks indeed weird. Let's make a proposal for redesign.
Comment 21 Samuel Thibault 2019-04-24 13:50:58 UTC
(In reply to Alex ARNAUD from comment #16)
> (In reply to Heiko Tietze from comment #15)
> > (In reply to Thorsten Behrens (CIB) from comment #14)
> > > ...clarified definition of what should be done...
> > 
> > Alex & UX people, please elaborate the planned changes.
> 
> I propose to stay consistent to what Java Swing and Microsoft does, see
> there for the Microsoft way:
> https://docs.microsoft.com/fr-fr/dotnet/api/system.windows.forms.textboxbase.
> acceptstab?view=netframework-4.7.2
> - Let tab behavior as it is 
> - Control + tab would be used to leave the multi-lines elements

That is actually what gtk3 does too. When the focus is inside a GtkTextView, tab inserts a tab, and control-tab switches to the next control. Even if control-tab usually switches tabs of the dialog.

(In reply to Heiko Tietze from comment #20)
> Okay, this dialog looks indeed weird. Let's make a proposal for redesign.

Well, a redesign will not change the issue: as long as there are e.g. buttons after the input control which eats tabs, people who can only use a keyboard can not escape from it the normal way to reach the buttons, they'd have to shift-tab to escape backward, and press shift-tab a lot of times only to get back to the buttons, and possibly pressing one time too much and get stuck *again* in the input control, and thus have to do shift-tabs again (and possibly again pressing once too much, etc.). That is really not a usable behavior, while making an exception for control-tab just here would just work, and be coherent with other UI toolkits.
Comment 22 Cor Nouws 2019-04-24 14:26:59 UTC
(In reply to Alex ARNAUD from comment #16)
> - Let tab behavior as it is 
> - Fix shift tab because shift+tab does the same as tab
> - Control + tab would be used to leave the multi-lines elements
Fine for me.

NB. I notice the TAB behavior is broken in more aspects in version Version: 6.3.0.0.alpha0+
Build ID: 89b1a00e08d8938714dd493fa27f08ba8d9b618d
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-04-21_15:52:39
Locale: nl-NL (nl_NL.UTF-8); UI-Language: en-US
Calc: threaded