RE: question about the draft:

> -----Original Message-----
> From: public-html-request@w3.org [mailto:public-html-request@w3.org] On
> Behalf Of Smylers
> Sent: Tuesday, August 05, 2008 1:46 AM
> To: public-html@w3.org
> Subject: Re: question about the draft:
> 
> 
> Justin James writes:
> 
> > > -----Original Message-----
> > > From: public-html-request@w3.org [mailto:public-html-
> request@w3.org] On
> > > Behalf Of Ian Hickson
> > >
> > > > If this assertion is true, why do you need "an appropriate HTML
> > > > element" when you can create a nonce-element using the very
> > > > techniques you have proposed ?
> > >
> > > A "nonce-element" doesn't help screen readers. Screen readers only
> know
> > > real HTML elements, they don't know about the inventions of the
> author.
> > > Extensibility solutions don't help accessibility.
> >
> > They do, *if* we provide a mechanism to tie semantics/accessibility
> to
> > the class.
> 
> For that to work there'd have to be a set of semantics that all
> browsers
> implement, that authors can choose to associate classes with (otherwise
> nothing Ian puts in the page could possibly convey the semantics
> required).

Yes, I agree. I think that the existing "semantic element set" would be a
good start, and I think that the aria-role stuff already covered it pretty
well.

> We already have such a set of semantics that browsers can convey;
> there's a separate HTML element for each one.

Yup, exactly correct.

> If we discover additional semantics that authors need, what would be
> the
> advantage in merely adding them to a list which authors could tie to
> generic elements, rather than us creating a specific named element for
> each one?

It is not that we would be discovering new semantics per se (I think the
existing list, as representing by existing elements, is more than sufficient
to start with). The idea is to be able to assign semantics to tags,
particularly "generic" tags like div, span, img, etc. For example, many
images are used as checkboxes, buttons, and other form widgets, but looking
at the HTML, there is no way for the UA/AT to really "get" that. Another use
case is the contentious "legend" draft. I think that this could replace that
completely and simultaneously address the content/presentation separation
problem that (I believe) exists in the current draft.

Jumping the gun a bit before I can make this a real proposal, imagine:

.imageCheckBox {
   aria-role: checkbox;
   state: checkbox-checked;
}

<img class="imageCheckBox" src="checked.gif" onClick="javascript:this.state
= !this.state; if (this.state == checkboxchecked) {this.src =
'checked.gif';} else {this.src = 'unchecked.gif'}" height="50" width="100"
alt="Clicking this image toggles the value of the field." />

The effect this would have, is that when the img is bound to the
imagecheckBox class at run time, it adds in the properties, methods, etc.
associated with the checkbox role (such as a "state" property indicated if
it is checked or not), much like implementing an interface in an OO
language. From there, it is pretty darned easy for a UA/AT application to
make MUCH better usage of the document! It also allows non-browser UA's to
do the same things with these generic fields that they've been doing with
semantic fields for quite some time. The real beauty of it is that it would
use a syntax and concept that most developers are already familiar with
(CSS), and applies it to a totally new direction, while furthering the
separation of responsibilities.

J.Ja

Received on Tuesday, 5 August 2008 06:27:10 UTC