H Ben > I think the more serious compatibility problem with ARIA is the immaturity > and rapid pace of change of the draft specifications and implementations.
The ARIA spec is expected to go to "last call" end of february, so the spec will be pretty stable by this point. From my understanding the stability of the spec in regards to landmark roles, there will be no further changes, so their use can be recommended. As fas as implementations go the same message applies. 2009/1/21 Benjamin Hawkes-Lewis <[email protected]>: > On 20/1/09 23:13, Anthony Ziebell wrote: >> >> because an implementation of ARIA without using >> JavaScript to do so would essentially mean a drop of support of legacy >> browsers > > If all you are doing is adding some unrecognized ARIA attributes to > _existing_ HTML or XHTML content, then such attributes are (realistically) > not going to harm users of legacy browsers. > > Some aspects of ARIA (such as "tabindex" for all elements and negative > values of "tabindex") were implemented in some older browsers, even though > invalid in HTML 4.x and XHTML 1.x, long before ARIA was proposed. > > In so far as new assistive technology performs any DOM inspections for ARIA > attributes in legacy browsers (probably not much), the presence of ARIA > attributes might help users of those combinations. > > So long as you continue to use the same HTML 4.01 or XHTML 1.x elements to > mark up the same content, I don't understand why the additional inclusion of > ARIA attributes (say, landmark roles) should make any difference to "support > of legacy browsers". > > For example, if you enhanced a document with you a "Skip to main content" > link by additionally marking up your navigation area with role="navigation" > and your main content area with role="main", the net effect of adding ARIA > attributes on backwards compatibility could be positive. > > I can see a conflict with backwards compatibility if you let the presence of > ARIA attributes change how you author your content. For example, if you > _replaced_ a "Skip to main content" link by marking up your navigation area > with role="navigation" and your main content area with role="main", you'd be > replacing a technique that works for a given set of older user agent > software with a technique that works for a given set of newer user agent > software. In that scenario, the net effect of adding ARIA attributes on > backwards compatibility could be negative. > > Similarly, if you depended on ARIA to communicate semantics available in > existing (X)HTML (say replacing "h2" with "div role='heading' > aria-level='2'") or if you introduce new semantics/functionality > communicable with ARIA but not existing (X)HTML are essential to > understanding/using your content rather than an enhancement , you'd lose > backwards compatibility for your content. > > So as you can see, progressively enhancing with ARIA doesn't equate to > adding ARIA attributes with JavaScript, but rather to using ARIA as an > enhancement rather than replacement whether dependent on JS or not. > > I think the more serious compatibility problem with ARIA is the immaturity > and rapid pace of change of the draft specifications and implementations. > > -- > Benjamin Hawkes-Lewis > > > ******************************************************************* > List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm > Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm > Help: [email protected] > ******************************************************************* > > -- with regards Steve Faulkner Technical Director - TPG Europe Director - Web Accessibility Tools Consortium www.paciellogroup.com | www.wat-c.org Web Accessibility Toolbar - http://www.paciellogroup.com/resources/wat-ie-about.html ******************************************************************* List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [email protected] *******************************************************************
