Re: Update to ARIA processing change proposal ISSUE-199

I've edited the proposal for these changes as I understood them.
Hopefully this means it's ready to move to consensus call. Michael

Janina Sajka wrote:
> Colleagues:
>
> Inasmuch as minutes from the WG teleconference today:
> http://www.w3.org/2012/06/28-html-wg-minutes.html
> do not clearly delineate the next steps we agreed during the call, I ask
> that the WG Chairs promptly correct my characterization of those next
> steps should I misrepresent them in any way.
>
> Michael, your acceptance of Ted's two edits was noted. The WG requests
> you proceed to make those changes in the CP.
>
> Agreement to have the new spec editor wordsmith the CP was also noted,
> provided that we be afforded the opportunity to review, and correct as needed, the editors rewording. It was requested that you add a note to this effect to the CP.
>
> By my reading, this should almost close consensus. The remaining item
> unaddressed is whether the editorial section Ted wants to remove, but
> Michael wishes to keep, can stay. It appears to me the next step on this
> item is Ted's.
>
> Is any of this incorrect?
>
> Janina
>
>
>
> Michael Cooper writes:
>   
>> Thanks for your feedback. My comments are inline below. In summary, I
>> think we've agreed on the basic proposal and are at the stage of
>> "dotting i's and crossing t's".
>>
>> Edward O'Connor wrote:
>>     
>>> Hi,
>>>
>>> Michael Cooper wrote:
>>>
>>>       
>>>> I have updated the ISSUE-199 Change Proposal on ARIA processing,
>>>> following guidance from the 3 May 2012 discussion and incorporating
>>>> much of Ted O'Connor's counter proposal. I believe this version
>>>> covers the agreement of that meeting. Some details of HTML-style spec
>>>> language may need to be tweaked.
>>>>
>>>> http://www.w3.org/html/wg/wiki/ChangeProposals/ARIA_Processing
>>>>         
>>> This revised proposal is definitely much closer to something that I
>>> think we could find consensus on. Some notes:
>>>
>>> There's no rationale provided for the changes proposed in the section
>>> titled "Clarify the existing ARIA section." As the change appears
>>> entirely editorial, I'd rather we leave it out of a consensus proposal.
>>>       
>> Hmm... I agree this is editorial, but I do think it makes the section
>> easier to process. If it's not blocking consensus (which I don't know
>> that it is), I'd rather leave it in. I'm not sure how to express an
>> explicit rationale, other than "people seemed to be misreading the
>> relationship of the parts of the section and adding these headers help
>> to distinguish them better".
>>     
>>> The text of the "Role attribute" section closely matches the text of
>>> my proposal. There are two differences:
>>>
>>> 1. The proposed spec section is titled "Role Attribute," whereas in my
>>> proposal it's titled "The ARIA role attribute." Because of the
>>> historical origins of the name of WAI-ARIA's role="" attribute in the
>>> XHTML Role Attribute Module, I think it's helpful to consistently
>>> refer to the attribute in spec text as "the ARIA role attribute" to
>>> avoid the implication that the attribute is intended as a generalized
>>> vehicle with which to imbue elements with additional semantics.
>>>       
>> I can see the point of this argument, that it could be read as
>> incorporating by reference features of the Role Attribute that HTML has
>> explicitly declined. I do I think it is misleading to call the section
>> "ARIA role attribute", since it is not defined in ARIA, but I don't feel
>> strongly enough about the issue to push back on this. So to be formal,
>> I'll accept this edit.
>>     
>>> 2. The "split on spaces" paragraph isn't marked as an implementor-only
>>> section. It probably should be, but I doubt this is an area of
>>> intentional disagreement.
>>>       
>> I didn't attempt to include certain flags the editor might include,
>> since I don't know what they are or how best to include them in a change
>> proposal in the wiki. I am happy to have the change proposal expressing
>> this in whatever manner is appropriate. In other words, I accept this edit.
>>     
>>> In terms of normative statements, I have no objection to the text in
>>> the section titled "State and Property Attributes." That said, I find
>>> this text hard to understand, so I would prefer a consensus proposal
>>> describe the normative requirements and defer to the editor for the
>>> precise wordsmithing.
>>>       
>> I'd be ok with the editor taking a stab at wordsmithing this, but only
>> if there is a check-back phase to make sure substantive changes aren't
>> unintentionally introduced. Alternatively, somebody else could clean
>> this up before we call for consensus. I have tried several times to come
>> up with wording for this section, and don't believe I would be able to
>> make further improvements that you will consider better. I think if
>> we're agreed on the substance, the wording that others feel better
>> represents it is better proposed by those people - yourself, or somebody
>> else who feels they have a handle on it.
>>     
>>> Thanks,
>>> Ted
>>>       
>> Michael
>> -- 
>>
>> Michael Cooper
>> Web Accessibility Specialist
>> World Wide Web Consortium, Web Accessibility Initiative
>> E-mail cooper@w3.org <mailto:cooper@w3.org>
>> Information Page <http://www.w3.org/People/cooper/>
>>
>>     
>
>   

-- 

Michael Cooper
Web Accessibility Specialist
World Wide Web Consortium, Web Accessibility Initiative
E-mail cooper@w3.org <mailto:cooper@w3.org>
Information Page <http://www.w3.org/People/cooper/>