Re: ISSUE-134 change proposals review - Part 2

On 03/20/2012 09:04 AM, Sam Ruby wrote:
> On 02/29/2012 11:11 AM, Paul Cotton wrote:
>> Thank you for your reply Jason. But I believe my question is still
>> outstanding:
>>
>>>> Does the TF plan to work on this Change Proposal in any way to
>>>> improve it?
>
> Since this question was never answered, the chairs are asking if anybody
> actively supports this proposal, and intends to either address the
> comments made by the chairs or would like the proposal to be considered
> as is.
>
> If no such response is received by March 28th, we will consider the
> proposal to be withdrawn.

We now consider the proposal to be withdrawn, and are marking issue 134 
as POSTPONED.

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

- Sam Ruby

>> -----Original Message-----
>> From: Jason Kiss [mailto:jason@accessibleculture.org]
>> Sent: Tuesday, February 28, 2012 11:46 PM
>> To: Paul Cotton
>> Cc: Janina Sajka<janina@rednote.net> (janina@rednote.net); Judy
>> Brewer<jbrewer@w3.org> (jbrewer@w3.org); public-html-a11y@w3.org;
>> Oedipus@hicom.net
>> Subject: Re: ISSUE-134 change proposals review - Part 2
>>
>> To address some of the initial comments from Tab and others in mid
>> 2011, I made some changes in November 2011 to the original Change
>> Proposal as initiated by Everett Zufelt and edited by Gregory J.
>> Rosmaita
>> (http://www.w3.org/html/wg/wiki/ChangeProposals/tablist_and_tab_states_for_menu_and_command_elements).
>>
>>
>>
>> I made some very minor revisions today to clarify a few passages, as
>> well, but am not in a position at the moment to spend significant time
>> on it.
>>
>> I'm happy to contribute as I can should the TF wish to offer any input.
>>
>> Regards,
>>
>> Jason
>>
>>
>>
>> On 29/02/12 08:56, Paul Cotton wrote:
>>> 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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> --
>> Jason Kiss
>> Web: www.accessibleculture.org
>> Mobile: +64 021 929 238
>> Email: jason@accesscult.org
>> Twitter: @jkiss
>>
>>
>>
>
>

Received on Friday, 30 March 2012 11:20:28 UTC