- From: Richard Schwerdtfeger <schwer@us.ibm.com>
- Date: Wed, 10 Oct 2007 09:04:39 -0500
- To: "Anne van Kesteren" <annevk@opera.com>
- Cc: "Matthew Raymond" <mattraymond@earthlink.net>, public-html@w3.org, wai-xtech@w3.org, wai-xtech-request@w3.org
- Message-ID: <OF45B090C3.97F078C3-ON86257370.004C083E-86257370.004D53D1@us.ibm.com>
Hi Anne, Simon's proposal does not mention stating the set of roles as a fallback mechanism sequence. That needs to be handled elsewhere. I am also worried that having multiple roles as you stated (for fallbacks) will make things more complicated for authors. Back to the forking issue: You know that the role module does not actually say what the user agent should do with the role attribute. Even if it were a qname you could just treat the role as a string and pass it off to the AT. So, from an AT interoperability piece it really is a situation where we say treat it as a string: flowchart:decision for example. If middelware wants to use the role qname for some other purpose should the browser really care? For example, Mark Birbeck uses roles to do semantic processing of the document. That does not impact the browser. At one point a document was created in the W3C to state how the browsers support HTML DOM. As HTML 5 progresses we do the same thing here. For now if it is not one of the standard aria or xhtml roles (no namespace required per the proposal) we treat it as a string or we can follow the fallback mechanism below. So, are we making too much of this? Rich Rich Schwerdtfeger Distinguished Engineer, SWG Accessibility Architect/Strategist Chair, IBM Accessibility Architecture Review Board blog: http://www.ibm.com/developerworks/blogs/page/schwer "Anne van Kesteren" <annevk@opera.com To > "Matthew Raymond" Sent by: <mattraymond@earthlink.net>, wai-xtech-request public-html@w3.org @w3.org cc wai-xtech@w3.org Subject> 10/01/2007 06:11 Re: ARIA Proposal AM On Mon, 01 Oct 2007 12:27:52 +0200, Matthew Raymond <mattraymond@earthlink.net> wrote: > So I must ask again: What it the specific problem that |role| is the > sole solution to? Is there even a problem for which it is the /optimal/ > solution? I'm just not seeing the benefit. It's part of the hopefully short-term, stop-gap measure, that provides "afterthought" accessibility for widgets created using JavaScript, HTML and CSS. Given that role= is already deployed, it's unlikely we need that name in the future, and all other attributes that are part of this are scoped using the aria prefix I don't think there's much harm. The only theoretical harm I suppose is that role= is also being defined by the XHTML role module which defines its scope to be much greater than what is being implemented and what is being considered necessary by the stakeholders implementing. In effect, role= is more or less being forked to do its specific accessibility related task. Given that everything under discussion is still in draft form I don't see much problems here. Introducing aria-role besides role just increases the number of options people have to implement unless existing content authors can be convinced to use the new idea instead. If that can be arranged on a relatively short time frime Opera might be able to change its implementation before Opera 9.5 final. It has been suggested that this might be possible for Firefox 3 as well. I believe the requirements of the proposal we're talking about are: 1. The ability to specify a widget type. 2. The ability to specify a fallback widget type in case the widget type is not supported. 3. The ability to specify widget properties. 4. The ability to do this consistently for both HTML and XHTML 5. The ability to also do this for other XML markup (SVG, etc.). Of these 1, 3, 4 and 5 are addressed by Simon's proposal http://simon.html5.org/specs/aria-proposal for ARIA. I would suggest we address 2 by making role= an _ordered_ space-separated list of values where the first value is used or, if it's not supported, the second, etc. If none is supported the element has no widget type. This would enable things like: <div role="aol-buddylist list"> (This fallback proposal is from Henri Sivonen if I remember correctly.) I'm using the CSS extension mechanism syntax above as qnames have serious issues http://lists.w3.org/Archives/Public/public-html/2007Sep/0520.html and only AT vendors will be able to introduce extensions that actually matter to the end user. (Maybe in that light using the prefix aol is a bad example, but hopefully everyone gets the idea.) -- Anne van Kesteren <http://annevankesteren.nl/> <http://www.opera.com/>
Attachments
- image/gif attachment: graycol.gif
- image/gif attachment: pic11579.gif
- image/gif attachment: ecblank.gif
Received on Wednesday, 10 October 2007 14:05:32 UTC