MyFaces Trinidad
  1. MyFaces Trinidad
  2. TRINIDAD-888

Add support for tabindex to focusable components

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 1.0.5-core, 1.2.5-core
    • Fix Version/s: None
    • Component/s: Components
    • Labels:
      None

      Description

      Add support for tabindex to focusable components (initial list, maybe changed during implementation):
      breadCrumbs
      chooseColor
      chooseDate
      commandButton
      commandLink
      commandNavigationItem
      goButton
      goLink
      inputColor
      inputDate
      inputFile
      inputListOfValues
      inputNumberSpinbox
      inputText
      navigationPane
      navigationTree
      panelAccordion
      panelPopup (not with hover?)
      panelRadio/showDetailItem
      panelTabbed
      processChoiceBar
      resetButton
      selectBooleanCheckbox
      selectBooleanRadio
      selectManyCheckbox
      selectManyListbox
      selectManyShuttle
      selectRangeChoiceBar
      showDetail
      singleStepButtonBar
      table
      train
      tree
      treeTable

      According to the w3c:
      http://www.w3.org/TR/html4/interact/forms.html#adef-tabindex

        Issue Links

          Activity

          Andrew Robinson created issue -
          Hide
          Sandeep Manepalli Gururaj added a comment -

          I guess the code for including tabindex is already in place, however the attribute for the same is missing from the tags.

          Show
          Sandeep Manepalli Gururaj added a comment - I guess the code for including tabindex is already in place, however the attribute for the same is missing from the tags.
          Andrew Robinson made changes -
          Field Original Value New Value
          Status Open [ 1 ] In Progress [ 3 ]
          Andrew Robinson made changes -
          Status In Progress [ 3 ] Open [ 1 ]
          Hide
          Andrew Robinson added a comment -

          This has been placed on hold until tab index architectural ideas are discussed.

          Show
          Andrew Robinson added a comment - This has been placed on hold until tab index architectural ideas are discussed.
          Matthias Weßendorf made changes -
          Link This issue is duplicated by TRINIDAD-100 [ TRINIDAD-100 ]
          Hide
          Matthias Weßendorf added a comment -

          There is a wiki page that covers some solutions, ideas around this "issue"

          http://wiki.apache.org/myfaces/CustomTabOrder

          Show
          Matthias Weßendorf added a comment - There is a wiki page that covers some solutions, ideas around this "issue" http://wiki.apache.org/myfaces/CustomTabOrder
          Hide
          Marco Grimm added a comment - - edited

          May this gain a higher priority than "Minor"?
          JSF, RichFaces and MyFaces Tomahawk do implement this feature and it is helpful especially to set the tabindex="-1".
          At the moment we help ourself with a JS a the end of the page, which sets the tabindex="-1" for given components, but that is not a nice solution.

          Show
          Marco Grimm added a comment - - edited May this gain a higher priority than "Minor"? JSF, RichFaces and MyFaces Tomahawk do implement this feature and it is helpful especially to set the tabindex="-1". At the moment we help ourself with a JS a the end of the page, which sets the tabindex="-1" for given components, but that is not a nice solution.
          Hide
          Andrew Robinson added a comment -

          There was no consensus on how this could be implemented. Any kind of declarative tabindex was met with strong developer resistance. I have given up in trying to find a solution for this at the moment.

          Show
          Andrew Robinson added a comment - There was no consensus on how this could be implemented. Any kind of declarative tabindex was met with strong developer resistance. I have given up in trying to find a solution for this at the moment.
          Hide
          Carsten Pieper added a comment -

          We (especially our customers/users) would very much like to see this feature implemented. It would be great, if the topic could be "revived"....

          Show
          Carsten Pieper added a comment - We (especially our customers/users) would very much like to see this feature implemented. It would be great, if the topic could be "revived"....
          Hide
          Blake Sullivan added a comment -

          The way to get the priority raised is to provide specific use cases that you would like to see addressed

          Show
          Blake Sullivan added a comment - The way to get the priority raised is to provide specific use cases that you would like to see addressed
          Hide
          Carsten Pieper added a comment -

          Specific use cases? Hm, I'm not quite sure, what you mean...

          If this might have been the question: We (developers) love using the tr:panelFormLayout. If you tab through its content, the order is "columns first". In almost all cases, our customers would prefer a "row first" tabbing strategy...

          Or have you been asking about the preferred tabIndex strategy? Well, wouldn't it make sense to follow the W3C approach (http://www.w3.org/TR/html401/interact/forms.html#adef-tabindex)?

          Show
          Carsten Pieper added a comment - Specific use cases? Hm, I'm not quite sure, what you mean... If this might have been the question: We (developers) love using the tr:panelFormLayout. If you tab through its content, the order is "columns first". In almost all cases, our customers would prefer a "row first" tabbing strategy... Or have you been asking about the preferred tabIndex strategy? Well, wouldn't it make sense to follow the W3C approach ( http://www.w3.org/TR/html401/interact/forms.html#adef-tabindex)?
          Hide
          Matthias Weßendorf added a comment -

          Blake was talking about a use-case: how do want to use the feature, if it would be present

          tabIndex has also some issues on more complex components...

          Show
          Matthias Weßendorf added a comment - Blake was talking about a use-case: how do want to use the feature, if it would be present tabIndex has also some issues on more complex components...
          Hide
          Marco Hallo added a comment -

          What are the issues on more complex components and what components do you mean? We've got an tabindex fix from Irian for trinidad components and I didn't noticed any problem. We use a lot of simple components like input fields, drop down boxes. But also more complex things like tr:table or radio buttons. Everything works like expected. Even with ppr we don't saw a problem.

          We don't want to patch every release of the components so it would be great if the fix could be patch the official sources.

          Show
          Marco Hallo added a comment - What are the issues on more complex components and what components do you mean? We've got an tabindex fix from Irian for trinidad components and I didn't noticed any problem. We use a lot of simple components like input fields, drop down boxes. But also more complex things like tr:table or radio buttons. Everything works like expected. Even with ppr we don't saw a problem. We don't want to patch every release of the components so it would be great if the fix could be patch the official sources.
          Hide
          Matthias Weßendorf added a comment -

          complex == composite comps with more than one tab-stop (inputDate) or table
          some thoughts are here:
          -http://mail-archives.apache.org/mod_mbox/incubator-adffaces-user/200608.mbox/%3C6dac79b90608031518p5b05f3e1l13b709d13b68599c@mail.gmail.com%3E
          -http://www.nabble.com/-Trinidad--tabIndex-support--td12296705.html
          -http://mail-archives.apache.org/mod_mbox/myfaces-dev/200705.mbox/%3C6dac79b90705040948x5b6810a4wb4741d12acb9f4c6@mail.gmail.com%3E

          not sure if there are other threads, but I think so;

          I can see the point of not patching the release all the time, so maybe you could upload your patch, so that the wider community could review it ?

          Show
          Matthias Weßendorf added a comment - complex == composite comps with more than one tab-stop (inputDate) or table some thoughts are here: - http://mail-archives.apache.org/mod_mbox/incubator-adffaces-user/200608.mbox/%3C6dac79b90608031518p5b05f3e1l13b709d13b68599c@mail.gmail.com%3E - http://www.nabble.com/-Trinidad--tabIndex-support--td12296705.html - http://mail-archives.apache.org/mod_mbox/myfaces-dev/200705.mbox/%3C6dac79b90705040948x5b6810a4wb4741d12acb9f4c6@mail.gmail.com%3E not sure if there are other threads, but I think so; I can see the point of not patching the release all the time, so maybe you could upload your patch, so that the wider community could review it ?
          Hide
          Marco Hallo added a comment -

          I've ask the developer to upload the patch.

          Show
          Marco Hallo added a comment - I've ask the developer to upload the patch.
          Hide
          Blake Sullivan added a comment -

          The row first vs. column first tabbing of panelFormlayouts is a good example of a use case. It is also a use case that is better addressed for the page author through an attribute than through tab index.

          Show
          Blake Sullivan added a comment - The row first vs. column first tabbing of panelFormlayouts is a good example of a use case. It is also a use case that is better addressed for the page author through an attribute than through tab index.
          Hide
          Blake Sullivan added a comment -

          Adding the comments from the most recent previous mail thread on this issue started on 3/18/08:

          Hey All -

          The concern with exposing a public component-level tabIndex attribute
          has always been that this opens up the potential for way more problems
          than it solves. The problem with HTML tabIndex attribute is that once
          you set one positive tabIndex value, in order to ensure that the tab
          traversal order matches the natural reading order (eg. the order in
          which a screen reader traverses the content), you are required to set
          tabIndex values on every tab stop on the page. This might be possible
          on extremely simple pages, but anything beyond that becomes
          unmanageable. Since it is not obvious to most page authors that
          setting tabIndex can actually have a negative impact on the
          accessibility of their page, we have historically avoided this issue
          by not exposing access to this functionality.

          The solution for the colorChooser problem is to:

          1. Make the first color cell a tab stop.
          2. Make all of the other color cells focusable, but not tab stops
          (tabIndex="-1").
          3. Implement up/down/left/right arrow key handlers which explicitly
          call element.focus() to move the focus to the appropriate color cell.

          I guess we could implement #1 and #2 now and leave #3 for later,
          though in the case where the chooseColor is used in an inputColor's
          popup (probably more common than the inline case), keyboard users
          would be losing some functionality - ie. they would no longer tab
          through the color cells in the popup. On non-FF browsers where the
          focus highlight is displayed, this might be considered useful, though
          clearly #3 is a much better solution.

          Andy

          Further elaborating on what Andy wrote, the reason why Trinidad has never supported tab index directly is that tab index is lame. In addition to the reasons that Andy listed, tab index has real problems when composing content from multiple authors (in the simplest case jsp:include), as there is no way for the authors to collaborate on the correct indices to use. Even specifying a tab-base on the locations where external content is included either hacking the ResponseWriter to modify the actual tab index written has potential problems with the limited tabindex space (0 - 32767) unless multiple passes are used. Even then, if the tab indices are packed too tightly together a PPR request that adds new items to be inserted into the tab order adds complexity, as it can require the shifting of existing indices to make space for the new items. All of this ignores sources of raw HTML content, such as Portlets, that a solely ResponseWriter-based system can't deal with.

          However, my biggest issue with exposing tab index on Trinidad components is that I doubt that it is even the appropriate abstraction. I suspect that some sort of focus manager strategy, attachable to any component would be more appropriate. I preferred to wait until we had a good set of concrete focus management use cases. We could then verify that a component tree with attached focus managers handled these cases and look at whether a small set of declarative focus managers covered these cases.

          – Blake Sullivan

          This was my main question after reading the Andrew's wiki page - I
          want to be sure to understand the use cases that we are trying to
          address before moving forward with a solution. Many use cases can be
          addressed by simpler solutions, eg:

          • The login page initial focus case can be addressed by tr:document
            initialFocusId.
          • The skip advertising/chrome use case can be addressed by improved
            skip link support.
          • The newspaper-style column-based tab traversal can be addressed by
            using multi-column panelFormLayouts, or similar dom structures.

          We should at least consider whether such solutions meet our
          requirements before deciding to add new functionality.

          Andy

          Show
          Blake Sullivan added a comment - Adding the comments from the most recent previous mail thread on this issue started on 3/18/08: Hey All - The concern with exposing a public component-level tabIndex attribute has always been that this opens up the potential for way more problems than it solves. The problem with HTML tabIndex attribute is that once you set one positive tabIndex value, in order to ensure that the tab traversal order matches the natural reading order (eg. the order in which a screen reader traverses the content), you are required to set tabIndex values on every tab stop on the page. This might be possible on extremely simple pages, but anything beyond that becomes unmanageable. Since it is not obvious to most page authors that setting tabIndex can actually have a negative impact on the accessibility of their page, we have historically avoided this issue by not exposing access to this functionality. The solution for the colorChooser problem is to: 1. Make the first color cell a tab stop. 2. Make all of the other color cells focusable, but not tab stops (tabIndex="-1"). 3. Implement up/down/left/right arrow key handlers which explicitly call element.focus() to move the focus to the appropriate color cell. I guess we could implement #1 and #2 now and leave #3 for later, though in the case where the chooseColor is used in an inputColor's popup (probably more common than the inline case), keyboard users would be losing some functionality - ie. they would no longer tab through the color cells in the popup. On non-FF browsers where the focus highlight is displayed, this might be considered useful, though clearly #3 is a much better solution. Andy Further elaborating on what Andy wrote, the reason why Trinidad has never supported tab index directly is that tab index is lame. In addition to the reasons that Andy listed, tab index has real problems when composing content from multiple authors (in the simplest case jsp:include), as there is no way for the authors to collaborate on the correct indices to use. Even specifying a tab-base on the locations where external content is included either hacking the ResponseWriter to modify the actual tab index written has potential problems with the limited tabindex space (0 - 32767) unless multiple passes are used. Even then, if the tab indices are packed too tightly together a PPR request that adds new items to be inserted into the tab order adds complexity, as it can require the shifting of existing indices to make space for the new items. All of this ignores sources of raw HTML content, such as Portlets, that a solely ResponseWriter-based system can't deal with. However, my biggest issue with exposing tab index on Trinidad components is that I doubt that it is even the appropriate abstraction. I suspect that some sort of focus manager strategy, attachable to any component would be more appropriate. I preferred to wait until we had a good set of concrete focus management use cases. We could then verify that a component tree with attached focus managers handled these cases and look at whether a small set of declarative focus managers covered these cases. – Blake Sullivan This was my main question after reading the Andrew's wiki page - I want to be sure to understand the use cases that we are trying to address before moving forward with a solution. Many use cases can be addressed by simpler solutions, eg: The login page initial focus case can be addressed by tr:document initialFocusId. The skip advertising/chrome use case can be addressed by improved skip link support. The newspaper-style column-based tab traversal can be addressed by using multi-column panelFormLayouts, or similar dom structures. We should at least consider whether such solutions meet our requirements before deciding to add new functionality. Andy
          Mathias Weber made changes -
          Status Open [ 1 ] Patch Available [ 10002 ]
          Hide
          Mathias Weber added a comment -

          Sorry, my last status change went there by error. I don't have an available patch

          Show
          Mathias Weber added a comment - Sorry, my last status change went there by error. I don't have an available patch
          Matthias Weßendorf made changes -
          Status Patch Available [ 10002 ] Open [ 1 ]
          Hide
          Carsten Pieper added a comment -

          Blake wrote:
          >The row first vs. column first tabbing of panelFormlayouts is a good example of a use case.
          >It is also a use case that is better addressed for the page author through an attribute than
          >through tab index.
          Well, yes, I have to agree. If there were such an panelFormLayout attribute that would do well for us (with less coding efforts). Hereby voting for it

          Show
          Carsten Pieper added a comment - Blake wrote: >The row first vs. column first tabbing of panelFormlayouts is a good example of a use case. >It is also a use case that is better addressed for the page author through an attribute than >through tab index. Well, yes, I have to agree. If there were such an panelFormLayout attribute that would do well for us (with less coding efforts). Hereby voting for it
          Hide
          Marco Hallo added a comment -

          I don't feel comfotible with a panelFormLayout based solution. What happens if you have column first tabbing with two columns (left and right)? In the left column you have a stack of adress fields. When you have to place a zip code and a city field they must perhaps placed in one row of the left colum. Or is the solution to add another container to adjust the taborder in the left column? I think that would produce pages where you can set tab order based on containers without exposing the tabindex attribute. Trinidad can rander the index and the developer only has to concentrate on the container.

          Show
          Marco Hallo added a comment - I don't feel comfotible with a panelFormLayout based solution. What happens if you have column first tabbing with two columns (left and right)? In the left column you have a stack of adress fields. When you have to place a zip code and a city field they must perhaps placed in one row of the left colum. Or is the solution to add another container to adjust the taborder in the left column? I think that would produce pages where you can set tab order based on containers without exposing the tabindex attribute. Trinidad can rander the index and the developer only has to concentrate on the container.
          Hide
          Blake Sullivan added a comment -

          Marco, I'm having a hard time picturing you panelFormLayout issue. The base issue here is what the abstraction or abstractions for controlling tabbing should be--both programmatic and declarative. To do that we need use cases like yours to ensure that we're covering the correct ground. I'm pretty certain that even if we were willing to make multiple passes through the component tree, rendering tabIndex would not be sufficient and that we will have to manage focus explicitly using javascript.

          Show
          Blake Sullivan added a comment - Marco, I'm having a hard time picturing you panelFormLayout issue. The base issue here is what the abstraction or abstractions for controlling tabbing should be--both programmatic and declarative. To do that we need use cases like yours to ensure that we're covering the correct ground. I'm pretty certain that even if we were willing to make multiple passes through the component tree, rendering tabIndex would not be sufficient and that we will have to manage focus explicitly using javascript.
          Andrew Robinson made changes -
          Assignee Andrew Robinson [ arobinson74 ]
          Transition Time In Source Status Execution Times Last Executer Last Execution Date
          Open Open In Progress In Progress
          53d 19h 30m 1 Andrew Robinson 02/Mar/08 22:58
          In Progress In Progress Open Open
          45d 20h 20m 1 Andrew Robinson 17/Apr/08 20:19
          Open Open Patch Available Patch Available
          458d 21h 6m 1 Mathias Weber 20/Jul/09 17:26
          Patch Available Patch Available Open Open
          27m 9s 1 Matthias Weßendorf 20/Jul/09 17:53

            People

            • Assignee:
              Unassigned
              Reporter:
              Andrew Robinson
            • Votes:
              9 Vote for this issue
              Watchers:
              10 Start watching this issue

              Dates

              • Created:
                Updated:

                Development