Re: Using ARIA to override semantics

On Mon, Mar 21, 2011 at 1:46 PM, Steve Faulkner
<faulkner.steve@gmail.com> wrote:
> thanks tab,
>
> that doesn't happen and agree it shouldn't happen.
>
> aren't the CSS hooks based on the tag/attribute names etc in the DOM?

No. The specs defer to the host language and says things like:

"The document language determines which elements are hyperlink source
anchors" [1]

and

"What constitutes an enabled state, a disabled state, and a user
interface element is language-dependent" [2]

So if ARIA can be argued to be part of the host language, which I
think is the case here since HTML5 explicitly supports ARIA, then we
need to define if ARIA affects the elements such that they are
considered links/enabled/etc in the relevant contexts.

[1] http://www.w3.org/TR/CSS21/selector.html#link-pseudo-classes
[2] http://www.w3.org/TR/css3-selectors/#enableddisabled

> you can have styles associated using the aria attribute names, but
> that has nothing to do with their function only that they are
> recognised bits in the DOM right?

Correct.

> so you can do
> a[role] {
> color : red ;
> }
>
>
> but that is no different from doing
>
> a[hreflang] {
> color : blue ;
> }
>
> the semantics of the attribute makes no difference right?

Correct.

> or is use of role/aria-* soemthing that should not be allowed?

No, I don't see a reason to special-case these attributes here.
Attribute selectors should work directly on the DOM, without reading
any semantics into them. That makes for simpler and saner use as well
as implementation.

/ Jonas

Received on Monday, 21 March 2011 21:52:21 UTC