RE: ISSUE-134 change proposals review - Part 2

The Chairs have not received any kind of reply to this review of the CP for ISSUE-134.  

Does the TF plan to work on this Change Proposal in any way to improve it?

/paulc

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


-----Original Message-----
From: Paul Cotton [mailto:Paul.Cotton@microsoft.com] 
Sent: Wednesday, February 15, 2012 10:43 AM
To: Oedipus@hicom.net
Cc: public-html@w3.org
Subject: ISSUE-134 change proposals review - Part 2

The following is a review of your change proposal for ISSUE-134:
http://www.w3.org/html/wg/wiki/ChangeProposals/tablist_and_tab_states_for_menu_and_command_elements

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:
http://lists.w3.org/Archives/Public/public-html/2011Jul/0235.html

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":
http://lists.w3.org/Archives/Public/public-html/2011Jul/0221.html
http://lists.w3.org/Archives/Public/public-html/2011Jul/0222.html

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.

/paulc
HTML WG co-chair

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

Received on Tuesday, 28 February 2012 19:57:20 UTC