role="application" should not be used for dialogs

[Teresa Monahan]

The fix for ticket #9841 applies role="application" to dialogs. This was added to "enable" JAWS forms/application mode. However this is not the purpose of the application role as it is intended to be a landmark region encompassing a whole application.

Dialogs have the "dialog" WAI-ARIA container role which implicitly supports keyboard interaction once that container or an element within it has focus. Therefore the application role should not be required to explicitly change to forms mode.

In 4.x, the dialog div container (with role="dialog") has "visibility: hidden" set as a style from the class .cke. This essentially makes the dialog semantics hidden. In 3.6, the dialog instead has "visibility:inherit" on the same div. Setting "visibility:inherit" on the dialog div in 4.x should address the original issue reported in ticket #9841 rather than using role="application".

[Jakub Ś]

@tmonahan I have reverted change for dialog introduced in #9841 and changed visibility value to inherit. It did work.
I don't know if it causes any problems other problems but it seems to fix this particular issue.

[Teresa Monahan]

This is a high priority ticket for us - can you please target it for the upcoming 4.1.2 release?

[Frederico Caldeira Knabben]

I've just pushed ​git:030ede2 with the proposed fix.

Still I have the impression that the issue happens even after fix, randomly and rarely.

I have also noticed that this happens when using ENTER to activate the toolbar button, but it never happened when using SPACE, which is btw the key that JAWS announce as the one to be used.

Anyway, the current status is now "correct". If any issue will be found, it should be investigated by FS, as CKEditor is now doing what is theoretically right.