RE: ACTION: Locations for the test samples

 

Hi Shadi, everybody.

> I think the location of the error depends on what has been 
> tested and must therefore be specified by the test procedure. 
> Here are two scenarios I am thinking of:
> 
> SCENARIO 1: The test is carried out on the script code and so 
> the location of the error will be in the source files; the 
> source files must be specified by the test sample, the 
> generated content is unimportant.
> 
> SCENARIO 2: The test is carried out on the executed code and 
> so the location of the error will be in the generated 
> content; the exact execution parameters must be specified by 
> the test sample.
> 
> If this type of information about carrying out the test is 
> not part of a test procedure, than we should send this as a 
> bug report to the WCAG WG.

Based on the WCAG 2.0 techniques document [1], we have:

A - Common failures --> some times the location should be in the (X)HTML files, sometimes in the CSS files, sometimes (mainly when the applicability is "all technologies") is not clear.

B - Client-side scripting techniques --> the location should be in the client-side scripting files (source file)

C - CSS techniques --> the location should be in the CSS files

D - General techniques --> the same as with "A - Common failures"

E - HTML techniques --> the location should be in the (X)HTML files (but I think that in the generated content, not the source)

F - Server side techniques --> the location should be in the source code (not the generated content)

G - SMIL techniques --> the location should be in the SMIL files

H - Plain text techniques --> the location should be in the plain text documents


