Opened 5 years ago

Closed 5 years ago

#11075 closed Bug (fixed)

AVT: With focus on button menu & no drop-down menu displayed, pressing Down Arrow should open drop-down menu and move focus in to menu and onto the first menu item

Reported by: Satya Minnekanti Owned by: Marek Lewandowski
Priority: Normal Milestone: CKEditor 4.3.1
Component: General Version: 4.0
Keywords: IBM Cc: Damian, Teresa Monahan, Irina


To reproduce the defect:

  1. Open any CK Sample, keep cursor in editor body.
  1. Press Alt + F10 to navigate in to toolbar.
  1. Navigate to Spell Check As You Type button menu.
  1. Press Down Arrow key.

Expected Result: Pressing Down Arrow will open drop-down menu and move focus into the menu and onto the first menu item. Actual Result: Focus moves to next button in the toolbar. This is a violation of Accessibility Checkpoint 2.1a & 4.1b

Look at the following link for wai-aria authoring practices for button menu & keyboard interactions for button menu

Change History (8)

comment:1 Changed 5 years ago by Jakub Ś

Status: newconfirmed
Version: 4.0

Yes you are right aria says that down arrow just like space or enter should open menu and focus first element in menu.

It has never worked that way from the very beginning but I'm setting start version as 4.0 since it is going to be in 4.x.

comment:2 Changed 5 years ago by Marek Lewandowski

Owner: set to Marek Lewandowski
Status: confirmedassigned

comment:3 Changed 5 years ago by Olek Nowodziński

editor.once( 'panelShow', function( evt ) { 40 );
} );

before item.execute() in itemKeystroke function (toolbar plugin) should do the job.

Edit: A better place for the fix could be the button plugin. The trick would correspond with the similar code in richcombo if extended those existing lines:

var keydownFn = function( ev ) {
	if ( instance.onkey ) {
		ev = new CKEDITOR.dom.event( ev );
		var keystroke = ev.getKeystroke();

		if ( keystroke == 40 && instance.button.hasArrow ) {
			editor.once( 'panelShow', function( evt ) { 40 );
			} );

			return clickFn, CKEDITOR.document.getById( id ) );
			return ( instance.onkey( instance, ev.getKeystroke() ) !== false );

This approach seems semantically correct because custom keystroke handling should belong to the button, not to the toolbar.

Last edited 5 years ago by Olek Nowodziński (previous) (diff)

comment:4 Changed 5 years ago by Marek Lewandowski

Status: assignedreview

Thanks a lot for help Olek. I ended up with 2 changes, one, exclusively for richcombo and second for button which has 'hasArrow' property set to true.

Richcombo required direct modification where you suggested.
As for typical buttons i added code to that switch in toolbar plugin, since whole logic is specified it already there. I think that adding it to another place would be very tricky for future maintainer.

Code pushed to t/11075 dev.

I skipped tests since interface is not convenient, so it would take lot of time to prepare it.

comment:5 Changed 5 years ago by Frederico Caldeira Knabben

Status: reviewreview_failed

I understand that the code is tricky as the API is limited. So the proposed solution is good.

Still an additional proposal is being included, to open the panel on ARROW-UP. This behavior is not described in the W3C recommendations so I think we should simply stick to that and avoid it.

comment:6 Changed 5 years ago by Marek Lewandowski

Status: review_failedreview

Ok so up arrow behavior is restored in t/11075.

comment:7 Changed 5 years ago by Frederico Caldeira Knabben

Milestone: CKEditor 4.3.1
Status: reviewreview_passed

comment:8 Changed 5 years ago by Marek Lewandowski

Resolution: fixed
Status: review_passedclosed

Masterized with git:430ada97f to dev.

Note: See TracTickets for help on using tickets.
© 2003 – 2019 CKSource – Frederico Knabben. All rights reserved. | Terms of use | Privacy policy