Re: css3-selectors Summary of Comment

On Thu, 7 May 2009, Tab Atkins Jr. wrote:
> On Thu, May 7, 2009 at 7:02 PM, Janina Sajka <janina@rednote.net> wrote:
> > 
> > Hover, active, focus:  All elements should be able to take those 
> > states. Any element that receives focus should be able to make use of 
> > those. With ARIA and with HTML 5, any element can be focusable. 
> >  Before that, form elements and buttons are also focusable.
> 
> CSS has no say on whether elements match these classes; it's entirely up 
> to the document language.  The CSS engines just need to know what the 
> document language wants.  As long as HTML5 and ARIA play nicely together 
> in this respect, we're great.

This is the relevant text in HTML5:

   http://www.whatwg.org/specs/web-apps/current-work/#matching-html-elements-using-selectors

Once ARIA is integrated with HTML5 (which is pending on getting the 
implementation requirements pinned down and having the ARIA spec address 
the last call comments [1]), I would be happy to add to that section the 
relevant ARIA states if that is the technically correct things to do.

Having said that, it seems like having the ARIA attributes affect selector 
matching runs counter to the principles behind the ARIA design. Surely if 
ARIA is to be treated as an accessibility API, it should not affect lower- 
level layers like CSS. Otherwise, what should happen if the ARIA-level 
accessibility API semantics conflict with the actual semantics of the 
language? It would be like ARIA affecting the form submission or form 
validation requirements in HTML, or changing the way graphics are rendered 
in SVG.


[1] In particular, those listed here:
http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/thread.html

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'