[1] - [http://www.w3.org/TR/WCAG20-TECHS/]

Regards,
 CI.

 
--------------------------------------

Carlos Iglesias

CTIC Foundation
Science and Technology Park of Gijón
33203 - Gijón, Asturias, Spain 

phone: +34 984291212
fax: +34 984390612
email: carlos.iglesias@fundacionctic.org
URL: http://www.fundacionctic.org




> > 
> > Hi everybody,
> > 
> > Comments inline:
> >  
> >> I would like to start thinking on that problem looking that from 
> >> different stakeholders point of view:
> >>
> >> Evaluation Tool Developers: For tools aiming at just evaluating 
> >> rendered pages I don't think source pointer would be useful. 
> >> Regarding tools that aiming at source code level (don't know any 
> >> yet!) such an info could be useful.
> >>
> >> Authoring Tool Developers: Same applies here.
> >>
> >> User Agent Developers: Don't care about server-side probably care 
> >> about js.
> >>
> >> Web Content Developers or even for education purposes: 
> Both pointers 
> >> would be useful.
> > 
> > Totally agree.
> > 
> >> Test case authors (;)): Might be difficult to point to 
> rendered page 
> >> (must setup server). More overhead having both pointers.
> > 
> > It's suppossed you (or the TF) need to test the test cases 
> at some point, so you need to setup a server anyway.
> > 
> >>>> As you can see, in example sc2.5.1_l1_003 the locations
> >> refer to the
> >>>> server-side language (JSP in this case) not to the interpreted 
> >>>> content (what an user agent gets).
> >>>> (...)
> >>>> This is obviously a problem that increases when you use
> >> server-side
> >>>> languages in an extensive way, and raises the following question:
> >>>> Should the location pointers refer to the source language
> >> or to the
> >>>> interpreted content?
> >>>>
> >>>> IMO the locations should at least refer to the interpreted
> >> content,
> >>>> because it's the content all user agents get (most E&R tools 
> >>>> included), and it's the only thing you have when you can't
> >> access to
> >>>> the files at the server.
> >>> I agree that this is a problem, but I don't know how to solve it.
> >>> Pointers into the generated code can't always be given if
> >> the server
> >>> response depends on form input, for example. If we want reliable 
> >>> pointers into generated code that depends on form input (or
> >> on other
> >>> parameters, such as those used in content negotiation, that
> >> are used
> >>> at the server side to generate the response), I don't see
> >> how we can
> >>> do that without pulling some of the HTTP in RDF 
> vocabulary (already 
> >>> used in the 'files' element in TCDL) into the location
> >> element. It is
> >>> probably feasible, but it is much more work for test case
> >> authors than
> >>> just pointing into the source code of the test samples. 
> Is that the 
> >>> way to go? Any other solutions?
> > 
> > I agree that is such cases (e.g multiple request-response) 
> it could be much more work, but I think the question is, do 
> we need that "extra" work?
> > 
> >> I think that in case of server-side scripting in the 
> context of this 
> >> task force we could probably simplify things. In real 
> scenarios the 
> >> uncertainty of user/agent input/request cannot be predetermined so 
> >> the generated markup cannot be predicted so that we can set the 
> >> pointers.
> >> Fortunately ;), in case of test samples IMO everything could be 
> >> strictly predetermined, even the user/agent input/request.
> > 
> > Also agree.
> > 
> >> Now, regarding the different ways of rendering (mentioned in
> >> teleconf) we could probably assume a default (w3c) rendering and 
> >> probably document that somewhere. Alternatively we could 
> rely only on 
> >> XPath (or
> >> XPointer??) location.
> > 
> > We may also have problems using Xpath (or Xpointer) in non-XML 
> > content. Are we going to restrict test samples to xhtml 
> language? What 
> > about other non-XML contents? (CSS, JS...)
> >  
> >>> Also, if pointers are based on generated code, how do we 
> point into 
> >>> DOM structures generated by client-side scripts?
> > 
> > Maybe we need generated content pointers in same cases, 
> both types of 
> > pointers sometimes, and probably never only the source 
> pointers (see 
> > the explanation about different use cases at the beggining)
> > 
> >>> If we point into the author's source code for test files with 
> >>> client-side script, and into generated code for test files with 
> >>> server-side script, do we have a consistency issue? (Note
> >> that a test
> >>> sample can use both server-side and client-side script.)
> > 
> > I think that there is not consistency issue if this is the 
> rule we decide to follow and we document it.
> > 
> >> [..] On the other hand,
> >> during last teleconf we decided not to include any script in 
> >> testfiles. So if we want to point to js source how we do? Are we 
> >> allowed to point to files outside testfile or should we 
> consider that 
> >> as "generated inline"?
> > 
> > Js, css... files are also test files, but we need something 
> to associate each point with each testfile.
> > 
> >>>> So, I think the only feasible options we have are:
> >>>>
> >>>> A - Use locations only for the interpreted content.
> >>>> B - Use both locations, for the original code and the
> >> interpreted code
> >>>> at the same time.
> >>> C - Use locations only for the source code - is also a *feasible* 
> >>> option.
> > 
> > C option looks only "feasible" for the use case of E&R 
> tools that aim at the source code level (see the use cases 
> explanation at the begining), if there is any of them.
> > 
> >> The problem is not feasibility but
> >>> interoperability/compatibility of location pointers (or
> >> whatever you
> >>> want to call it) with evaluation and repair tools.
> > 
> > I think there is not such a interoperability/compatibility 
> problem, depending on the use case you will need one class of 
> pointers or the other.
> > 
> > Regards,
> >  CI.
> > 
> >  
> > --------------------------------------
> > 
> > Carlos Iglesias
> > 
> > CTIC Foundation
> > Science and Technology Park of Gijón
> > 33203 - Gijón, Asturias, Spain
> > 
> > phone: +34 984291212
> > fax: +34 984390612
> > email: carlos.iglesias@fundacionctic.org
> > URL: http://www.fundacionctic.org
> > 
> > 
> 
> -- 
> Shadi Abou-Zahra     Web Accessibility Specialist for Europe |
> Chair & Staff Contact for the Evaluation and Repair Tools WG |
> World Wide Web Consortium (W3C)           http://www.w3.org/ |
> Web Accessibility Initiative (WAI),   http://www.w3.org/WAI/ |
> WAI-TIES Project,                http://www.w3.org/WAI/TIES/ |
> Evaluation and Repair Tools WG,    http://www.w3.org/WAI/ER/ |
> 2004, Route des Lucioles - 06560,  Sophia-Antipolis - France |
> Voice: +33(0)4 92 38 50 64          Fax: +33(0)4 92 38 78 22 |
> 
>

Received on Tuesday, 16 January 2007 09:14:07 UTC