Re: Update to ARIA processing change proposal ISSUE-199

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

-- 

Janina Sajka,	Phone:	+1.443.300.2200
			sip:janina@asterisk.rednote.net
		Email:	janina@rednote.net

The Linux Foundation
Chair, Open Accessibility:	http://a11y.org

The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Chair,	Protocols & Formats	http://www.w3.org/wai/pf
	Indie UI			http://www.w3.org/WAI/IndieUI/

Received on Thursday, 28 June 2012 19:20:53 UTC