We are migrating CKEditor issue tracking to GitHub. Please, use GitHub to report any new issues.

The former tracking system (this website) will still be available in the read-only mode. All issues reported in the past will still be available publicly and can be referenced.

Important: we decided not to transfer all the tickets to GitHub, as many of them are not reproducible anymore or simply no longer requested by the community. If the issue you are interested in, can be still reproduced in the latest version of CKEditor, feel free to report it again on GitHub. At the same time please note that issues reported on this website are still taken into consideration when picking up candidates for next milestones.

Although the proposed solution is based on ARIA's best practices, I'm not sure if it's better thanks to that…

In our current solution if user opens some combobox (e.g. "Styles"), then the screenreader announces the name of the opened combobox and the selected element. In the proposed solution this information is ommited and the screenreader announces only the value of the first item in the opened combobox. Tested with VoiceOver.

The solution is working pretty well for context menus, but for richer UI's elements it doesn't convince me.

From the other things:

it will be nice to have some unit test which checks if the first element is really focused.

Although the proposed solution is based on ARIA's best practices, I'm not sure if it's better thanks to that…

In our current solution if user opens some combobox (e.g. "Styles"), then the screenreader announces the name of the opened combobox and the selected element. In the proposed solution this information is ommited and the screenreader announces only the value of the first item in the opened combobox. Tested with VoiceOver.

Yes, the name of the combobox is announced in JAWS, but the selected element is not announced. I'm not sure, but it's probably connected with the fact how the combobox currently works: the selection is strictly connected with focus, so moving focus inside the list means also moving selection.

Inside guidelines dedicated to listbox we could read that moving selection with focus is optional and this case is probably the best example why.

Yes, the name of the combobox is announced in JAWS, but the selected element is not announced. I'm not sure, but it's probably connected with the fact how the combobox currently works: the selection is strictly connected with focus, so moving focus inside the list means also moving selection.

Ok, I see the problem now. I think it's more connected with the crudeness of my implementation.