W3C home > Mailing lists > Public > public-html-a11y@w3.org > February 2012

Fwd: ISSUE-134 change proposals review - Part 2 (ISSUE-134: Provide tablist and tab states)

From: Laura Carlson <laura.lee.carlson@gmail.com>
Date: Wed, 15 Feb 2012 15:32:30 -0600
Message-ID: <CAOavpvc=b-k0QkZBBaWFs0VNJAOJZYFhvHph8puN9XxGCU3J6A@mail.gmail.com>
To: HTML Accessibility Task Force <public-html-a11y@w3.org>
Cc: "E.J. Zufelt" <everett@zufelt.ca>, jason@accessibleculture.org, "Gregory J. Rosmaita" <gregory.rosmaita@gmail.com>
Hi all,

I am forwarding the following message for the task force's information
regarding ISSUE-134: Provide tablist and tab states.

I don't think it was copied to this list.

Best Regards,

---------- Forwarded message ----------
From: Paul Cotton <Paul.Cotton@microsoft.com>
Date: Wed, Feb 15, 2012 at 9:43 AM
Subject: ISSUE-134 change proposals review - Part 2
To: "Oedipus@hicom.net" <Oedipus@hicom.net>
Cc: "public-html@w3.org" <public-html@w3.org>

The following is a review of your change proposal for ISSUE-134:

This review if provided in order to help WG members improve the
quality of their change proposals and to ensure that the WG Chairs
make their views known about the completeness of change proposals well
in advance of moving the related issues to the survey stage.

The re-open request for ISSUE-134 from Tab provides some comments on
your change proposal that you might consider using as input to improve
the strength of your arguments:

For example providing clarifications for the following items would
improve your change proposal:

> 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.

In addition representatives of two user agents have explicitly stated
that they will not implement this change proposal when they responded
to the "CfC: Close ISSUE-134 tab-states by Amicable Resolution":

In particular the comments about the following points might be used to
make your change proposals more complete:

a) by providing more information on how your changes to <menu> and
<command> could be integrated with CSS, and/or
b) by providing further information on implementer's experience with
implementing the currently defined <menu> and <command> semantics and
showing that your additions integrate well with those implementations.

You might consider obtaining feedback from other user agent
implementers if they are willing to implement your proposal.

HTML WG co-chair

Paul Cotton, Microsoft Canada
17 Eleanor Drive, Ottawa, Ontario K2E 6A3
Tel: (425) 705-9596 Fax: (425) 936-7329

Laura L. Carlson
Received on Wednesday, 15 February 2012 21:33:02 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:26 UTC