Re: img issue: should we restrict the URI

Guillaume Ludwig wrote:
> Dr. Olaf Hoffmann wrote:
> > object is more a generic element for problematic cases, if nothing
> > else describes the purpose of the content better. Maybe authors
> > have to use attributes like role/class to specify it better.
>
> OK, I agree.
>
> > No, if it has the same functionality than object, authors have
> > the chance to provide alternative content in different formats
> > and if the viewer/user-agent provides an interface, the
> > reader/user may chose what is the best 'display' for
> > the intended purpose and his access to the problem.
>
> Exactly the same way as the object element ? For example we
> have an image, and a text alternative, then an audio alternative ?
>
>
> Guillaume

The proposed new elements like audio, video (canvas?)
have additional functionalities, mainly the idea of an interface.
This needs to be added to this media-element-group to get 
an improved usability compared to the current object.
Ideally in the interface the viewer mentions, which kinds of
media are specified or detected (text, audio, video, graphics, 
maybe the content-type as an indicator too)  to give the users a 
chance to have another choice than the first automatic choice 
from the viewer. Why not to choose an audio alternative for an
image, if the user has some problems with different colours,
just to be sure, that the interpretation of the first choice is 
somehow useful? Ok, typically authors will not have the 
capability to provide a lot of different formats for the same
purpose, but for some critical parts of the content this may
help. Currently this is better done with a simple list of
a elements referencing die different formats directly to
avoid problems with acessibility, but obviously several authors
prefer it to embed content (already indicated by the proposed
new elements audio and video), even if this causes problems.
And typically if I visit a current page with such an embedded content 
like video, audio, sometimes for SVG too, there are of course
already unneccessary technical accessibility problems.
An answer to this problem could be to encourage implementors
somehow to make all possible methods and mechanisms 
available to get access to the information.

For example even if there is just one document in one format
embedded, I often want to see it with another program or
plugin to get the complete information. This is currently 
typically the case for a format like SVG (maybe for an 
advanced container format like MP4 too) - there are some 
programs having only a very basic partial support of this
format, programs supporting only this format (and no (X)HTML,
but maybe indicating additionally document errors, other programs
silently ignore), plugins and maybe alternatives for several purposes 
or general purpose programs with already an advanded interpretation
of SVG. Obviously for a simple company or conference logo 
I'm satisfied with a basic support, for more advanced content
(educational, arts, games etc) I like to switch to get the best
display I can get, depending on my personal experience and the
programs available on my computer. Because I do not want to
extract the information always myself from the page source code,
a user interface to switch would be very helpful to decide, which
method provides best accessibility in my case.
And because the situations are different for any user, restrictions
on possible content or suppression of alternatives by the user-agent
means, that some people will have no chance to see the best
alternative(s) for their purpose, even it the author provides them,
what in indeed is currently often not the case, but already the
existence of an interface to choose something might change
the situation and authors will pay more attention to such a feature,
because suddenly the alternative content gets accessible and
usable for anyone and it gets more 'sexy' to provide different
views on the same issue for anyone.

Received on Friday, 25 January 2008 14:15:52 UTC