- From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- Date: Tue, 14 Apr 2009 12:21:00 +0100
- To: public-pfwg-comments@w3.org
L. David Baron writes: > Having semantic markup for these things that is not specific to > assistive technology will lead to benefits for users, including > accessibility benefits. For example, in Firefox, users who have > configured a Windows high contrast theme get by default the Firefox > preference to ignore colors specified by the author. This > preference causes problems with some types of markup where authors > construct their own controls -- the same types of markup that ARIA > is trying to make more accessible. For example, with this > preference set, users are unable to see the selection in a tree > control, since that selection is expressed as an author-specified > color. The ARIA annotations don't help here, but if the tree > control were marked up as an HTML5 tree control, there would be an > appropriate default color for the selected row. I strongly agree this is a significant problem with the sort of DOM ARIA is trying to make more accessible that is largely unsolved by ARIA itself. It is hard to see how many of the examples in the draft could be seen as conforming to WCAG 2.0 in principle or in detail. I think the ARIA spec could do some things to mitigate the problem. Either: A. Demonstrate how one could reject all publisher styles and style an ARIA-annotated DOM. This demonstration would take the form of an informative guide, including CSS where possible. Compare: http://dev.w3.org/html5/spec/Overview.html#rendering This is not as ideal as a world in which publisher styles and user styles can be mixed. It may be someone can come up with a clever way to deliver that world too on top of ARIA, but the loss of publisher styles entire would (I think) be an acceptable fallback position for ensuring accessibility of content and functionality. Or: A1. Warn authors of this problem. A2. Ensure all examples in the spec are be perceivable and operable when rendered without CSS by providing explicit content. For example, "img" elements with "alt" text could replace implied CSS background images. It may be that the first approach is suitable for some ARIA features, and the second approach for other ARIA features. It is unlikely both approaches are suitable for a given feature, since user agent/user styles would probably conflict with explicit content. -- Benjamin Hawkes-Lewis
Received on Tuesday, 14 April 2009 11:21:43 UTC