r48509: added 'accesskey' attribute support to 20 ACE components

There are still 7 components left (datatable paginator, column, row editor, breadcrumb menu, fileentry, richtextentry, silderentry, tabpane). For these components, supporting accesskey requires a bit more effort, as in some cases the element in question is rendered dynamically from the javascript or might not be always accessible.

Support for accesskey varies from browser to browser. For example, on Chrome the support is actually very limited. The accesskey attribute is only working for elements that support it in HTML4, even though all elements are supposed to support it in HTML5, and the test page I've been using has the correct HTML5 declaration. I also made sure to make these elements focusable by adding tabindex="0", but this is not working on Chrome. Another issue is that for <a> elements, accesskey not always works. Sometimes it's necessary to first give focus to that <a> element in some other way before being able to use its access key. Sometimes, a different key combination is necessary for these elements (e.g. Alt+Shift+<key> instead of just Alt+<key>). On IE11, for example, everything is working as expected.

r48513: added 'accesskey' attribute support to ace:breadcrumbMenu, ace:column, ace:dataTable paginator, ace:rowEditor, ace:fileEntry, ace:richTextEntry, ace:sliderEntry, and ace:tabPane; also made all ace:tabSet tab headers focusable and navigable via the tab key

Testing notes:

• Note that the accesskey support was added to the ace:rowEditor component and not to the ace:cellEditor, as mentioned in the description. Those buttons are rendered by the ace:rowEditor component.
• When testing these components for accesskey, please read the TLD documentation on this attribute to understand how it's supposed to work.
• Again, Chrome doesn't support giving focus to certain elements, while IE and FF do.
• Likewise, on some browsers when focusing a link (<a>), the link will be followed or activated automatically, on others it will simply receive focus.
• On ace:fileEntry, in multiple mode, it's not possible to focus the input element, since it's hidden. So, you won't see an outline. The styling was enhanced to apply an on-hover styling to the Add button, to give a signal that this component has focus.

The following components have been found with the accesskey not working manually on Chrome:
accordionPane
audioPlayer
column
dataTable
dataTable paginator
maskedEntry
selectMenu
sliderEntry
tableConfigPanel
textEntry
themeSelect
tree
videoPlayer

That's a pretty big list. Art, are all these components unable to be supported in Chrome, or just some of them? We need to document these as Known Issues for ones we cannot fix in the TLDdoc for each component.

I went over the list above, and this is what I found:

These components actually work for me on Chrome. I tested them by adding accesskey="x" to their demo pages in the showcase application: accordionPane, column, maskedEntry, tableConfigPanel, textEntry, and themeSelect.

Please re-test, and if they still don't work, please explain how exactly you're testing them.

There's nothing we can do about these four components, because their tags are simply not focusable on Chrome: audioPlayer (<audio>), dataTable (<tbody>), tree (<span>), videoPlayer (<video>).

As for the paginator controls, selectMenu and sliderEntry, they should work, since they use the <a> element, but for some reason it's not working. I've tried various things with no success. The selectMenu actually works, but you have to focus it first by another means (e.g. tabbing). The only thing left to try for the other two components is to add an onkeydown listener on the document and force focus on these elements when pressing the right key combination for the accesskey on Chrome.

Retested accordionPane, column, maskedEntry, tableConfigPanel, textEntry, and themeSelect with Chrome 50.

accordionPane, column, maskedEntry, textEntry, themeSelect all work when using Alt + "letter". Sometimes you have to click on the page first before using the accesskey.
tableConfigPanel does not work consistently for me. Using Alt + "letter" does not regularly open the panel on first try. Once the panel has been opened using the accesskey will open and close it consistently.
Test case /views/configPanelTest.jsf
http://dev.icesoft.com/svn/repo/qa/trunk/Regression-Icefaces4/Sparkle/Nightly/dataTable

r48640: fixes for using accesskey on Chrome for ace:selectMenu, ace:sliderEntry and the paginator controls in ace:dataTable

In Chrome, triggering the accesskey on <a> elements actually simulates a click rather than just giving them focus. So, I managed to fix this by adding onclick="this.focus();". I did the same for the tableconfig panel button and also included a fix to avoid triggering the column header where the button is when triggering the accesskey.

The tests pass as long as the target components receive focus when triggering the accesskey or control is transferred to them. The panels and lists don't have to necessarily pop up. This behaviour is seen only on FF for some reason, but the purpose of accesskey is just limited to giving focus. The panels and lists can be opened by pressing the space key when the component has focus.

r48665: removed onclick="this.focus()" on inactive page links, since it's actually not necessary for accesskey to work properly on Chrome and was causing the regression described in ICE-11010

The changes for ace:richTextEntry appear to cause a regression on showcase > RichTextEntry: a button is rendered underneath the richTextEntry component (all servers/ all browsers), screen shot attached.

r48674: modification to always render the styling that makes the accesskey proxy button invisible and unusable for anything else but to transfer focus to the CKEditor

EE4-trunk r45005/48674/ IE8/11, FF41, Chrome50, MS Edge: verified showcase > richTextEntry, the issue mentioned above is resolved.

On MS Edge/Windows10 test PC, a browser console error was seen when saving text in the richTextEntry - see ICE-10988.

The issue above seems unrelated to these changes. Do you know what was the last revision where this wasn't an issue?

ICEfaces 4 trunk r 48675. Also tested with Jenkins build 1857 where the initial commits were made for the accesskeys.
gMap > accesskey > all browsers - map component does not appear to gain focus when using the accesskey in any browser. When viewing the page markup there is no accesskey attribute associated with the gMap. This is only the case for the gMap component. Not an issue with the gMap autoComplete.

r48694: fix to make accesskey work on Chrome for ace:gMap; moved attribute to parent node, which doesn't get replaced by the Google Maps code

Note that for ace:gMap, having focus doesn't imply that the map can be controlled that way.

Verified ICEfaces EE-4.1.0 r48694. Tomcat 8, IE Edge, 11, 10, 9, 8, Chrome 50, FF 43.