Re: ARIA roles added to the a element should be conforming in HTML5.

Hi Maciej,

>There are some elements with enough built-in behavior that it doesn't make
sense to change their role with ARIA. For example, it doesn't really make
sense >to say a <textarea> is a checkbox.

While i agree with this in principle, if a developer has gone to the trouble
of adding a role and associated aria properties/states to a text area, it
would make sense that he/she has added these on top of scripting and styling
to make the textarea into a checkbox for other users. Not that doing any of
this would be the sane approach, but making conformance in this case hinge
on the addition of ARIA does not seem the sane approach either. But think
this example is very unlikely to occur. If it does, I would suggest checking
that the appropriate aria properties are present for the role in question,
if not it would be more likley to indicate a coding error, and provide a
conformance checker warning asking the developer if they have really, really
scripted this element to act like a checkbox. If so it this that should be
flagged as a conformance error not the addition of the ARIA attributes.

> Is it worthwhile for the spec to tell people doing such things that they
are wrong?

I have no issue with telling people they should not script elements such as
the a element to act like a button, but this advice should not prohibit the
addition of ARIA to improve the accessibility and the additon of ARIA if the
developer ignores such conformance criteria, and should not be the point at
which conformance errors are flagged in validators.


regards
Stevef

2009/10/21 Maciej Stachowiak <mjs@apple.com>

>
> On Oct 21, 2009, at 2:23 AM, Jonas Sicking wrote:
>
> On Wed, Oct 21, 2009 at 1:45 AM, Steven Faulkner
>> <faulkner.steve@gmail.com> wrote:
>>
>>> hi maciej,
>>>
>>>> I think <button> is pretty consistently fully stylable cross-browser
>>>> (unlike, say, <input type="button">).
>>>>
>>> This is really incidental to the issue being discussed, most, if not all
>>> html elements can be scripted and styled in a way that overides their
>>> native
>>> semantic
>>> If this is allowed, then it follows that the addition of ARIA roles
>>> should not result in a conformance error, as the addition of ARIA is
>>> incidental to the developers intention to overide the native semantics.
>>>
>>
>> Couldn't the same argument be made for any other element as well? Does
>> this mean that we should allow ARIA roles on all elements?
>>
>> I guess there still are a few exceptions, like <script>, <style>, and
>> <form>.
>>
>> But for example <h1> can be overridden to look and act like a button
>> or a link, does this mean that we should allow arbitrary ARIA on <h1>?
>>
>
> There are some elements with enough built-in behavior that it doesn't make
> sense to change their role with ARIA. For example, it doesn't really make
> sense to say a <textarea> is a checkbox. If your markup says that, you
> probably made a mistake. I'm personally not sure whether elements with
> strong semantics but fairly simple built-in behavior (like <a> or <h1>)
> should be able to take arbitrary roles. In practice, the most often
> repurposed elements are <div>, <span> and <li>, so it's not clear there is
> much need to put a funky custom role on <h1>. But it does seem fairly common
> to use an <a> element with styling and a click event listener or javascript:
> URL as a button, instead of as a link. Is it worthwhile for the spec to tell
> people doing such things that they are wrong?
>
>  - Maciej
>
>


-- 
with regards

Steve Faulkner
Technical Director - TPG Europe
Director - Web Accessibility Tools Consortium

www.paciellogroup.com | www.wat-c.org
Web Accessibility Toolbar -
http://www.paciellogroup.com/resources/wat-ie-about.html