Closed Bug 393608 Opened 13 years ago Closed 13 years ago

[Proto] Event dialog and Task dialog have no accesskeys

Categories

(Calendar :: General, defect)

defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: ssitter, Assigned: ssitter)

References

Details

(Keywords: access, late-l10n, Whiteboard: [l10n impact])

Attachments

(1 file, 2 obsolete files)

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.7pre) Gecko/20070824 Calendar/0.7pre

The Event dialog and Task dialog have no accesskeys set. At least the main menu items and the dialog items should be accessible via accesskeys in my opinion.
The difficulty with getting all accesskeys working properly is that each accesskey in the window must be unique. I tried to follow the accesskeys used in the old dialog and the recommendations from <http://developer.mozilla.org/en/docs/XUL_Accesskey_FAQ_and_Policies> and came up with this working solution:

Main menu items
    F   File
    E   Edit
    V   View
    O   Options
    H   Help

Dialog items
    T   Title
    L   Location
    y   Category
    C   Calendar
    A   All Day
    B   Begin (in Event dialog)
    g   Begin (in Task dialog)
    n   End
    u   Due Date
    S   Status
    R   Repeat
    m   Reminder
    D   Description

I had to rename the "Start:" label to "Begin:" to get the possibility to add a unique accesskey. Requesting ui-review for the renaming and the accesskeys.

During testing I noticed that the accesskeys Alt+B (Begin) and Alt+n (End) doesn't seem to work. But this seems to be a issue with the datetimepicker control and not the accesskey. If you press the accesskey followed by the Tab key the date field in the correct datetimepicker is selected. But this is something for a followup bug.
Attachment #278122 - Flags: ui-review?(christian.jansen)
Attachment #278122 - Flags: review?(philipp)
I personally really don't like the idea of renaming 'start' to 'begin'. the latter just sounds weird and out of place.
Comment on attachment 278122 [details] [diff] [review]
rev0 - add accesskeys to main menu and dialog items

I agree, I think we should stick with start, and I also think this should preceed recommendations from the FAQ. We need accesskeys for the menu items too. Also, some elements are missing in the patch (Document, Change Document...). If we change "Document" (back?) to "Link", the following could be used, also ignoring parts of the FAQ. If Link is not good, then maybe URL (accesskey=L). I'm really no expert on accessibility, also the only accesskeys I personally use are tab and the menu accesskeys. Maybe others have an opinion, or Christian has a decision?


Main menu items
    F   File
    E   Edit
    V   View
    O   Options
    H   Help

Dialog items
    T   Title
    L   Location
    y   Category
    C   Calendar
    D   All Day
    S   Start
    n   End
    u   Due Date
    a   Status
    R   Repeat
    m   Reminder
    p   Description
    g   Change (Link)
    k   Link
    
r- for now to at least add the menuitem accesskeys. Please use the thunderbird message compose window as a template. Note also, that the correct way to select a menuitem is not |alt+f,alt+u| but |alt+f,u|. That baffeled me for a while.
Attachment #278122 - Flags: review?(philipp) → review-
New proposal. Patch adds accesskeys to all menu items and almost all dialog items. Patch renames "Document:" to "Link:" as proposed in Comment #3 to reflect the changes from Bug 360533/Bug 393104.
Attachment #278122 - Attachment is obsolete: true
Attachment #279246 - Flags: ui-review?(christian.jansen)
Attachment #279246 - Flags: review?(philipp)
Attachment #278122 - Flags: ui-review?(christian.jansen)
Christian, Philipp, could you please try to review this patch this Monday (Sep 03) since that is the last day before our string freeze. Thanks!
Main menu items
    F   File
    E   Edit
    V   View
    O   Options
    H   Help

-> These are OK.
	
Dialog items
	  T   Title
	  L   Location
	  y   Category
	  C   Calendar
  New:    A   Attendees  -> "k" Selects Link, "Return" Executes link
	  D   All Day
          S   Start
	  n   End				
	  u   Due Date
	  a   Status	
	  R   Repeat
	  m   Reminder		
	  p   Description
	  g   Change...	 -> "C" better readability 
          k   Link       -> "k" Selects Link, "Return" Executes link

