Hi Lucas,

I think a number of folks would find this useful.

Another variant, if there is time & interest, is to highlight those 
elements that have no mnemonic and/or are otherwise not reachable via 
keyboard traversal.  This use would be more for developers/QA folks, to 
help highlight where keyboard shortcuts are needed but don't exist.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

> Hi folks,
>
> I'm exposing here a GSoC project idea not listed in the 2007 Ideas
> Pool and I would appreciate any comments/suggestion from you,
> GNOME Accessibility team, especially concerning the idea relevance to
> GNOME project.
>
>
> Here is the idea draft I sent to gtk+dev and usability lists.
> Thank you in advance for taking the time to read it.
>
> The idea was motivated by my experience as user/developer and by the
> following GNOME HIG quote:
> "A well-designed keyboard user interface plays a key role when you are
> designing applications."
>
> Here we go..
>
> IDEA:
>         Improve the visual indication of keyboard shortcuts in UI.
>
> SHORTCUTS IN GTK:
>    The shortcuts support in GTK+ is powerful and very well designed,
> although visual indications of available shortcuts are provided just
> by Labels and AccelLables. It allows software developers to design a
> very nice keyboard support to their applications and most of the users
> I know understand well access keys indicated on those Labels and
> AccelLabels.
>
> POSSIBLE IMPROVEMENTS:
>    GTK+ might allow developers to expose available mnemonics near
> to it's widgets even when there is no (Accel)Label related to it, e.g.
> a Canvas area. When user holds the first key of an accelerator key
> combination, e.g. CONTROL or ALT, then the available shortcuts with
> that key might pops-up near to it's widgets.
>    It will allow users to easily identify and jump fast across
> application UI areas without having to press several TABs or
> SHIFT+TABs to get there (Have you ever wondered "where is the focus
> now?").
>    This approach should work very well even on 'keyboard centric'
> applications like Text Editors. On this applications, users can't
> navigate properly using TABs.
>    We might go even further allowing a second level of shortcuts to
> widget's children. Just to make it clear, the user could press ALT+T
> to activate the 'Toolbar' and then all active ToolItems might show
> it's mnemonic so user could press one and get it activated.
>
>    There are some mock-ups to illustrate this idea applied to Nautilus
> [1], Gedit [2] and GtkFileChooser [3].
>
> BENEFITS:
>   * "Novice and advanced users alike will be able accomplish tasks
> quickly and easily" [GNOME HIG]
>  * Helping users to identify available mnemonics in order to navigate
> easily across the user interface.
>  * Improving the applications accessibility.
>  * Software developers could improve it's applications keyboard
> support to fits even better into GNOME HIG.
>
> I'm looking forward to receiving your feedback.
> Best regards,
> Lucas
>
> [1] Nautilus: 
> http://picasaweb.google.com/lmveloso/GnomeSoC2007Idea/photo#5040744879812560818
> [2] Gedit: 
> http://picasaweb.google.com/lmveloso/GnomeSoC2007Idea/photo#5040744879812560834
> [3] GtkFileChooser:
> http://picasaweb.google.com/lmveloso/GnomeSoC2007Idea/photo#5040744879812560850
>
>
> 2007/3/11, Steve Frécinaux <[EMAIL PROTECTED]>:
>   
>>> IDEA:
>>>       Improve the visual indication of keyboard shortcuts in UI.
>>>       
>> The idea looks pretty cool indeed, and reminds me what konqueror does
>> for webpages (it adds "random" shortcuts to the fist hyperlinks of a
>> page)
>>
>> What's harder is to play nice with the shorcuts that are already
>> defined, like mnemonics and regular shortcuts (Shouldn't ctrl+n appear
>> directly near the "new" icon from the toolbar ?).
>>     
>
> Really nice you have pointed it out.
>
> Yes, it should. In fact, already defined shortcuts should work without
> any (or with minimal) code modifications. So, when users holds
> Control key, all those already defined shortcuts have to pops-up. This
> must be the project primary goal.
>
> The second goal is about allowing a complementary keyboard approach:
> software developers might be able to design a menu-like shortcuts to
> some desired UI components (as shown by those mock-ups). By
> 'menu-like' here I mean keyboard sequences as ALT+F Q, ALT+F P, ALT+E
> X. Toolbars could be accessed in both ways if the software developer
> add this complementary shortcut approach.
>
>   
>> Good luck in completing the spec :-)
>>     
>
> Thank you!
>
> -------
> This email recommends Free and Open Source Software (R)
> _______________________________________________
> Gnome-accessibility-devel mailing list
> [email protected]
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
>   

_______________________________________________
Gnome-accessibility-devel mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel

Reply via email to