W3C home > Mailing lists > Public > public-wai-ert@w3.org > March 2005

Re: Locating the subject and dynamic content

From: Nils Ulltveit-Moe <nils@u-moe.no>
Date: Wed, 23 Mar 2005 13:08:15 +0100
To: public-wai-ert@w3.org
Message-Id: <1111579695.18246.101.camel@moe-ulltveit-moe.com>

Hi Carlos

My opinion is that it is not wrong to use fuzzy pointer/xpointer to
point out where the fault occurred.

However, I think accessibility monitoring tools that identifies a
temporal/intermittent accessibility problem on a page, would have to
store a copy of the page together with an EARL assessment report of the
page, to be able to show how the page really looked when the fault
happened. Otherwise the fault would be impossible to trace.

Of course, a combination of line number of the cached document, and the
URL it had when it was assessed would work as well.

Mvh.
Nils Ulltveit-Moe


ons, 23,.03.2005 kl. 12.41 +0100, skrev Carlos Iglesias:
> Hello all,
> 
> I'd like to clarify my opinion (that in deed is the TAW Team opinion) about locating the subject and dynamic content.
> 
> When I said that the big one problem is the dynamic content, which is actually most of the web content, I am thinking about the "real" location of the problem not about content that changes dynamically, so the problem I'm talking about is not the persistence of the content but the "origin" of the problem. 
> 
> The best reason I imagine to have a location or reference to the problem is to use it for some repair actions, but with the proposed solutions we are offering an "imaginary" location of the problem which is almost useless for this objective. 
> 
> For example:
> 
> Imagine that finally we found a properly way to locate the test subject, fuzzy pointers, xpointers or whatever, that looks like a good solution for everybody. The problem is that you are locating something that is not the "real" problem, you are locating the problem at a web page which is served by a server, but the "real" problem is located anywhere inside a huge amount of ASP, JSP or whateverSP you use, databases, etc.
> 
> A good simple dynamic example could be the images rotator attached (a way to see an image in a page that is different every time you reload the page). There are three files:
> 
>  Images.ini --> a configuration file that includes src, title, and alt attributes  
>  Index.php --> the web page that includes the rotator  
>  Rotator.php --> the php code needed to make the rotator effect
> 
> When you have the rotator in action (the index.php served) you have an xhtml page which shows a different image each time. If there were no alt text for the image you have an accessibility problem that you could locate in the served page, but if order to repair this problem, are you going to repair this served page?
> 
> 
> Well, on every TAW release we have made ourselves the same question "What could be this (a location to the problem in the served page) useful for?" and we think that is only useful for educational purposes, or as a help for seeing the problem in its context.
> 
> So, in my opinion again, there are two dynamic content related problems:
> 
> - Monitoring a Web site over time (This is the 5th scenario at the Johannes document [1]) In this scenario dynamic content is a problem, and some kind of persistent location to the problem could be useful.
> 
> - Fixing problems
> In this case, a reference to the problem at the web page is not valid because if you want to fix the problem, you will need to fix the JSP, ASP or whatever, which is the "real source" of the problem.
> 
> 
> My conclusion is, is really necessary to add a complex pointer to the subject of a problem to the specification? Or maybe a simple pointer, like line numbers, could be enough.
> 
> I think that we need to think about this question before continuing the locating discussion, specially because in the last teleconference Shadi talked about some reflections on EARL from CSUN [2] and one of them is that tool developers are not yet convinced of using EARL, and I think one reason is that EARL is RDF, a not well know technology that seems complex, and if we add more unnecessary complexity to the specification, with xpointer, fuzzy pointers or so on, it could be a barrier for the wide use of EARL.
> 
> [1] [http://lists.w3.org/Archives/Public/public-wai-ert/2005Mar/0048.html]
> [2] [http://www.w3.org/2005/03/22-er-minutes.html#item01]
> 
> Sorry for the big message, I'm waiting for your opinions.
> 
> Carlos.
> 
>  
> --------------------------------------
> 
> Carlos Iglesias Moro
> 
> Fundación CTIC
> Parque Científico-Tecnológico de Gijón
> 33203 - Gijón, Asturias, España
> 
> teléfono: +34 984291212
> fax: +34 984390612
> email: carlos.iglesias@fundacionctic.org
> URL: http://www.fundacionctic.org
-- 
Nils Ulltveit-Moe <nils@u-moe.no>
Received on Wednesday, 23 March 2005 12:06:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:25 GMT