3 Replies Latest reply on Feb 8, 2013 12:05 PM by Anthony Rayner-Oracle

    Optional Label w Help - label template

      Hi All,

      I am working on 508 stuff for sequence navigation with tab order. We have a input form on one place where the labels have help text. If I navigate the form using tab key, input fields get the focus first and labels at last. I removed the tabindex="999" from the template to get the right order. Labels are getting focus before input fields, but if I click on label to see the help, help popup appears but can't get focus using IE. And if I try to go to next field after opening the help popup, it throws me out of the form. Please let me know if there is a way to handle this.

        • 1. Re: Optional Label w Help - label template
          Anthony Rayner-Oracle

          Thanks for your question. Firstly, can you provide the following information:
          - APEX version
          - IE version
          - Theme #

          So I think you're fix for the tab order issue is correct. Generally speaking, positive tabindex definitions almost always have a negative effect on usability for keyboard-only users. They have been present in theme label templates for a long time and must have been added initially as a way for users to move between form fields quickly. However, and as you have realised, this disrupts a keyboard-only user who wishes to view item help text. This can cause either a) If the form field has focus when the page loads, they have to TAB many times until they reach the help, or b) Form field focus is not set on page load, which can cause page focus to go directly to the label (because browsers treat elements with a positive tabindex as higher priority in the tab order than elements with no tabindex), and then the user has to press TAB many times to get to the form field. It's not good. I have filed bug #16183368 to remove this from all our modern themes, and we also had existing bug #9474840 which deals with the same issue in our internal applications that comprise APEX.

          So moving on to the help text dialog issue. Firstly setting focus to the dialog. I am unable to reproduce focus not being set to the dialog in IE. I tab to the label, hit ENTER, dialog opens, then I can either hit ESC key, or TAB once to go to the 'x' close icon and hit ENTER, to close the dialog. I tested in IE9 and works as expected for me. Can you provide a test case on apex.oracle.com where I could try there?

          Regarding closing the dialog, this is a problem with the version of the underlying jQuery UI dialog widget, where focus is not set back to the calling element when the dialog closes. We failed to workaround this in the default behaviour, (I believe in the most recent release of jQuery UI they have added this now by default, which we hope to pick up in our next release). Until then, I can see 2 options:
          1) Although a little counter-intuitive, you could suggest for keyboard-only users to use 'Screen Reader Mode'. In this mode, the old style page popup loads with the help text. This is fine for keyboard-only users too and focus is still in the same place when the popup closes.
          2) Rework the popup JS to also handle setting focus back to right place on close. I can suggest the code for you, but I need to know your version first, before I can do that.


          Edited by: Anthony Rayner on Jan 17, 2013 11:37 AM
          • 2. Re: Optional Label w Help - label template
            Hi Anthony,

            Here is what you asked:

            1. Apex: 4.0.2
            2. IE : 7
            3. 16 (Dark Blue). P.S: I can't change the theme as this is our default theme for all applications.

            • 3. Re: Optional Label w Help - label template
              Anthony Rayner-Oracle
              Hi user-Rachna,

              Thanks for the information. I was able to reproduce your issue, using APEX 4.0.2 / IE>=7 / Theme 16. This issue does not reproduce with APEX 4.2.1 at all. I would strongly encourage you to try and upgrade to 4.2.1 if you can? Aside from the obvious reasons, a lot of work goes into improving accessibility in each release, including countless bug fixes, which would definitely be of benefit to you in trying to meet 508.

              Upgrade aside, would you consider using 'Screen Reader Mode' as a fallback for your keyboard-only users? You don't have to call it 'Screen Reader Mode', it could be called 'Keyboard / Screen Reader Mode' or similar? I think given your version as well, that could be easier than going down the custom JS route.