Re: unifying alternate content across embedded content element types

On Jul 15, 2007, at 9:24 PM, Andrew Sidwell wrote:
>
> Robert Burns wrote:
>> The issue I'm raising is not about that situation. Its about the
>> situation when <object> contains long rich text. How then will a UA
>> provide an @alt like rendering of that lengthy alternate text?
>
> I think that gets to the root of the issue, and now we have a problem
> statement: "It is unspecified how to find or create shortened fallback
> text for the <object> element."

Thank you. I'm so delighted to hear some one echo back to me what  
I've been saying. I've tried to say this in many different ways with  
no luck. I hope this echos with someone else otherwise its just  
increments to a lunacy of two :-). This may be part of a larger issue  
of how to tighten the handling of fallback by UAs. And in this case,  
I mean all UAs that present content aural, tactile and visual.

> The first thing to find out if UA vendors want to do this.  If they
> don't, then it's fairly pointless discussing how to.

I don't think this recognizes the current state of the WG and the UA  
development environment. Many vendors cannot talk about future  
enhancements. Of those who can, most of them are part of open source  
projects and cannot definitively speak about future enhancements  
because these are a part of  large and relatively decentralized  
community project. So I think it might be interesting as an informal  
poll. It is only an interesting bit of trivia that we can glean from  
that however. So you're welcome to pursue that, but I think it would  
make more sense to first get more discussion going from members of  
the WG on what sorts of conformance criteria we may want to include.  
Obviously this could be based on some shining examples among existing  
implementations.

> Of those that do want to provide alt-like rendering, some may already
> have an algorithm set up to produce such text.  That may be  
> suitable for
> inclusion into the specification, or it may be a point for UAs to
> compete on, and thus not be suitable for standardisation yet.

Yes, that would be interesting to learn. It would also be interesting  
to see how such an algorithm would handle diverse scenarios. Of  
course the advantage of bringing such an algorithm into our  
recommendations is  it would allow us to define authoring criteria to  
help tighten, support, and complement that algorithm.

> Then some background info might be useful, e.g. how many pages with  
> <img
> alt="" longdesc=""> actually contain meaningful info in both  
> attributes.
>  This would be useful because it tells us how useful a new  
> attribute or
> element is likely to be other places where two equivalents are  
> allowed.

I'm not sure how what data like that would tell us. Keep in mind our  
resources to perform any rigorous scientific surveys are likely quite  
limited. However, if you're interested in pursuing something like  
that, you should first think about what hypotheses your trying to  
establish or rule out. Its hard for me to think of what you're trying  
to do here, but you would definitely want to put this  in the form of  
a hypothesis or a list of hypotheses before expending a lot of time  
or money on it. My sense is empirical research on these things might  
be unfruitful. On the other hand, we might find an abundance of  
library research materials that could answer key questions for us.

In addition, I think we all know that support for these features has  
been very slow in coming: even within screen readers. Authors too,  
have been slow to use these features in part because they do not work  
well or consistently in UAs. It is a vicious  circle.. As with any  
feature that works inconsistently across UAs it is often of limited  
usefulness. A big part of my motivation — and I imagine many others  
anxious to see a new HTML recommendation — is that I want to see  
better guidance on these issues for UAs so that in the future,  
authors will be able to make use of those features.

Putting that guidance in our recommendation, provides a goal post for  
UA developers to aim for. It provides a way standard to support bug  
filing (for both commercial and open source engines).

> BTW, how does one actually talk to the accessibility UA vendors?  It
> would be nice to have somewhere where the HTML-WG could go to ask  
> people
> who know what they're talking about on such matters.

Though I do not know him personally, I had invited the creator of  
Fire Vox to join in the WG (I don't know what became of that; I  
hadn't followed up). IBM, Microsoft, and Apple are all vendors who   
make screen-reader or screen-reader-like products and have some  
presence on our WG.  Is Freedom Scientific on our WG or involved with  
any other W3C endeavors? Someone else mentioned a Firefox extension  
that provides @longdesc support. Perhaps we could invite the makers  
of these and other products to participate.

I thought perhaps a wiki page for collecting together information on  
UAs would be useful.  You'll find it here:

<http://esw.w3.org/topic/HTML/UAsL

I put this together rather quickly and in no particular order, so  
there are likely errors. Everyone is welcome to add and rearrange the  
contents.

Take care,
Rob

Received on Monday, 16 July 2007 07:29:39 UTC