Re: using an attribute to categorize the @alt state [was Baby Steps or Backwards Steps?]

HI Jon,

On Aug 16, 2007, at 4:50 PM, Jon Barnett wrote:

>
> On 8/16/07, Robert Burns <rob@robburns.com> wrote:
>>
>> This is example example where  Ian hasn't even taken his own  
>> advice.  He has
>> rightly suggested that we all focus on problems statements and use- 
>> cases.
>> The changes he's made to the draft certainly reflect an important
>> problem-statement /use-case.  However, the solution fails to  
>> benefit from
>> the WG process.
>
> I don't understand what you mean by this or what you're implying.

I think following Ian's advice, the proper thing to do would be to  
introduce the problem he's trying to solve in the draft (which right  
now has to be gleaned from a careful reading),  and then solicty the  
feedback of this WG. That's an approach that starts from problems  
instead of jumping to solutions.

>
> In case you haven't seen it, this is Hixie's message tot he WHATWG  
> list:
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-August/ 
> 012378.html
> It's just a response to various messages to the WHATWG list, but it
> shows some of the reasons for the latest changes.
>
> As a result, we now have a draft that is a much better starting point
> for discussion than before.

We voted on a document for a starting point and gained consensus in  
the group for a starting point. Its in appropriate to change that  
starting point after that fact. The edits to the draft from this  
point on should reflect the HTML WG. The WhatWG needs to be put on  
the back burner now. We didn't adopt a dynamic WhatWG HTML5 draft  
back in May. We adopted a specific version of the draft. The  
evolution of that draft from that point on should reflect the views  
of this WG. Certainly as a member of the WG, Ian can draw on all  
sorts of interactions and experiences in giving input into the WG But  
as an editor, the changes should directly reflect the discussions  
here and not elsewhere. If Ian doesn't see the types of discussion  
here he wants to see, then he should prod us to start those discussions.

>> I can't think of a good name for this attribute, but consider  
>> something like
>> @embedrel (required) for now (name suggestions welcome). The value  
>> of this
>> attribute would reflect the scenarios identified in the recent  
>> changes to
>> the draft. missing, icon, decorative, seecontext, seefallback. The  
>> value
>> 'missing' would be the default value, unless '@a't had a string  
>> (or perhaps
>> some other contingencies for content backwards compatibility )  so  
>> not
>> setting either @alt or @embedrel would be considered 'missing'.
>>
>
> I am by no means opposed to a new attribute for indicating that an
> image intentionally has no @alt text, i.e. a new attribute to do what
> omitting @alt does now.  The suggestion was @noalt, Maciej has
> mentioned it in a recent message.  If it can be proven that either (a)
> enough UAs treat missing @alt the same as alt="" or (b) enough authors
> omit alt when they really mean alt="", then I'd be in favor of that
> attribute.
>
> However, I don't understand what specific problems these keywords  
> solve.

These keywords are addressed at the same problems Ian's changes to  
the draft are aimed at (at lease as I interpolate the problems that  
haven't been stated explicitly as problem statements). Each keyword  
corresponds to one of the 5 (I dropped email, because I think that's  
a completely different axis than the other scenarios) that Ian lays  
out in the draft. By combining this new @embedrel attribute and its  
keywords with @alt, we do several things: 1) we provide crucial  
information to conformance checkers to actually do their job and  
reflect the intentions of the draft; 2) we continue to place an  
importance on alternative equivalent fallbacks so that authors learn  
that it is important; 3) we provide important information to AT and  
browsers with images turned off (for example deciding whether to  
download an image might be effected by whether its an 'icon' or  
'decorative' or 'seecontext', etc).

> For example, alt="" works well when an image is purely decorative - a
> blind user can ignore it.  alt="" also works well when an image's
> alternate text would just be redundant: <img alt=""
> src="home.jpg">Home - a blind user can ignore it.  What problem is
> solved by using foo=icon or foo=decorative?  I don't see how
> accessibility is served by making the distinction.

Those two are largely the same in my mind (they have subtle  
differences). However, the keywords I defined were built on Ian's  
work on the draft and reflect the 5 scenarios (6 - 1 about email)  
that Ian outlines.

> Why does an aural browser need to distinguish between various roles of
> embedded content?  It's not the aural browser's job to understand the
> role of images - it's the aural browser's role job to replace that
> image with appropriate content by (a) speaking the alternate content
> seamlessly in place of the image (b) saying nothing at all because
> omitting the image doesn't change the meaning of surrounding content
> or (c) saying something to indicate that an image is missing (and
> possibly reading its @title) because that image has no appropriate
> alternate text and cannot be omitted from the document without
> changing its meaning.

For a browser such as lynx, it could let a user know whether its  
worthwhile to bother downloading an image and loading on some other  
device or into some other application. For users of AT, it can let  
them know whether this page has content that will ever be  
decipherable to the user. Should they try to listen or braille read  
the document yet another time. Or is it clear from the keywords (or  
lack of keywords) that this page was just not setup properly for  
their consumption (complaints could be lodged).

I think the relation between these keywords, the default value for  
this @embedrel attribute and the value for @alt provide a nice  
solution to the  problem Ian is trying to address (at least as I  
understand it). We can say that the @embedrel attribute is required.  
Its default value is 'missing' when @alt is missing or set to alt=''.  
So for the following elementt s:

1)  <img>
2) <img embedrel='missing'>

the value of embedrel is 'missing'. These all reflect the important  
information that the alternate for this content is missing. It  
doesn't matter whether an authoring tool couldn't provide the  
information (2), or its simply a careless author (1) or not targeted  
at all to be accessible (2) in an email application. The interesting  
part for the conformance checker or other UA is that and to the user  
is that the information is missing. Its not decorative or an icon  
where comprehending the document or subdocument wouldn't be a  
problem . Its just missing: that part of the document will be  
incomprehensible to the user.

For

1)  <img alt=''>

the default value for @embedrel would be 'decorative'. This would be  
backwards compatible with HTML 4 content for documents that actually  
follow that convention. However, for HTML5 conforming authors and  
editing UAs, the @embedrel attribute provides a much less ambiguous  
approach. With @embedrel, conformance checkers, AT and other UAs can  
distinguish between alt='' that means:

1) decorative (decorative)
2) icon (icon)
3) I'm just trying to get this document  to validate (missing)
4) I made this with a visual editor that threw this on here to make  
it validate (missing)

Those are the important distinctions Ian outlines. However, this  
approach allows us to state positive authoring conformance norms such  
as authors must INCLUDE a @embedrel attribute rather than authors  
must OMIT an @alt attribute. In the latter case its not possible to  
distinguish from sloppy HTML 4 or HTML5 authoring from conforming  
HTML5 authoring.

Take care,
Rob

Received on Friday, 17 August 2007 02:02:39 UTC