[html4all] @role values & comments (was RE: alt attribute applied to other elements)

[John Foliot]

Robert J Burns wrote:
 
> So Ian has basically returned the draft to the original state that
> raised so many objections. For images where the author doesn't want to
> provide alt text she need not provide alt text: or as Ian is so fond
> of calling the willful omission of alt text: "Images whose contents
> are not known". Except now in addition to requiring such images to be
> wrapped in a figure element with some text, he now also permits a
> title of the image to replace the alt text using either the title
> attribute or the a heading element.

Rob,

I think we need to also be pragmatic here: if an image has sufficient
textual information surrounding it, and that information is directly linked
to the image, but there is no "alt" value, we have to accept that sometimes
this is the best we are going to get.  It is not "deprecating" @alt, but
simply accepting that yep, sometimes we're gonna get nothing, and now at
least we have a spec that says that even when there is no alt value/content,
that there must be something else "specifically" on the page to be
conformant.  Water with the wine I'm afraid.


> 
> Again his only goal seems to be to introduce a loophole so that
> basically alt does not show up in conformance checkers (since the
> conformance checker cannot possibly differentiate these cases from all
> others and therefore cannot flag any IMG omitting the alt attribute as
> an error).

See my response to Ian's note.  I think we should still push for a mandatory
@alt for "code purity" but accept that oft time the value will be alt=""
(which does nothing but satisfy the conformance checker - certainly is of no
use to the non-sighted)


> 
> The HTML5 draft covers 10 worthwhile cases[1]. They are (with proposed
> role keywords[2] in parentheses):
> 
>   . link  - required
>   . charts, etc.(chart, diagram, geomap) - required
>   . icons and logos (icon, logo) - required
>   . text (text, mathexpr, musicscore) - required
>   . Illustrative of the nearby text (illustrative) - null required
>   . Decorative (decorative) - null required
>   . image that is part of a larger sliced image - ?
>   . image that is part of a larger sliced image with links - ?
>   . either a key part or \the\ key part of the content - required
> except now we're back to the not required if the author doesn't want
> to bother
>   . img hacks

Not to go too off track, but I really like those proposed @role values.  Is
this something collectively we should expand upon?Should we put forth a
formal proposal to "entrench" these values into the spec, or should they
simply remain external to HTML 5 but elsewhere defined? (As I recall, @role
values, at least back when I was looking at @role in context of XHTML2, can
be defined using RDF, so would these roles be something that would live
within WAI space?  I do not know - perhaps Chaals could shed some
light/thoughts?)

> 
> However, there are two other cases that I think suggest alt should be
> permitted elsewhere. The first case of a link (and I've brought this
> up before) is where the author provides alt text to describe where a
> link will take the user. To me this belongs on the A (anchor) element
> and not on the image. I think it is easier for authors to understand
> on the anchor than on the IMG. Also it may be that the IMG element
> needs descriptive of the image alt text while the link needs alt text
> descriptive of the link destination. Finally, I think it would be easy
> for conformance checkers to alert authors of the needed alt text
> whenever an anchor fails to contain significant text either in its
> contents or in its alt attribute.

Hmmm... I can see some possible value here.  Robert, how do you see this as
being different that providing @title to the anchor element?  @title is for
"advisory" information, which as I read it is what you are talking about.

> 
> The other case is that of image slices. Personally, I think client-
> side image maps might be a better technique than image slices for the
> use case, but when authors do use image slices I think we should
> require the element containing the slices (perhaps a DIV or a TABLE)
> also accept the alt attribute. I suppose for TABLE the summary
> attribute could be used (if we're keeping it), but the alt attribute
> would be better since it could be used automatically without querying
> like the summary attribute (and it could also be either a table or a
> div that contained the image slices).

Personally, I am less keen on this.  I think that we should be discouraging
"image slices" rather than promoting them and "enhancing" them.

JF