Fwd: Your comments on WCAG 2.0 Public Working Draft of May, 2007

Dear Charles McCathieNevile,

Thank you for your comments on the 17 May 2007 Public Working Draft of
the Web Content Accessibility Guidelines 2.0 (WCAG 2.0
http://www.w3.org/TR/2007/WD-WCAG20-20070517/). The WCAG Working Group
has reviewed all comments received on the May draft, and will be
publishing an updated Public Working Draft shortly. Before we do that,
we would like to know whether we have understood your comments
correctly, and also whether you are satisfied with our resolutions.

Please review our resolutions for the following comments, and reply to
us by 19 November 2007 at public-comments-wcag20@w3.org to say whether
you are satisfied. Note that this list is publicly archived. Note also
that we are not asking for new issues, nor for an updated review of
the entire document at this time.

Please see below for the text of comments that you submitted and our
resolutions to your comments. Each comment includes a link to the
archived copy of your original comment on
http://lists.w3.org/Archives/Public/public-comments-wcag20/, and may
also include links to the relevant changes in the WCAG 2.0 Editor's
Draft of May-October 2007 at
http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-20071102/

Thank you for your time reviewing and sending comments. Though we
cannot always do exactly what each commenter requests, all of the
comments are valuable to the development of WCAG 2.0.

Regards,

Loretta Guarino Reid, WCAG WG Co-Chair
Gregg Vanderheiden, WCAG WG Co-Chair
Michael Cooper, WCAG WG Staff Contact

On behalf of the WCAG Working Group

----------------------------------------------------------
Comment 1: Techniques for Reporting and Attaching Conformance claims
Source: (@@ archive reference missing)
----------------------------
Original Comment:
----------------------------

This is a general topic relating to all the ways we can profile and report
conformance claims.  All would be opitional. The question is -- do we recommend
any?   do we list options?   what goes in guidelines?  What in a resource doc.
Various candidates are listed below

---------------------------------------------
Response from Working Group:
---------------------------------------------

The following section has been added to the Understanding Conformance
Claims which has a direct link from the Conformance Claims section of
WCAG 2.0

Use of metadata to report conformance claims

The most useful way of attaching conformance claims to content would
be to do so in standard machine readable form. When this practice is
widespread, search tools or special user agents will be able to make
use of this information to find and provide content that is more
accessible or so the user agents can adjust the content. There are a
number of metadata based options under development for making claims,
and authors and tool developers are encouraged to support them.

In addition, metadata can be used to report conformance to individual
success criteria once Level A conformance has been achieved.

There are also programmatic reporting formats such as Evaluation and
Report Language (EARL) that are being developed that could provide
machine readable formats for detailed conformance information. As the
reporting formats are formalized and support for them develops the
will be documented here.

----------------------------------------------------------
Comment 2: accessibility-supported
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0084.html
(Issue ID: 1997)
----------------------------
Original Comment:
----------------------------

> Source:
> http://www.w3.org/mid/op.tbjlv1aowxe0ny@researchsft.myhome.westell.com
> (Issue ID: LC-1302)
>
> Technical/substantive issue
>
> The section currently provides no guidance to actually choosing a
> baseline that can in fact be used accessibly.
>
> I propose that the availability of a user agent which meets level-A
> conformance to User Agent Accessibility Guidelines 1.0 for the relevant
> technology and language be a minimum criterion for the selection of a
> baseline.
>
> In this way, selection of a baseline that is not actually accessible
> automatically makes it impossible to claim conformance to the
> accessibility guidelines. This avoids the situation where it is possible
> to construct content that can meet the requirements, but that is not
> actually accessible due to the absence of any means for using the
> baseline
> set. Otherwise there is a risk that the value of conformance will be
> significantly reduced, since it makes no reliable statement about whether
> the content is in fact accessible to real people.
>
> This seems a reasonable requirement given that UAAG is a W3C
> recommendation, and does not seem onerous for common web technologies.
>
> cheers
>
> Chaals
>
> ----------------------------
> Response from Working Group:
> ----------------------------
>
> For a period, WCAG made the assumption that user agents satisfied
> UAAG. This would have simplified a number of issues.
>
> However, in the absence of any user agent for any technology that is
> fully UAAG-compliant, the working group did not think it was practical
> to require only the use of technologies for which such user agents
> exist. The effect of such a requirement would be to make it impossible
> to claim compliance for any web content.
>
> The notion of baseline (now accessibility-supported web technologies)
> was introduced to make it possible to apply WCAG in environments with
> a wide range of user agent support for accessibility. It places a much
> heavier burden on the author to understand the capabilities of his
> customer's user agents. WCAG will be much easier to satisfy in an
> environment in which UAAG is satisfied by the available user agents.
>
> ----------------------------------------------------------

The notion of accessibility-supported technologies is defined in such
loose terms as to be meaningless in practice. Important questions for a
website trying to determine whether something is "accessibility-supported"
must include at least the following:

1. Does it matter that the content I use is only available on one
Operating System?
2. When does downloading a new browser discriminate against people with
disabilities?
3. What kinds of Assistive Technology need to be supported? Is ZoomText
enough? Or support for a screen reader, or for speech output combined with
switch access?

Leaving this question to an informative document, which in any case says
that the working group doesn't offer any answer, is almost useless for an
organisation trying to determine which technologies are accessible as
opposed to an organisation trying to meet some arbitrary requirement
regardless of its impact on accessibility.

Therefore I feel that the original comment has not been satisfied at all,
and if the current approach is incorporated into a new Last Call I expect
to again make a comment (and objection if necessary).

As noted in the original, some kind of testable criteria should be
offered. I understand that UAAG conformance (even to some given profile)
may not be ideal, but simply leaving it to people to make up their own
criteria doesn't show any path to interoperability except at the level of
the least people think they can get away with, which is unlikely to assist
accessibility in any way.

Related comment (from
http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0085.html)

> Source:
> http://www.w3.org/mid/op.tbjxedeqwxe0ny@researchsft.myhome.westell.com
> (Issue ID: LC-1307)
>
> Structural/substantive issue
>
> The specification seems to take no account of situations where in fact
> all user agents relevant to a given baseline offer functionality that
> the guidelines are requiring of authors.
>
> Where this is the case (for example, SVG user agents generally provide a
> mechanism to pause any animation independently of the content, and in SVG
> tiny it is not possible to provide the functionality in content anyway)
> the guidelines should take it into account.
>
> I propose that the baseline section be reworked, to incorporate this type
> of situation. Perhaps the most robust way of specifying this would be to
> explicitly relate UAAG requirements to WCAG requirements, and note that
> where there are (some expression for most or all) user agents for the
> baseline which meet a given UAAG requirement the corresponding WCAG
> requirement need not be met. Note that the proportion of user agents for
> which this needs to be true should be at least as high, and probably
> higher than that which is reasonable to justify the use of a particular
> baseline in the first place.
>
> ----------------------------
> Response from Working Group:
> ----------------------------
>
> WCAG success criteria have been written to describe the functionality
> that must be available, but have avoided specifying that the
> functionality must be provided by the user agent or by the content
> directly. For example, SC 2.4.1 (A mechanism is available to bypass
> blocks of content that are repeated on multiple Web pages) can be
> satisfied by providing links in the content to bypass the blocks, or
> by providing headings at the beginning of each section and relying on
> the user agent to skip the repeated content by skipping to headings.
>
> ----------------------------------------------------------

Unfortunately, there is no clarity in what user agents are to be counted
in the notion of "accessibility-supported", so it is not possible to make
a rational (as opposed to arbitrary or wishful) determination of whether
this is the case. As a single example, the Working Group has not resolved
the question of whether Zoom support in HTML (even in the limited terms
that the working group understands that) is sufficient in current user
agents to determine whether it can be relied on.

This suggests that the practical problem of determining whether support is
available still exists. This issue could well be resolved by an
appropriate resolution to LC-1302 but I currently consider that it is not
satisfactorily resolved in the current draft.

---------------------------------------------
Response from Working Group:
---------------------------------------------

You asked a series of questions. Responses are under each:

1. Does it matter that the content I use is only available on one
Operating System?
 * Although this is an important Web issue, availability across
platforms is not directly covered if the restriction applies to all
users. If users with disabilities are restricted in platforms when
others are not then it would violate conformance requirement #5. The
rules on "accessibility support" say" The user agent(s) that support
the technology are also accessibility supported and available for
download or purchase in a way that does not disadvantage people with
disabilities."

2. When does downloading a new browser discriminate against people
with disabilities?
  * There are any number of ways that are accepted in law as discrimination
     o if people with disabilities are charged more
     o if people with disabilities are not equally informed
     o if people with disabilities must do considerably more work to download
     o if people with disabilities do not have players/viewers
available in the same locations (same platforms)

3. What kinds of Assistive Technology need to be supported? Is
ZoomText enough? Or support for a screen reader, or for speech output
combined with switch access?
  * The working group did not come up with a list of AT that would
need to support a technology in order for it to be
"accessibility-supported". The group recognized that this was both a
difficult and a fluid situation. It is not possible to support all
users' AT. Nor is it sufficient to support the AT used by just a small
percentage of the users. Also it is important to not talk about a
particular AT without also specifying the version of that AT. Thus a
list of what technologies would be sufficiently supported would change
over time as would the AT that one would look to for that definition.
The working group therefore defined its guidelines with the
recognition that 'accessibility-support' would need to be defined and
updated separately from the guidelines. There simply is no other way
to do it. The working group expects that documented lists of
technologies that are accessibility support will emerge along with the
assistive technologies that support them.

You said that leaving the definition to an informative document was
unsatisfactory. The working group agrees. The definition is normative
and appears in both the conformance section and the glossary both of
which are normative sections. If you mean leaving the list of AT that
must be supported out of the WCAG as discussed above, yes - that is
indeed what we have done. If you know of some other way to do this we
would be very interested in hearing it. You mentioned UAAG in your
comments. But that is for User Agents - and we are discussing Content
Technologies (like HTML etc.). If you have a means for determining
which are accessibility supported (now and in the future) besides the
formulation here - please submit it to us to consider.

Regarding your related comment
(http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0085.html),
you said there was no clarity as to what constituted an accessible
user agent. The conformance section lays this out as follows:


    2. The Web technology must have accessibility-supported user
agents that are available to users. This means that at least one of
the following is true: a. The technology is supported natively in
widely-distributed user agents that are also accessibility supported
(such as HTML and CSS); OR b. The technology is supported in a
widely-distributed plug-in that is also accessibility supported; OR c.
The content is available in a closed environment, such as a university
or corporate network, where the user agent required by the technology
and used by the organization is also accessibility supported; OR d.
The user agent(s) that support the technology are also accessibility
supported and available for download or purchase in a way that does
not disadvantage people with disabilities.



Again if you have suggested improvements please submit. This is a
difficult area and any suggested edits are appreciated.

----------------------------------------------------------
Comment 3: LC-1320 NEW PROBLEM Re: Your comments on WCAG 2.0 Last Call
Draft of April 2006
Source: http://http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0082.html
(Issue ID: 1998)
----------------------------
Original Comment:
----------------------------

> Source:
> http://www.w3.org/mid/op.tbly4lvhwxe0ny@researchsft.myhome.westell.com
> (Issue ID: LC-1320)
>
> Technical/substantive issue?
>
> The current requirement fo unambiguous parsing is impossible to meet -
> there are always multiple ways of parsing any data.
>
> Instead I suggest the old wording of "conforms to formal published
> grammars".
>
> This makes it feasible for User Agents to recognise the content and parse
> it either according to the rules for such grammars, or in cases where it
> is necessary (such as HTML) to use specifically adapted parsing
> techniques.
>
> cheers
>
> Chaals
>
> ----------------------------
> Response from Working Group:
> ----------------------------
>
> To make this requirement easier to understand, we have reworded SC
> 4.1.1 as follows:
>
> Content implemented using markup languages has elements with complete
> start and end tags, except as allowed by their specifications, and are
> nested according to their specifications.
>
> Note: Start and end tags that are missing a critical character in
> their formation, such as a closing angle bracket or a mismatched
> attribute value quote are not complete.
>
> The working group looked at this topic carefully over an extended
> period of time and concluded that requiring strict adherence to all
> aspects of specifications does not necessarily result in an increase
> in accessibility. For example, it is possible to create invalid pages
> that present no accessibility barriers. It is also possible in certain
> situations to enhance accessibility through the use of markup that is
> not part of the specification.
>
> The working group must work within its charter and only include things
> that directly affected accessibility. Some aspects of "use
> technologies according to specification" and validity do relate to
> accessibility. However, others do not. So requiring validity would
> take us beyond our charter. We do recommend it though and it is our #1
> technique listed for conforming to SC 4.1.1.

The current requirement could be expressed more clearly by referring to
the XML concept of "well-formedness" (which it instead attempts to
replicate), and analagous constructs of basic syntax in other languages.

I recognise that it is possible to write invalid documents which
nevertheless improve accessibility. A specific example would be making use
of the embed element in "HTML tag-soup". It is also, of course, possible
to do this in a way which is actually valid content, by extending the DTD.
Joe Clark recently suggested an example method for this specific case in
XHTML [1], and there is no requirement to break validity in order to use
such extensions. Markup languages in common use (with the single exception
of CSS) actually incorporate specific extension mechanisms in order to
make it possible to use these while maintaining validity

While user agents are often required, in practical usage, to support by
reverse-engineering and guesswork a number of undocumented conventions and
semi-documented private extensions used to extend markup languages,
allowing authors to rely on these has the effect of making it far more
difficult to sytematically improve user agents. Unoducmented behaviour is
effectively irreproducible or very difficult to reproduce and thus
difficult or impossible to support in assistive technology.

Requiring any such extension mechanism to be at least implemented
according to the rules of the relevant markup language would have the
effect of reducing the amount of guesswork and reverse engineering
required of user agents, incorporating a requirement into the dependent
Authoring Tool Accessibility Guidelines, while not outlawing the practice
of extending languages in order to enhance accessibility, nor of using
those extensions in content.

Indeed, requiring that the markup construct used be in accordance with
publicly documented semantics (where publicly docmented actually applies
to the scope of use - so for an intranet, under the structure of
"accessibility supported" you only have to make the documentation
available to those who are responsible for tools used within that
environment) would enhance accessibility in general by requiring the use
of open standards, rather than allowing for undocumented behaviour to be
exploited.

I therefore feel that the original narrow question raised has been
answered by the change, but that the result is still unsatisfactory and
the issue of appropriate requirements in this area is not satisfactorily
resolved.

---------------------------------------------
Response from Working Group:
---------------------------------------------

It is true that the guidelines now essentially require that content in
markup languages be well formed. However, exact parsing requirements
vary amongst markup languages, and most non XML-based languages do not
explicitly define requirements for well formedness. Therefore it was
necessary to be more explicit in the success criterion in order to be
generally applicable to markup languages. Because the term "well
formed" is only defined in XML and applying it to HTML would restrict
valid HTML we felt we could not use that term.

The guidelines are silent on the topic of validation by DTD
customization because there is not a relationship to accessibility.
While it is possible for an author to use custom language features,
create a DTD that permits those features, and validate the content,
this does not ensure that user agents will know how to support those
features. It is also possible for user agents to support custom
language features but not document them or provide a DTD for
validation, yet if the features work, authors should be permitted to
use them. This is the reason WCAG conformance depends on the concept
of accessibility support - whether or not features are documented or
pass public validators, they must be supported in user agents for a
WCAG conformance claim to be valid. The reverse is also true -
features not supported by user agents cannot be used to achieve WCAG
conformance, even if those features are documented in public
specifications.

The Working Group is extremely sympathetic to the desire to ensure
that all user agents support the same form of a given language, as
well as that all language features be documented both in technical
specifications and forms that can be processed by machine. However, it
is beyond the charter of the Web Content Accessibility Guidelines to
create content authoring requirements that effectively create user
agent requirements. Conformance to WCAG 2.0 is based on existing user
agent support, and advocacy for improvements in that domain should
take place in complementary activities, such as within the User Agent
Accessibility Guidelines.

Note that Validating pages is our #1 sufficient technique for meeting
this success criterion.

----------------------------------------------------------
Comment 4: Definition of Levels with respect to impact on people with
disabilities
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0081.html
(Issue ID: 1999)
----------------------------
Original Comment:
----------------------------

> Source:
> http://www.w3.org/mid/op.tbjlv5miwxe0ny@researchsft.myhome.westell.com
> (Issue ID: LC-1303)
>
> Structural/substantive issue
>
> The current levels system for success criteria seems insufficiently
> described, and inappropriate to the needs of developers.
>
> WCAG 20 acknowledges that most criteria are essential in order for
> some people to be able to use some types of web content. It then
> attempts to describe the amount of benefit to usersin general (the
> difference between level 1 and level 2) and the apparent applicability
> of a technique to the web. It appears that the goal is to provide a
> "reasonable" implementation planning tool.
>
> Both of these things are in fact situation-dependent. In some cases,
> it will be easy, in others critical, to apply approaches whose level
> suggests that they are not so important or easy in the general case.
>
> Thus, while providing a signed equivalent of content is extremely
> important in a number of cases, and is occasionally trivially easy (in
> others it is quite expensive), it is perfectly possible that all web
> content claiming triple-A conformance is without signed content.
>
> Similarly, there is no clear technical justification for different
> requirement levels for captioning depending on whether content is
> "live"/"real-time", or pre-recorded. The accesibility result for users
> who rely on captions is exactly the same in both cases. Again, this
> may be easy to implement in some cases, and is very expensive in
> others, and its relative importance will be variable.
>
> In order to assist developers, and policy makers, WCAG should describe
> the imact on users of a particular success criterion being met or not.
> This enables prioritisation based on the actual situation, rather than
> a generalised model situation which will often be an inaccurate
> representation of the case at hand.
>
> I propose that either:
> 1. the levels be removed, and the information in the currently
> informative "Understanding WCAG" about who benefits be moved to the
> normtive recommendation. Or, as an alternative
>
> 2. the specification revert to the WCAG 1.0 priority scheme, rather
> than with the "apparent ease of implementation" clouding the question
> of their relevance to users.
>
> cheers
>
> Chaals
>
> ----------------------------
> Response from Working Group:
> ----------------------------
>
> The description of conformance levels in WCAG 2 has been rewritten to
> clarify the differences (see
> http://www.w3.org/TR/2007/WD-WCAG20-20070517/#overview-levels ):
>
> The word "levels" does not mean that some success criteria are more
> important than others. Each success criterion in WCAG 2.0 is essential
> to some users, and the levels build upon each other. However, even
> content that conforms at AAA (triple-A) may not be fully accessible to
> every person with a disability.
>
> *In general, Level A success criteria achieve accessibility by
> supporting assistive technology while putting the fewest possible
> limits on presentation. Thus people with a wide range of disabilities
> using a wide range of assistive technologies, from voice input and
> eye-tracking devices to screen readers and screen magnifiers, are able
> to access content in different ways. In other words, Level A success
> criteria support the ability of both mainstream and specialized user
> agents to adapt content to formats that meet their users' needs.
>
> *The success criteria in Level AA provide additional support for
> assistive technology. At the same time, they also support direct
> access to content by the many people who use conventional user agents
> without assistive technology. In general, Level AA success criteria
> place more limits on visual presentation and other aspects of content
> than the success criteria in Level A.
>
> *Level AAA success criteria increase both direct access and access
> through assistive technology. They place tighter limits on both
> presentation and content.
>
> ----------------------------------------------------------

The conditions seem to be ambiguous with respect to their impact on people
with disabilities, and heavily based on the irrelevant (to accessibility)
question of how much impact it might have on the ability to use arbitrary
presentation and design. They certainly don't provide a clear measure of
the impact on people with disabilities, even whenn combined with the
informative "Understanding ..." document, which means that this
specification is not very helpful for determining accessibility except in
the context of an arbitrary requirement that any possible means of
presentation is acceptable.

The only rational interpretation is therefore that the working group has
tried to assess some measure of "reasonable effort" or "cost/benefit"
without explaining this. Obviously, it is more dificult to caption live
multimedia than pre-recorded content from a library in some cases although
it seems perfectly feasible for most major US television networks to do
it, since they do both kinds of content in practice. Therefore a different
priority based apparently only on this consideration represents the
working group stepping far beyond the question of accessibility, and into
making guesses about content production which are both inappropriate and
outside the scope of their expertise.

I consider the issue raised totally unsatisfied by the response, and will
continue to raise it, if required as a formal objection.

---------------------------------------------
Response from Working Group:
---------------------------------------------

Although WCAG 1.0 described its priority levels as being based on the
checkpoint's impact on accessibility, experience has shown that
checkpoints at all priority levels were basic requirements for some
groups. It was misleading to imply that the priority 2 and 3
checkpoints were less important to accessibility than the priority 1
checkpoints since this implied that the needs of people with some
disabilities were more important than the needs of people with other
disabilities.

The working group has been very careful not to claim that meeting a
higher level of conformance makes content more accessible. The word
"levels" does not mean that some success criteria are more important
than others. Each success criterion in WCAG 2.0 is essential to some
users, and the levels build upon each other. However, even content
that conforms at AAA (triple-A) may not be fully accessible to every
person with a disability or combination of disabilities, especially
certain types of severe disabilities."
(http://www.w3.org/TR/2007/WD-WCAG20-20070517/#overview-levels)

The working group did not want to define conformance levels by
disability, since this seemed likely to imply (falsely) that the
requirements for one disability were in conflict with the requirements
for another disability and that authors would need to choose which
people to support. Neither did we want to imply that the number of
people with a disability was a measure of its importance. (However,
since each level of conformance builds upon the previous level, it
will be true that higher levels of conformance will provide access to
more people.)

The descriptions of the levels in the May 2007 draft reflect the major
dividing lines we used in categorizing success criteria, and a number
of success criteria changed levels based on that description. At level
A, it may be necessary to use assistive technology to transform the
content into a suitable rendering. At level AA, there are more
requirements for direct access without the need for assistive
technology. At level AAA, the direct access requirements are stronger,
and it may not be possible to satisfy those requirements for all types
of content. These distinctions are based on the types of solutions
that are appropriate for developers, not on the measure of impact on
people with disabilities.

Difficulty of implementation did influence the conformance levels of
some success criteria. When solutions required uncommon skills of
authors or extensive training, they might be placed at a higher
conformance level. Hence, extended audio descriptions, which are very
difficult to produce, are at level AAA, although for some content they
may be necessary for providing access to the multimedia content for
the vision impaired.

More discussion of the considerations made in selecting levels can be
found at http://www.w3.org/WAI/GL/WCAG20/WD-UNDERSTANDING-WCAG20/Overview.html#uc-levels-head.

----------------------------------------------------------
Comment 5: Recognize other work on learning disabilities
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0095.html
(Issue ID: 2005)
----------------------------
Original Comment:
----------------------------

> I agree with Jonathan, in that the current draft does not have the
> wording that I was hoping.
>
> Specifically we want people to look at other specifications until WCAG
> adequately supports people with Learning Disabilities. That it why it
> was  important that the words "There is a need for more research and
> development in this important area." are removed, as this implies that
> WCAG 2.0 has done it's best under the currently available knowledge.
>
> People will assume from the current wording , that there are no better
> options to include people with learning disabilities. Even worse - they
> may think that other standards are non credible.
>
> It is important to note that some sites WANT to include people with
> learning disabilities. The very least we should not make it less likely
> for them to succeed.

I agree that the current draft simply fails to recognise work done outside
WCAG, and instead gives the impression that there is no other current
knowledge - which as Lisa notes does a dis-service to accessibility and to
those who want to make their sites accessible.

The process issue is difficult. I think that there are valid criticisms to
be made against W3C process in dealing with an area of general concern,
and in particular in the application of that process in WCAG from time to
time. However, I am not sure what are the specific structural changes that
I would suggest. Instead, unfortunately, since I cannot dedicate
sufficient time to participation in order to meet the requirements of good
standing, I have chosen to simply rely on the public feedback aspects of
W3C process - last call, and the proposed recommendation process (since we
are a W3C member).

I believe that the comment process, and ensuring that we follow up on it,
is about the best way to proceed for those who don't have the bandwidth to
maintain good standing in the group.

cheers

Chaals

---------------------------------------------
Response from Working Group:
---------------------------------------------

We have tried to include references to other people's work throughout
the informative sections of the descriptions of the success criteria
and techniques.  If you are aware of any other (non-commercial) work
that should be cited please let us know.

Received on Sunday, 4 November 2007 04:17:13 UTC