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

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

Received on Monday, 9 November 2009 12:26:28 UTC