W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > April to June 2004

Re: 1.1 suggestion

From: David Woolley <david@djwhome.demon.co.uk>
Date: Fri, 4 Jun 2004 22:16:27 +0100 (BST)
Message-Id: <200406042116.i54LGRR02310@djwhome.demon.co.uk>
To: w3c-wai-ig@w3.org

>  this summarizes several open 1.1 issues and, imho, addresses some of

This may only accidentally be public, but....

> 1. For content that is not syndicated from an outside source, e.g. ads,

I think the above is giving advertisements as examples of content
syndicated from outside source, but it actually reads as though they
are not so syndicated.  (Many would not consider adverts to be content.)

> 	*	For non-text 'resources' that have iconic or functional
> use a text alternative must be provided which details the function of
> the element.  

I don't think this should say details; one of the authoring failure
modes for alternative text is to provide too much, and this encourages
excessive detail.  (This happens when authors are providing the text 
for legal reasons, not because they are really thinking about it.)

> 	*	For non-text 'resources' that encode specific
> information in a non-verbal form a text alternative must be provided
> which presents the encoded information verbally.

One of the meanings of "verbal" is spoken spoken (second definition
in the Concise Oxford Dictionary), I think you mean "using words".
The function of iconic elements is also often to provide branding by
using a common theme; users generally won't want to know about that theme
when viewing in text or speech, but details of the function would imply
describing this function as well as the function performed by the control.
It could also be misunderstood for text as graphics - some people might
consider such to be textual resources.

> 	*	For non-text 'resources' which encode no specific
> information, but are intended to create a sensory experience, a text
> alternative must be provided.  This text should convey what the resource
> is, and what relevance the resource has to the rest of the content if
> any.

This will be very difficult to comply with for most commercial
web sites as one of the main reasons for doing this is to imply an
association between the product and something desirable where no such
association exists[2], objectively.  In the UK, at least, unsubstantiated
claims in the text can get the advertising banned, but unsubstantiated
associations in the graphics will normally (although not always[1]) get past
advertising standards type bodies.  I'm treating the primary content
as advertising here, which is often the case.  Where it is a loss leader,
it is still often the case that illustrations aren't really correct for
the content.

The only real solution for this for the content author is to provide
a text only version of the whole that uses a more literal style
(metaphor) to carry the deniable part of the message.

> 
> 2. Syndicated content must not:
> 	*	Flash screen reader readable text or otherwise altering
> text stream
> 	*	Spawn pop up windows
> 	*	Steal or keep keyboard focus
> 	*	Refresh content

I would want to add:
        *       Pretend to be part of the non-syndicated content
        *       Mimic the appearence of user interface element so as
                to lead users to believe the elements are real
> 
> Level2 Success Criteria for Guideline 1.1:
> 1. All content including syndicated content must conform to level one
> conditions.
 
 
[1] There are exceptions, e.g. people in advertisements for alcohol have
to appear to be at least 26, I think.

[2] Even where there is some association, it quite often erroneous, e.g.
the UK railways authority recently got caught out using a picture of
German railways on the cover of a document, because the agency that
produced it used a stock photo without thinking about it, and long long
ago, in the days of 8080 microprocessors, the business microcomputer
software part of the company I worked for produced a brochure with a
large photograph of the, even then, near obsolete 4004 microprocessor
on its cover.
Received on Friday, 4 June 2004 17:17:35 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:13:33 UTC