Re: CfC: Close ISSUE-134 tab-states by Amicable Resolution

On Thu, Jul 14, 2011 at 5:16 AM, Sam Ruby <rubys@intertwingly.net> wrote:
> First, thanks to Tab, Jonas, and Anne for your feedback on issue 134.
>
> I'd like to draw your collective attention to the fact that we have a
> long-standing policy[1] of allowing issues to be reopened based on new
> information and a concrete change proposal.
>
> I encourage each of you to consider submitting a change proposal on this
> matter.

Sure.  I'd like to submit a request to reopen.

New Data
========

1. The "Details" part specifies that "User agents must manage focus
for the tab controls by ensuring that only the selected tab is
focusable, and that the remaining tabs in the tablist menu are not
focusable.".  However, the "Risks" section states without such an
element, developers might make "only the selected tab in each
tablist... focusable, meaning that the remaining tabs from each
tablist will not be available or accessible to assistive
technologies.".  Is this a good or bad thing?

2. In "Details", "tabpanel" is listed as a state for <command>
elements, but later text seems to suggest that it should be an
attribute on <command> elements that takes an IDREF.

3. The CP doesn't indicate what the proposed changes should *do*.  The
intention is clearly to make it easier to do cardstacks, where you
have a list of tabs associated with cards, and only one card is
visible at a time (and its tab is specially indicated in the tablist).
 But nothing like that is specified anywhere.  It appears that authors
would still need to use script to create this kind of UI.

4. This is fundamentally a CSS issue.  I've thought about this exact
problem before, and while I suspect there *may* be something we need
to do at the host-language level to connect tabs to cards, that
conclusion should only come after some research has been put into the
problem by the CSS Working Group.

5. An Opera representative has stated that Opera would not implement
this proposal.  A Firefox representative has expressed doubts that
this is an appropriate solution to the stated problem.  I (a Chrome
developer) also believe this is not an appropriate solution to the
stated problem.


Counter Change Proposal
=======================

Summary
-------
No change.

Rationale
---------
The stated problem should probably be solved with CSS, as it is an
issue of presentation.  If it is best solved in HTML, it is likely
*not* through the provided solution, which overloads the <menu> and
<command> elements with additional semantics, similar to the known
anti-pattern exemplified by <input>.

Benefits
--------
A bad solution is not adopted.  Work is not misspent on bad solutions
that could instead be spent on investigating a good, CSS-based solution.

Risks
-----
Tablists continue to be fiddly to implement in a fully accessible way
for an extended period of time.  They've been that way for years,
though, so this isn't a new issue.

~TJ

Received on Thursday, 14 July 2011 21:13:00 UTC