The main takeaways of this investigation are:

• The accesskey behaviour for some native elements such as buttons and links is to activate them, instead of just focusing them, as we thought.
• The accesskey behaviour is the same on Chrome, Firefox and Edge (at least on Windows).
• The best way to solve these issues is to explicitly add an accesskey attribute to the components, instead of relying on passthru logic.

r43147: added the accesskey attribute to all input and action components that were missing it and made it an explicit attribute that appears in the TLD doc for those components that were relying on the passthru attribute functionality for accesskey

r53148: backported ICE-11479 and ICE-11473 to customer's patch branch

The components that now have full support for the accesskey attribute as well as having it declared in their documentation pages and having it tested are the following: ace:autoCompleteEntry, ace:checkboxButton, ace:combobox, ace:dataExporter, ace:dateTimeEntry, ace:dynamicResource, ace:fileEntry, ace:linkButton, ace:listExporter, ace:maskedEntry, ace:menuButton, ace:menuItem, ace:pushButton, ace:radioButton, ace:selectMenu, ace:simpleSelectOneMenu, ace:tableConfigPanel, ace:textAreaEntry, ace:textEntry, ace:themeSelect.

r53217, r53221: fixed accesskey attribute for ace:linkButton and ace:pushButton in 4.3 (committed to the trunk and the P02 tag)

The passthrough attribute functionality wasn't working for accesskey, so it had to be explicitly rendered.

Also tested all other components (in 4.3) that have the accesskey attribute and made sure it works on all of them.

As for ace:drawerPanel, it is not a candidate for accesskey, because the open and close handles are actually different elements so they are in conflict as the chosen access key.