- From: Anne van Kesteren <annevk@opera.com>
- Date: Thu, 29 May 2008 14:39:56 +0200
- To: "Henry S. Thompson" <ht@inf.ed.ac.uk>, "Aaron M Leventhal" <aleventh@us.ibm.com>
- Cc: "public-html@w3.org" <public-html@w3.org>, "public-xhtml2@w3.org" <public-xhtml2@w3.org>, w3c-wai-pf@w3.org, "wai-xtech@w3.org" <wai-xtech@w3.org>, "www-tag@w3.org" <www-tag@w3.org>
On Thu, 29 May 2008 14:13:43 +0200, Henry S. Thompson <ht@inf.ed.ac.uk> wrote: > We have to set against the problems with aria: the medium- and > long-term negative aspects of the aria- approach, which focusses on > ease of ARIA integration in text/html environments at the expense of > costly integration throughout the application/...+xml universe. From > my perspective, the cost of aria: in the text/html environment is > modest, manageable, and declining over time, whereas the cost of aria- > in the application/...+xml universe is large and permanent. This is by no means proven. I don't buy it at all that the specific syntax has much impact on the cost of introducing ARIA in any vocabulary. The cost of ARIA is in figuring out what happens when native and ARIA semantics clash. Also, as for syntax, I'd claim that given the HTML environment we have on the Web (which is by the way much larger than this magical XML universe, but that's besides the point), introducing aria-* is of much lower cost to everyone involved than introducing aria:*. We need ARIA in HTML, XHTML, and SVG. Those languages don't have that attribute now. The only cost of introducing those attributes is the cost I mentioned above, figuring out what happens in case of clashing semantics, which we have regardless of syntax. The cost of introducing aria:* however is bigger, because of DOM and styling differences as has been explained countless times. As well as making it impossible to ever change the way colon works in HTML, et cetera. -- Anne van Kesteren <http://annevankesteren.nl/> <http://www.opera.com/>
Received on Thursday, 29 May 2008 12:42:03 UTC