- From: Steve Faulkner <faulkner.steve@gmail.com>
- Date: Wed, 2 Mar 2011 22:42:51 +0000
- To: Sam Ruby <rubys@intertwingly.net>
- Cc: HTMLWG WG <public-html@w3.org>, Ian Hickson <ian@hixie.ch>
- Message-ID: <AANLkTi=nhpK5HK8EHw3eUcDOBkc3gcEEgs781VBd1+2x@mail.gmail.com>
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". regards stevef On 2 March 2011 22:33, Steve Faulkner <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> 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 | www.HTML5accessibility.com | > www.twitter.com/stevefaulkner > HTML5: Techniques for providing useful text alternatives - > dev.w3.org/html5/alt-techniques/ > Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html > > > -- with regards Steve Faulkner Technical Director - TPG www.paciellogroup.com | www.HTML5accessibility.com | www.twitter.com/stevefaulkner HTML5: Techniques for providing useful text alternatives - dev.w3.org/html5/alt-techniques/ Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
Received on Wednesday, 2 March 2011 22:43:45 UTC