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

On Sat, Nov 7, 2009 at 11:36 AM, John Foliot <> 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.


Received on Saturday, 7 November 2009 20:40:20 UTC