Re: Issue #134 Tab states updated proposal

On Wed, Nov 16, 2011 at 3:53 AM, Steve Faulkner
<faulkner.steve@gmail.com> wrote:
> Hi Tab, rereading your CP:
>
> you state
>
> "This is fundamentally a CSS issue."
>
> "The stated problem should probably be solved with CSS, as it is an
> issue of presentation."
>
> From an accessibility perspective this does not seem to be the case [1]
>
> Most accessibility APIs have distinct roles for tab, tabpanel and tablist
> and most platforms have distinct display features associated with
> tab/tabpanel/tablists and also distinct keyboard interactions.
>
> Can you put a little more 'meat on the bone' as to why a fairly ubiquitous
> interface design pattern with established semantics and interaction
> behaviours should not be considered as something worthy of supporting as a
> HTML feature?
>
>
> [1] http://www.w3.org/WAI/PF/aria-implementation/#mapping_role_table

Presenting something as a tabbed interface rather than as an ordinary
headers+sections document is a visual design choice.  You do interact
with it somewhat differently, but that can be handled from CSS and
magic as easily as it can from HTML and magic.  This proposal prevents
me from transforming a headers+sections document into a tabbed display
- I'm forced to choose the tabbed display up front.

There are further issues with this specific proposal (that may not be
present in other proposals of this type):

1. Reusing <menu> and <command> is probably a bad idea.  We shouldn't
be trying to duplicate the <input type> debacle - new types of things
should get new elements.  The current types of <menu> all represent
approximately the same thing, and are essentially just instructions to
the UA about how it should be displayed or interacted with.

2. It's not clear what the meaning of non-tab commands are in a
tablist menu, or how they can have a reasonable default presentation,
or what tab commands mean in a non-tablist menu.  The fact that *none*
of the existing command types are compatible with tablist menus is a
strong indicator that you should not be reusing <menu>/<command> here.

3. Tabs are associated with their panels by id.  This makes it more
difficult than necessary to have large numbers of tab stacks on a
page.  A solution that embraced the possibility of a tabbed interface
being a display choice over headers+sections interface could instead
associate tabs implicitly, making this easier for authors and harder
to accidentally misuse.

4. The change proposal still has the weird detail that UAs should
"ensure that only the currently selected tab control is focusable",
which doesn't make any sense to me.

~TJ

Received on Wednesday, 16 November 2011 15:19:14 UTC