<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Envelope dialog: Make dialog more a11y friendly" href="https://bugs.documentfoundation.org/show_bug.cgi?id=107625#c21">Comment # 21</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Envelope dialog: Make dialog more a11y friendly" href="https://bugs.documentfoundation.org/show_bug.cgi?id=107625">bug 107625</a> from <a class="email" href="mailto:samuel.thibault@ens-lyon.org" title="Samuel Thibault <samuel.thibault@ens-lyon.org>"> Samuel Thibault</a> <pre>(In reply to Alex ARNAUD from <a href="show_bug.cgi?id=107625#c16">comment #16</a>) > (In reply to Heiko Tietze from <a href="show_bug.cgi?id=107625#c15">comment #15</a>) > > (In reply to Thorsten Behrens (CIB) from <a href="show_bug.cgi?id=107625#c14">comment #14</a>) > > > ...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: > <a href="https://docs.microsoft.com/fr-fr/dotnet/api/system.windows.forms.textboxbase">https://docs.microsoft.com/fr-fr/dotnet/api/system.windows.forms.textboxbase</a>. > 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 <a href="show_bug.cgi?id=107625#c20">comment #20</a>) > 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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>