r=Christian with these changes.
(In reply to comment #6)
>   New:    A   Attendees  -> "k" Selects Link, "Return" Executes link
>           g   Change...  -> "C" better readability 
>           k   Link       -> "k" Selects Link, "Return" Executes link

Unfortunately I can't apply your proposals because A, C and K are already used for different items (A-Status, C-Calendar, K - Link). 
Just selecting the link is not possible as far as I know. The use of the accesskeys automatically triggers the corresponding action (e.g. opening the link in the browser).
(In reply to comment #7)
> (In reply to comment #6)
> >   New:    A   Attendees  -> "k" Selects Link, "Return" Executes link
> >           g   Change...  -> "C" better readability 
> >           k   Link       -> "k" Selects Link, "Return" Executes link
> 
> Unfortunately I can't apply your proposals because A, C and K are already used
> for different items (A-Status, C-Calendar, K - Link).
> Just selecting the link is not possible as far as I know. The use of the
> accesskeys automatically triggers the corresponding action (e.g. opening the
> link in the browser).

Next time I read the rules fist. I overlooked that accesskeys should not assigned twice. Sorry for the confusion. This one should work....


Dialog items
          T   Title
          L   Location
          y   Category
          C   Calendar
  New:    A   Attendees
          v   All Day Event -> was: D
          S   Start
          n   End                               
          D   Due Date      -> was: u
          u   Status        -> was: a
          R   Repeat
          m   Reminder          
          p   Description
          g   Change...
          k   Link
Comment on attachment 279246 [details] [diff] [review]
rev1 - add accesskeys to menus and dialog items

r=christian
Attachment #279246 - Flags: review+
(In reply to comment #8)
>           v   All Day Event -> was: D

Finding the correct accesskeys is hard: V is already used for menu View. 

We could change the accesskey for all occurrences of 'Invite Attendees' in the menus from 'A' to 'I' and also use 'I' for the dialog item 'Attendees'. But this also means that menu item 'Importance' needs to be changed from 'I' to e.g. 'm'.

 This should work with the proposal from attachment 279246 [details] [diff] [review] and would be displayed as 'Attendees (I)' in the dialog. Currently the start date for tasks is also displayed as 'Start (B)' because the accesskey 'S' is already used for the start date for events.
This patch incorporates the proposal from Comment #10. I think we should take this working patch due to the en-US string freeze today for now. 

Later we can change the accesskeys to a better working solution. This change would not break the en-US string freeze in my opinion because it doesn't add or remove entities and the en-US accesskey entity value itself is not relevant for other locales.
Attachment #279246 - Attachment is obsolete: true
Attachment #279459 - Flags: ui-review?(christian.jansen)
Attachment #279459 - Flags: review?(philipp)
Attachment #279246 - Flags: ui-review?(christian.jansen)
Attachment #279246 - Flags: review?(philipp)
Whiteboard: [l10n impact]
Comment on attachment 279459 [details] [diff] [review]
rev2 - add accesskeys to menus and dialog items

Stealing review request as Philipp is on vacation. I'm fine with taking this version now and change it after 0.7 is out of the door. r=mickey.
Attachment #279459 - Flags: review?(philipp) → review+
Keywords: checkin-needed
Comment on attachment 279459 [details] [diff] [review]
rev2 - add accesskeys to menus and dialog items

Moving Christian's ui-reiview forward. Can someone please check this in as our string freeze was two days ago. 

Localizers need to be notified on this!
Attachment #279459 - Flags: ui-review?(christian.jansen) → ui-review+
Notifying localizers that this will get in after the string freeze.
Keywords: late-l10n
patch checked in on trunk and MOZILLA_1_8_BRANCH

-> FIXED
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → 0.7
I can't make Start and End accesskeys working
(In reply to comment #16)
See last paragraph in Comment #1.
Other accesskeys works very good in lightning 20070906---> verified
Status: RESOLVED → VERIFIED
Verified on linux with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.7pre) Gecko/20070906 Calendar/0.7pre
Duplicate of this bug: 362924
You need to log in before you can comment on or make changes to this bug.