Re: Working Group Decision on ISSUE-129 aria-mapping

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