> these examples, but for us, is there a danger that integrating these > examples into wcag will lend the impression that this is a best practice, > when it is actually not? Or, perhaps a clear note on the issue indicating > that aria is reserved for situations when native html is not possible would > suffice. > What say you I believe the Intro to ARIA clearly states: "WAI-ARIA is intended to be used as a supplement for native language semantics, not a replacement. When the host language provides a feature that provides equivalent accessibility to the WAI-ARIA feature, use the host language feature. WAI-ARIA should only be used in cases where the host language lacks the needed role, state, and property indicators." Many forget this and it gets over-used / misapplied when there is no need for it. Browser and AT mmakers (provide varying levels of support and this makes it problematic for users as well as developers and accessibility auditors. Sailesh Panchang spanchang02@yahoo.com Tel 571-344-1765 www.deque.com Yes, interesting point and worth discussion on a call. The issue of native semantics is important default fallback if ARIA is unsupported IMO and I appreciate you concern about codifying what may not be best practice (on the face of it). In the example that you site of using images for buttons - there are none. However devs will do all sorts of 'non-standard' things with markup so it may be good to cover those instances also - in our examples. Thats one of the reasons why I think we should consider the JS library examples (as they refect what devs are doing in the wild). We also face the issue of using ARIA to override native semantics (which according to spec is what should happen) and maybe provide some reference/guidance (like the API doc Steve, Cynthia and Jason put together). Cheers Josh
Received on Tuesday, 24 July 2012 19:40:50 UTC