- From: Sam Ruby <rubys@intertwingly.net>
- Date: Wed, 02 Mar 2011 18:14:11 -0500
- To: Steve Faulkner <faulkner.steve@gmail.com>
- CC: HTMLWG WG <public-html@w3.org>, Ian Hickson <ian@hixie.ch>
On 03/02/2011 05:42 PM, Steve Faulkner wrote: > Have also realised that the conformance checker example will need to > change as it talks about use of button on an a element as an error. Can > this be left to the editors discretion or is a modified version required? > > Current text: > Conformance checkers are encouraged to phrase errors such that authors > are encouraged to use more appropriate elements rather than remove > accessibility annotations. For example, if an |a > <http://dev.w3.org/html5/spec/text-level-semantics.html#the-a-element>| > element is marked as having the |button| role, a conformance checker > could say "Either a |button > <http://dev.w3.org/html5/spec/forms.html#the-button-element>| element or > an |input <http://dev.w3.org/html5/spec/forms.html#the-input-element>| > element is required when using the |button| role" rather than "The > |button| role cannot be used with |a > <http://dev.w3.org/html5/spec/text-level-semantics.html#the-a-element>| > elements". It seems to me that this text still makes sense, at least for now, given that there were a number of exclusions in the decision. For example: progressbar, radio, slider, or scrollbar for <a>. Put another way, if there is general agreement on any change made to this paragraph then there is no problem. Failing that, I would think that we would tend to act on requests to revert this paragraph to its current form should it be changed in a way that people object to. > regards > stevef - Sam Ruby > On 2 March 2011 22:33, Steve Faulkner <faulkner.steve@gmail.com > <mailto:faulkner.steve@gmail.com>> wrote: > > > Ian hickson wrote: > > "In the interests of avoiding mistakes, could you provide me with a > set of > edit instructions that state exactly what should change to fully comply > with this decision? I fear that attempting to apply the vague change > proposal in the original CP followed by the diff to that proposal quoted > above will result in errors." > > I have provided here > http://www.html5accessibility.com/tests/aria-changes.html > > A copy of the aria section revision 1.4093. with the required changes: > > the required changes are in the 2 data tables. > each deletion and insertion is marked using the <ins> and <del> > elements. > > NOTE: the deletion of the rows in the data tables pertaining to > the table, tr, td and th elemnts is NOT part of the change > proposal, but were removed earlier by the html5 editor and NO > agreement on re-inserting them has occured, but have mysteriously > re-appeared in this version of the spec, so need to be removed once > again > > regards > Stevef > > > On 2 March 2011 00:48, Ian Hickson <ian@hixie.ch > <mailto:ian@hixie.ch>> wrote: > > On Mon, 28 Feb 2011, Sam Ruby wrote: > > > > In any case, the above examples should not be exposed to ATs as > > buttons widgets even if they were valid. They are exposed > to users as > > link widgets, not button widgets, and thus that is the > appropriate AT > > behaviour and the appropriate ARIA role. > > > > We fail to follow the logic. They are exposed differently to > AT users > > and non-AT users and therefore this behavior is correct? > > I feel that the chairs' lack of understanding of this particular > argument > may have affected the decision with respect to the "button" role > on links > and the "link" role on buttons. > > The argument presented in favour of allowing these roles is that > this > (even in the absence of styling) is a button: > > <a href=# onclick="action()">Action</a> > > Putting aside the issue of whether such authoring should be > valid at all > in the first place, the counter-argument, which is quoted above > and was > apparently not understood by the chairs, is that this in not a > button. > > The type of widget that a user interacts with, as determined by > the user, > is determined not by the theoretical purpose that the author > intended the > widget to have, but by the actual user interaction with the > widget. For > the sample markup above, the rendering and behaviour of a visual > user > agent is that of a link, not of a button. As such, it would be > inappropriate, for the reasons described in the CCP and the > objections to > the original CP, to expose that link to ATs as a button. > > (The same argument applies in reverse, for <button role=link>.) > > > > Therefore, the HTML Working Group hereby adopts the ARIA in > HTML5: > > change some role mappings Proposal for ISSUE-129, with some > specific > > exclusions. Of the Change Proposals before us, this one has > drawn the > > weaker objections. > > > > The specific exclusions are: > > > > * Any changes to how <hgroup> elements are to be > interpreted, or how > > headings contained within such an <hgroup> are to be > interpreted. > > * Allowing slider, scrollbar, or progressbar for <button>, > <input > > type=image>, or <input type=image> > > * Allowing progressbar, radio, slider, or scrollbar for <a> > > * Allowing button, checkbox, option, radio, slider, > spinbutton, or > > scrollbar on <h1>-<h6> > > In the interests of avoiding mistakes, could you provide me with > a set of > edit instructions that state exactly what should change to fully > comply > with this decision? I fear that attempting to apply the vague change > proposal in the original CP followed by the diff to that > proposal quoted > above will result in errors. > > > > We encourage discussion to continue on these topics, and for the > > discussion to take tangible form as bug reports. Bug reports > on these > > specific topics will be allowed. > > Could you clarify how I should handle such bug reports? For > example, would > it be appropriate for me to edit the spec if someone filed a bug > saying > that allowing role=link on <button> is bad because buttons > aren't links, > don't look like links, don't act like links, and that this therefore > results in a situation where AT users and non-AT users get a > confusingly > different experience (e.g. they would not be able to easily > communicate > when discussing the page, since what one experienced as a link > the other > would see as a button)? Such a bug doesn't seem to fall foul of > the taboo > argument indicated here: > > > Bug reports predicated on the assumption that use cases of > adding ARIA > > to existing markup that mostly works but doesn't conform to > the ideals > > defined by the specification will be summarily closed. > > Also, since this decision has been given in the form of > rationale that is > to be applied to future bug reports as well, could the chairs > clarify what > the purpose of conformance criteria should be in general, if not > to help > authors avoid writing markup that "mostly works but doesn't > conform to the > ideals defined by the specification"? (Or is "ideals" being used > in a > narrower sense than "best practices" and "avoiding mistakes" > principles > that was used in the arguments against these changes?) > > -- > Ian Hickson U+1047E > )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ > ;`._ ,. > Things that are impossible just take longer. > `._.-(,_..'--(,_..'`-.;.' > > > > > -- > with regards > > Steve Faulkner > Technical Director - TPG > > www.paciellogroup.com <http://www.paciellogroup.com> | > www.HTML5accessibility.com <http://www.HTML5accessibility.com> | > www.twitter.com/stevefaulkner <http://www.twitter.com/stevefaulkner> > HTML5: Techniques for providing useful text alternatives - > dev.w3.org/html5/alt-techniques/ > <http://dev.w3.org/html5/alt-techniques/> > Web Accessibility Toolbar - > www.paciellogroup.com/resources/wat-ie-about.html > <http://www.paciellogroup.com/resources/wat-ie-about.html> > > > > > -- > with regards > > Steve Faulkner > Technical Director - TPG > > www.paciellogroup.com <http://www.paciellogroup.com> | > www.HTML5accessibility.com <http://www.HTML5accessibility.com> | > www.twitter.com/stevefaulkner <http://www.twitter.com/stevefaulkner> > HTML5: Techniques for providing useful text alternatives - > dev.w3.org/html5/alt-techniques/ <http://dev.w3.org/html5/alt-techniques/> > Web Accessibility Toolbar - > www.paciellogroup.com/resources/wat-ie-about.html > <http://www.paciellogroup.com/resources/wat-ie-about.html>
Received on Wednesday, 2 March 2011 23:14:43 UTC