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

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.


regards
Stevef


2009/11/7 Tab Atkins Jr. <jackalmage@gmail.com>

> On Sat, Nov 7, 2009 at 11:36 AM, John Foliot <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 | www.wat-c.org
Web Accessibility Toolbar -
http://www.paciellogroup.com/resources/wat-ie-about.html