W3C home > Mailing lists > Public > wai-xtech@w3.org > November 2009

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

From: Steven Faulkner <faulkner.steve@gmail.com>
Date: Mon, 9 Nov 2009 05:03:14 -0800
Message-ID: <55687cf80911090503g7fe85998qfd0bd6914af6a574@mail.gmail.com>
To: Sam Ruby <rubys@intertwingly.net>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, John Foliot <jfoliot@stanford.edu>, Jonas Sicking <jonas@sicking.cc>, Richard Schwerdtfeger <schwer@us.ibm.com>, HTMLWG WG <public-html@w3.org>, W3C WAI-XTECH <wai-xtech@w3.org>
hi sam,
>It is my experience that conversations are more productive when anchored by
specifics.  Given that there are implementations, instead of simply saying
"Y >should be allowed", statements like "tool X does Y for reason Z; Y is
currently considered non-conformant; which should change, X or the draft?"
would likely >end up with a better (and quicker) outcome.


which is what i did at the start of this thread. and consequently moved it
to a bug and then escalated it to the html wg tracker.

regards
stevef


2009/11/9 Sam Ruby <rubys@intertwingly.net>

> Steven Faulkner wrote:
>
>> hi Tab,
>>   >I'm reasonably certain that ARIA is *not* in wide use at the moment
>>  Its implemented to varying degrees in all of the major javscript UI
>> libraries, as well as major CMS's such as wordpress and drupal, its in use
>> by both Google and yahoo for many of their web applications and widgets. It
>> is in use in over 200 IBM web based applications. So it depends on your
>> definition of wide use.
>>  I personally would prefer that developers stayed within the boundaries of
>> correct usage (as defined within a spec) for HTML elements and attributes,
>> but they don't. When they extend the semantics of HTML to create UI widgets,
>> without the addition of ARIA it is most likely they will not be
>> understandable to AT users.
>> Making ARIA non conformant does not encourage developers to do the right
>> thing, it encourages them not to use ARIA. It does not make sense to
>> penalise developers for use of ARIA when it is not the use of ARIA that
>> causes an issue.
>>
>
> It is my experience that conversations are more productive when anchored by
> specifics.  Given that there are implementations, instead of simply saying
> "Y should be allowed", statements like "tool X does Y for reason Z; Y is
> currently considered non-conformant; which should change, X or the draft?"
> would likely end up with a better (and quicker) outcome.
>
> regards
>> Stevef
>>
>
> - Sam Ruby
>
> 2009/11/7 Tab Atkins Jr. <jackalmage@gmail.com <mailto:
>> jackalmage@gmail.com>>
>>
>>
>>    On Sat, Nov 7, 2009 at 11:36 AM, John Foliot <jfoliot@stanford.edu
>>     <mailto:jfoliot@stanford.edu>> wrote:
>>     > We really have no reason to believe any given author will do
>> anything
>>     > right *or* wrong; experience tells us to expect both. The real
>>    question
>>     > is, why impose limits when we don't really need to? Think
>>    inclusive, not
>>     > restrictive.
>>
>>    That doesn't work here.  We know what we want to encourage (using the
>>    correct elements whenever possible, and only falling back to ARIA when
>>    the semantics aren't quite right or just don't exist).  I'm reasonably
>>    certain that ARIA is *not* in wide use at the moment, so any mistakes
>>    made are likely minimal.  Thus, we should restrict away.  It's *much*
>>    easier to remove a restriction that turns out to be widely violated
>>    than it is to impose one after the fact.
>>
>>     > We can see JS libraries do that (add a role attribute to the <a>)
>>    for the
>>     > author if/when required (as one use-case: ARIA is/was designed
>>    primarily
>>     > for "DHTML / AJAX").  Moreover, what real harm is caused by
>>    allowing to do
>>     > so?  We can't envision all uses that authors might dream up moving
>>     > forward: look at Bespin and Canvas - nobody really envisioned
>>    Bespin like
>>     > use when Canvas was spec'd, yet here we are today.
>>
>>    Indeed, and it's great that creative uses like Bespin happen.  That
>>    pushes the technology forward, and also helps highlight the problems
>>    (in Bespin's case, the accessibility story for <canvas>).  If/when
>>    creative and unexpected things happen with ARIA that would require a
>>    violation of the existing reasonable restraints, that will show they
>>    are unreasonable and should be changed.  At that point they can and
>>    *will* be changed, assuming the people of the future are at least
>>    halfway sane.  It's not like an invalid use of ARIA causes technical
>>    problems preventing a page from working, after all.  There is
>>    flexibility built in to allow experimentation; we don't need to
>>    actively push such experimentation for it to happen.
>>
>>    ~TJ
>>
>>
>>
>>
>> --
>> with regards
>>
>> Steve Faulkner
>> Technical Director - TPG Europe
>> Director - Web Accessibility Tools Consortium
>>
>> www.paciellogroup.com <http://www.paciellogroup.com> | www.wat-c.org <
>> http://www.wat-c.org>
>>
>> Web Accessibility Toolbar -
>> http://www.paciellogroup.com/resources/wat-ie-about.html
>>
>
>


-- 
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
Received on Monday, 9 November 2009 13:03:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 13:16:07 GMT