`Tabs` widget

[nexushoratio]

The current implementation relies on CSS with hidden radio button and labels to activate panels. But a lot of JavaScript was still involved for set up, keyboard and event handling. That probably made things more difficult than it should have been.

Before we had HTML looking like this:

<section>
  <input> ... </input>
  <input> ... </input>
  <nav>
    <label> ... </label>
    <label> ... </label>
  </nav>
  <div> ... </div>
  <div> ... </div>
</section>

Where all of those elements were generated by the API. The nav element was the tablist role and label the tab role. What should be used now? Continue with nav/label or use ul/li? There may have been a suggestion to use button for the tab role. Research needed.

N.B.: It is unfortunate that the label has the role tab, as that is a handy noun to describe the whole title/content combination. What is better? For Grid we used GridColumn. Would TabEntry work? Like GridColumn, would it make sense to have a dedicated class that has two associated widgets instead of the caller keeping track of both things themselves? It could then an object for name/tab(label)/panel.

• ARIA details
  • Pattern
  • tablist navigation (when tab has focus)
    • left/right OR up/down arrow keys move between tabs when they have focus (vs Control modifiers currently used)
    • home/end moves to first/last tab (optional)
  • tablist container has role tablist
  • tablist exactly one of the attributes aria-labelledby or aria-label; similar to Modal
  • label elements have role tab
  • tab elements must have aria-controls attribute referencing associated tabpanel
  • All tabs have attribute aria-selected, true for active, false for rest
  • content panels must have role tabpanel
  • tabpanels must have attribute aria-labelledby identifying tab
  • tabpanel itself must be focusable (tabindex=0) if has no focusable content
• Flesh out TabEntry
• See if TabEntry should actually be a Widget with tabpanel being the base element
• Some other Widgets use custom elements, why not?
• The tab entries should be a live like GridColumns
• gotoTab(tab)
• first()/last()/next()/prev()
• Call build() on build
• Call destroy() on destroy
• Call show()/hide() on tab change
• Min size on tabs: There are standards that say how small a clickable item should be. The W3C folks recommend 44x44px. Material design recommends 48x48. And LinkedIn's own stuff seems to be anywhere from 32x32 to 54x54 depending on where.