3 Replies Latest reply on May 5, 2010 9:43 AM by Jay Balunas

    Keyboard navigation in semantic HTML markup

    Nick Belaevski Master

      In this thread I want to discuss the following question: what is the better way to support keyboard navigation in semantic HTML markups.

      This includes support for tab-based navigation and (probably) access keys.

       

      HTML 5 declares that any element should have "tabindex" attribute and in any modern browser explicitly setting "tabindex" makes the element participate in tab-based navigation. Even more, CSS 3 declares "tab-index" property, however it seems to be not supported in Chrome & FF.

       

      HTML 4 DTD declares only limited set of elements that support "tabindex" attribute, and A element (with "href" attribute) is the most handy among them.

      However I have concerns about usage of A element:

      • Such usage does not seem to be semantic, as we are really not going to make focusable part a hyperlink
      • Nested A elements are not allowed, so user won't be able to place hyperlink for example in tab label area
      • Browsers have built-in styling for A element, that we'll have to override

       

      Alternative solution is JavaScript usage, so that we create some class e.g. RichFaces.TabbedControl or function RichFaces.includeIntoTabOrder that's task is to:

      • Assign "tabindex" to element
      • Handle activation events from keyboard

       

      JavaScript solution won't work without JavaScript enabled and can decrease performance of page load.

       

      WDYT?

        • 1. Re: Keyboard navigation in semantic HTML markup
          Ilya Shaikovsky Master
          Such usage does not seem to be semantic, as we are really not going to make focusable part a hyperlink

          if the child content could not be redefined by end developer - I think it's most simple and elegant solution. So we have to decide how much we want to sacrifice in order to be "semantic"

           

          Nested A elements are not allowed, so user won't be able to place hyperlink for example in tab label area

          This however is more serious problem and could be the reason to reject this idea. But how about to use <a> explicitly encoded as anchor and not to wrap the content itself? something like :

          <div>
          <a>//some fake anchor which will handle the styling of the whole div when focused/leaved//</a>
          actual label content
          </div> 
          

          not looks really good but just rough idea.

          Browsers have built-in styling for A element, that we'll have to override

          I believe that not a big deal which could be solved by some common class for all such links.

           

          About the second idea, especially about

          JavaScript solution won't work without JavaScript enabled

          Actually almost nothing will works with JavaScript disabled. "Rich" components will became just "pretty" wrappers and all Ajax stuff will be "broken" And I believe we should not even consider that.

          and can decrease performance of page load.

          This however should be estimated using some prototype in order to have clean vision for making decisions.

          • 2. Re: Keyboard navigation in semantic HTML markup
            Jay Balunas Master

            After discussions in IRC....

             

            No one seems crazy about the <a> tag, and almost nothing in richfaces ( or any rich component set ) will work with JS off.

             

            The idea of a tab index component/behavior seems worth looking into more.

             

            We could handle cross-browser and technology issues in the tag, and give developers a single place to assign this.

             

            -Jay

            • 3. Re: Keyboard navigation in semantic HTML markup
              Jay Balunas Master

              After an IRC discussions we have decided to postpone this until one of the milestone releases.

               

              I have created https://jira.jboss.org/jira/browse/RFPL-587 to cover this and have attached the IRC log to it.