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

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