W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > January to March 2000

Re: Question about access to ALL content - UAAG 2.1 P1

From: Ian Jacobs <ij@w3.org>
Date: Sat, 25 Mar 2000 15:33:59 -0500
Message-ID: <38DD22B7.90746F45@w3.org>
To: Charles McCathieNevile <charles@w3.org>
CC: pjenkins@us.ibm.com, w3c-wai-ua@w3.org
Charles McCathieNevile wrote:
> 
> I don't think that providing a source view solves the problem. It requires
> the user to understand the markup language being used, which is not
> necessarily the case, and has thus far been explicitly excluded as a
> requirement on the user.

I think it minimally satisfies the requirement of making content
available. We include no specifics about how content must be rendered
(e.g., that alt content for an image be made available inline, in the
same geometric area as an image, a click away from the image, in
a tool tip, etc.). I wouldn't expect a user to have to read through
the encoding of a raster graphic. However, I think that providing
text in a view, even if it's surrounded by markup tags, allows users
access to that information and thus minimally satisfies the
requirement of making (text) content available. I agree that
not all attribute values are useful, but since we don't specify
that only those for humans need to be available to the user (since
it may not be specified clearly in the markup language which are
for humans and which are machines), I think it's "safest" to ensure
that they are all available.

I strongly agree that a source view is not an ideal solution,
however, I think it meets the requirements of a minimal solution
to the issue of availability of text content.

1) When rendered through the user interface, the information has to
be rendered for human consumption (and thus the GIF code doesn't
count, but text as part of a source view would).

2) When made available through an API, we don't care what the
data looks like.

We may need to clarify this.

 - Ian
 
> In addition, there are only some attributes which are actually content for
> the user (title and alt are the main ones but I suspect there are a couple of
> others somewhere). longdesc, most of the attributes for object, name, id, and
> others are relevant to the User Agent but not directly to the user (except as
> a repair strategy for dealing with user agents that don't implement the
> relevant specifications) and exposing this information is not required, nor
> in many cases very helpful.
> 
> In general having the ability to render the source is only relevant to "power
> users" who are able to interpret (and therefore write) the markup language,
> which is a small subset of those who read content. With the advent of decent
> authoring tools this will in fact diminish - how many people can read RTF or
> Word binary format?
> 
> cheers
> 
> Charles McCN
> 
>   pjenkins@us.ibm.com wrote:
>   >
>   > After reading the user agent proposed rec guidelines [1] document and the
>   > associated techniques [2], I have a question about how to interpret the
>   > priority 1 checkpoint 2.1 Ensure that the user has access to all content
>   > ... The techniques [2] give examples about AMAYA's ability to show the
>   > attributes of an element - which is nice,  but more like what I would
>   > expect from an editing tool and environment than what I would expect from a
>   > user agent that majors in rendering content.  But my question is;  -  would
>   > the current technique of rendering the source view of the content meet this
>   > checkpoint?  If not, it needs to be explicitly stated.  If it would be OK,
>   > then the instances for which it would be O.K. need to be stated in the
>   > techniques.
> then On Fri, 24 Mar 2000, Ian Jacobs wrote:
> 
>   I believe that, while not an ideal solution, a source view would meet
>   this
>   requirement. A navigable source view would be better, but still forces
>   people
>   to read the markup, which is not very desirable.
> 
> [more, snipped]

-- 
Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel:                         +1 831 429-8586
Cell:                        +1 917 450-8783
Received on Saturday, 25 March 2000 15:34:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:49:52 GMT