W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > March 2011

[Bug 11956] restrict use of role=presentation

From: <bugzilla@jessica.w3.org>
Date: Fri, 04 Mar 2011 19:22:49 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1PvaaP-0003CY-Jk@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11956

--- Comment #7 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> 2011-03-04 19:22:48 UTC ---
(In reply to comment #6)
> (In reply to comment #5)

> > hi leif, i am aware of bug 10919 it does not provide use cases for using
> > presentation on form controls or links.
> 
> There you mention two very specific elements. May be  it can be justified that
> those elements are excempted from the general permission to use
> role=presention. In contrast, this bug report covers "all" elements. 
> 
> Btw, role=presentation is not the only thing that could make form controls and
> links inaccessible to AT.  Placing form controls or links inside elements with
> role="img" would do the same. (Example: <div role=img ><a
> href="*">link</a></div>) 

And, related, what about aria-labelledby or aria-describedby, if they are used
to point to an anchor element or a form control element?  Would that be any
useful? Such an anchor element would appear completely dead - it would only be
a presented to the AT user as pure text - click-ability would be gone. When is
that useful?

It seems that the real problem here is those specific, interarictive elements
that you mention - in relation to *any* ARIA feature that in some way or
another removes their interactivity.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Friday, 4 March 2011 19:22:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 4 March 2011 19:22:53 GMT