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

[Robert J Burns]

On Aug 26, 2008, at 11:46 PM, John Foliot wrote:

> 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.

Actually these are two different cases in the HTML5 draft. What you  
describe here is the case where I apply the 'illustrative' role  
keyword and what the draft calls "a graphical representation of some  
of the surrounding text"[1]. However, what I'm referring to here is  
the section on "A key part of the content" subsection "Images whose  
contents are not known"[2]. Certainly the former should be  
alt='' (though we could also require explicit describedby=IDREF  
association). However, the latter does not need to be permitted by  
HTML5. I don't think we want to encourage authors to include alt='' in  
this case because it will get confused with the legitimate alt=''  
cases, but we could just require authoring tools to leave off the alt  
attribute and generate non-conforming HTML5 due to author error.  
Obviously an author cannot complain about its authoring tools emitting  
non-compliant HTML if the tool gave the author every opportunity to  
conform (as ATAG recommends). Though I wouldn't' be surprised to se  
the WhatWG folks complain about that :-).


>
>> 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)

I saw it. Nicely done.

>> 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?)

I imagine there's many ways to do this. In XML including XHTML (though  
not XHTML5) the role keywords are QNames so each namespace steward  
(such as ARIA, HTML, etc) can designate their own keywords. Ian is  
opposed to QNames because they're helpful for authors, user and spec  
writers other than him, so instead it would have to handled differently.

>> 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.

Its not all that different from alt for the containing image, but I  
feel it is something that would help authors understand the purpose of  
the alt text (though it would have legacy UA issues). So I'm merely  
suggesting:

<a href='aURLRef' alt='privacy policy'  ><img src='aURLRef2' ></a>

instead of the current practice:

<a href='aURLRef' ><img src='aURLRef2' alt='privacy policy' ></a>

The legacy issues alone may make this undesirable, but I feel authors  
would better understand what to do in the first case. Either way I  
think we should get conformance checkers and authoring tools to  
provide clear and specific alt text guidance especially for this case,  
where an anchor contains only an IMG element.

Of course in XHTML2 (and we could do this for both serializations of  
HTML5 as well) the structure could instead be:

<img href='aURLRef'  src='aURLRef2' alt='privacy policy' />

which simplifies this all into a single img link (of course in XHTML 2  
the alt text appears in the element contents, but we cannot do that  
for text/html and Ian for some reason doesn't want that for XML  
serializations either). Since adding attributes to text/html is much  
easier than adding new elements it would be very desirable for HTML5  
to follow the XHTML2 lead of globalizing many attributes.

>> 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.

I tend to agree with you about image slices. Ian has deleted the image  
slice sections from the latest draft, but the table of contents still  
has the sections listed.

Take care,
Rob


[1]: <http://www.whatwg.org/specs/web-apps/current-work/#a-graphical>
[2[: <http://www.whatwg.org/specs/web-apps/current-work/#a-key>