Re: fear of "invisible metadata"

To clarify where I stand on this.
I do not want alt removed. I just don't want it _required_.

On 6/22/07 7:36 PM, "Robert Burns" <rob@robburns.com> wrote:
>> Finally, we should provide some of the same detailed processing algorithms
provided throughout the rest of the HTML5 draft for UAs for handling this
fallback content. Obviously nothing compels the implementers from following
these directives, but at least there's a milestone to frame the dialog.

I'd like to define in the spec that
<figure>
 <legend><legend>
 <img>
</figure>
should be treated similarly to alt.

This way there's less repetition of the same text and I strongly prefer the
concept of figures accompanying an article over just having a bunch of img
tags floating around. For someone to consciously choose to use <figure>
likely means anything within that figure is informative and not decorative.

Yes! There will still be times when an img used within a figure still needs
an alt value!

I also wish I could demand that browser devs alter the way they display
tooltips.
* wrap text every 30 characters
* display the tool tips for 1.5 seconds longer than they do now.
* add an extra half second of display time for ever wrapped line of text
* make the appearance of the tooltip box accessible to css
...possibly other stuff.




>> The <img> element is more complicated than the other media elements for
whatever reason. One way to fix this might be to make the <img> element not be
defined as a canonically empty element. Or if we have concerns about namespace
conflicts to add an <image>  element and deprecate the <img> element.  This way
a new <image> element could have the same fallback facilities as all of the
other media elements. However, for backwards compatibility we should maintain
the traditional <img> element and its @alt and @longdesc attributes.


I think I'd like an <image>


>> Finally, we should provide some of the same detailed processing algorithms
provided throughout the rest of the HTML5 draft for UAs for handling this
fallback content. Obviously nothing compels the implementors from following
these directives, but at least there's a milestone to frame the dialog. In other
words the implementors will be able to understand the intention behind the spec
and whether their users will benefit from the proposed features.


like others on this list have said, a big part of the problem is that
assistive tech/user agents suck really bad in some areas and have sucked for
a very long time.

-- 
::   thyme online ltd
::   po box cb13650  nassau  the bahamas
::   website: http://www.thymeonline.com/
::   tel: 242 327-1864  fax: 242 377 1038