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

[Satya Minnekanti]

To reproduce the defect:

1. Open any CK Sample, keep cursor in editor body.

2. Press Alt + F10 to navigate in to toolbar.

3. Navigate to Spell Check As You Type button menu.

4. 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 ​http://www.w3.org/TR/wai-aria-practices/#menubutton

[Jakub Ś]

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.

[Olek Nowodziński]

editor.once( 'panelShow', function( evt ) {
	evt.data._.panel._.currentBlock.onKeyDown( 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 = CKEDITOR.tools.addFunction( 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 ) {
				evt.data._.panel._.currentBlock.onKeyDown( 40 );
			} );

			return CKEDITOR.tools.callFunction( clickFn, CKEDITOR.document.getById( id ) );
		}
		else
			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.

[Marek Lewandowski]

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.

[Frederico Caldeira Knabben]

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.

[Marek Lewandowski]

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

[Marek Lewandowski]

Masterized with ​git:430ada97f to dev.