ERT WG -- 05 Mar 2008

Comments on WCAG 2.0 by CarlosI

SAZ: latest WCAG 2.0 Editors Draft available, also a diff version comparing changes to last draft
... also a disposition of their draft responses to the comments received so far
... we should look at the draft responses and check if we may have any follow-up

JK: how do we record test results of Web pages that could be in different states
... for example CarlosI mentioned Ajax and other Web applications
... or in my opinion framesets too
... need to means to record the state of the Web page
... not part of the EARL language itself
... don't see a way to do that

SAZ: framesets a little different scenario from web applications
... usually information is fetched from the server and could be addressed by HTTP-in-RDF

JK: definition of web page in WCAG 2.0 is restricted to non-embedded elements
... so combinations of resources, like in a frameset, would be considered a single web page

[a non-embedded resource obtained from a single URI using HTTP plus any other resources that are used in the rendering or intended to be rendered together with it by a user agent]

JK: content of the individual resources could change

CI: typically a frameset has a single content frame
... don't usually need to cover all combinations of all pages on a web site

JK: agree, but you are interpreting the WCAG WG
... the definition does not address the current *state* of the Web page
... we may not have a mean to record the *state* of a frameset

SAZ: a frameset would cause a sequence of HTTP requests to obtain a combination of [HTML] resources, that together form a "Web Page"
... wouldn't HTTP-in-RDF give you the necessary information?

JK: it would tell you which resources were loaded into the frameset, but would not tell you in which frameset it was loaded
... this could make a difference towards the result of the test
... there used to be xframes extension, not sure if that could be useful

SAZ: seems that we record the interaction with the server using HTTP-in-RDF
... but we don't record the interaction with the user in the browser
... something to identify what action caused an HTTP request or other event
... can we model this? do we want to do this at the current time?

CI: also need to record the context of the frames or web application at the given time
... but not necessary on the EARL (results layer)

JK: agree, don't need the user interaction at the results layer
... but the current state

SAZ: for web applications, would DOM content in the "Content-in-RDF" be sufficient (forgetting frames for now)

CI: it would be, but we don't have a "DOM-in-RDF" model (just a dump currently)

CI & JK: don't have DOM content class

SAZ: could serialize it as XML and dump it into an XML content class?

http://www.rosettacode.org/w/index.php?title=DOM_XML_Serialization

CI: DOM representations may look different depending on user agent

JK: want to record the elements/nodes that we have, to describe how the document looks like
... for example DOM Level 3 has an interface for serializing documents
... problem is converting back from DOM serialization to its original form
... for example an HTML document may generate issues when using an XML parser

<scribe> ACTION: JK send brief document and the serialization of it, to demonstrate DOM usage and recording in XML content [recorded in http://www.w3.org/2008/03/05-er-irc]

<scribe> ACTION: CI & SAZ look more closely at DOM serialization for recording the state of Web applications [recorded in http://www.w3.org/2008/03/05-er-irc]

ERT WG

05 Mar 2008

Attendees

Contents

Comments on WCAG 2.0 by CarlosI

Summary of Action Items