HTML5 Viewer v2.4 -- Keyboard (tab) navigation issue

Permanently deleted user

13. Mai 2015 23:43

 

Hi:

We are implementing a disclaimer view upon site/map load that sits in the modal region.  The intent is to have focus on the disclaimer upon first time tab and then to proceed through the disclaimer with further tabs.  At the moment the first time tab key invokes an outline of the map region covered by the modal window.  Further tab key requests go nowhere.  Tried various simple javascript/query/getelementbyid/focus() kinds of snippets as well some tabindexing but same result.  Tried toggling the AccessibilityModule's automaticElementFocusing property but also the same result.  The required tab key navigation did work in v2.3.3.  

Suggestions please.

Thanks,

Ralph

0

• 

  Permanently deleted user

  14. Mai 2015 05:49

  Hi Ralph,

  Have you also tried setting "keyboardFocusIndicatorEnabled" in the Accessibility Module to false? Also, it may be worth a try to disable the "expandedMapKeyboardAccessibility." If neither of these work, could you try removing the Accessibility module entirely and let me know if the behavior persists?

   

  Thanks,

  Kyle

  0
• 

  Permanently deleted user

  15. Mai 2015 22:39

  Many thanks for your suggestions Kyle.  Still having issues though.  Wondering how the Print tool works?  It shows the Print form in the modal region with focus on the first drop down control right away.

  0
• 

  Permanently deleted user

  21. Mai 2015 23:25

  Hi Ralph,

  For WCAG accessibility purposes we restrict tab focusing to the active modal when a modal is open. Unforturnately I've found a bug that causes this to happen independently of settings applied to the accessibility module. 

  GVH 2.4.1 will make it so that when the accessibility module's "automaticElementFocusing" is disabled the modal behavior will be as it was before.

  In the meantime, after reviewing your initial issue I have a suggestion. Have you tried wrapping the element that you wish to focus in a <input>, <button>, or <a> element? These are the elements that are sought out for focusing when the modal is active.

  Also, ensure that any custom modals have a parent class name "ModalViewContainerView" in their tree.

  Thanks,

  Kyle

  0
• 

  Permanently deleted user

  27. Mai 2015 17:33

  Thanks again for your suggestions Kyle. 

  We managed to have the user focus on first tab and subsequent tab strokes in the disclaimer using the tabindex attribute.  Basically setting everything to tabindex=1.  Did try <a> but resorted to <div> with tabindex to navigate.  Seems to be some inconsistencies though in how focus and modal behaviour occurs depending on the site loading.  Looking forward to v2.4.1.  Also, will look at the "ModalViewContainerView" parent to better handle this custom modal modules and possibly others.

  Again thanks,

  Ralph

  0

Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.