Re: We area close !

On Sep 17, 2012, at 12:20 PM, Peter Korn <peter.korn@oracle.com> wrote:

> Gregg,
> 
> PK: I think you mis-read my comments, or I was otherwise unclear.
> 
> I think there is a show-stopper for your proposal for 2.4.2 Page Titled.  I see that you had in-line comments after your sign-off, so I'll also address those in-line.
> 
> Yes, for 2.4.1 Bypass Blocks, I think we have a reasonable way to apply this that holds up to the three examples I cited, across the desktop GUI and mobile world.  I think it needs further scrutiny before we declare ourselves done, but I am cautiously optimistic about this one.  
> 
> For the other two - 2.4.5 Multiple Ways & 3.2.3 Consistent Navigation, I didn't see how they applied to the examples I was looking at. 

GV: correct.  They don't apply to the examples you were looking at.  Because those were not things they would apply to.   Multiple ways is for getting to software - not around in it and consistent navigation only applies to navigation elements. 

> I didn't do an exhaustive look this past Sunday evening.  Doing no harm to a handful of examples (but not applying) isn't the same as saying "it works, let's use it".  And frankly, if we cannot find good examples where they DO apply, then I am of the opinion that they likely SHOULDN'T apply.  Which is why I said we need to find positive examples of them applying first.

GV:  It is entirely likely that some will be of less importance than others for docs and software.  Or occur more often others.       In not sure that I follow how one gets from 'it doesn’t apply in many places" to "it doesn’t apply".    If we were deciding whether to include things in a standard or not -- then importance and prevalence are both things we would look at when deciding what to devote time and standard space.  But we arent doing that.  We are just saying how it would apply.   So the fact that it may not apply in as many places as other provisions doesn’t seem as relevant to us. 

> 
> Now, on to in-line replies..
> 
> On 9/16/2012 11:23 PM, Gregg Vanderheiden wrote:
>> 
>> GV:  Thanks Peter
>> 
>> Looks like things are working wherever they are applied to the thing the SC with the words I proposed are present.
>> and - where they are not present -- then of course the success criterion is automatically satisfied like all the other success criterion 
>> 
>> The only problems or confusion seemed to be when you tried to apply the SC against something "inside" a doc or software program - which would be like applying WCAG inside a web page or web app (that resided at one URL).    And that of course is going beyond what WCAG does.   And is what had us confused for so long.
>> 
>> So no show stoppers here for the proposals. 
>> 
>> Gregg
>> 
>> 
>> 
>> 
>> On Sep 16, 2012, at 9:08 PM, Peter Korn <peter.korn@oracle.com> wrote:
>> 
>>> Hi Gregg,
>>> 
>>> I really think it would be useful to take the Examples for UI Context discussion and apply your suggested definitions to them.
>>> 
>>> 2.4.1. Bypass Blocks: 
>>> Looking at How many Example #1: two document windows since the menu bar & toolbar can be repeated in the software, some bypass mechanism would be needed...   This seems like a reasonable application.
>>> Looking at Changed? Example #3: Tabbed panes there is nothing formally repeated, so this wouldn't apply.  That too seems like a reasonable application.
>>> Looking at Changed? Example #24 calender appointments since the calendar title & days repeat while content below changes, arguably again some bypass mechanism would be needed.   This seems like a reasonable application.
>> GV: Good.    One down.
> 
> PK: yes, perhaps.  I want to see more examination, more looking at more of our examples, before I mark this one as "down".
> 
>> 
>>> 2.4.2 Page Titled:
>>> 
>>> Looking at How many Example #1: two document windows there is no obvious visible page title; "Untitled Document 1" is no more or less the obvious "software title" than "Untitled Document 2" is (and in fact, clearly neither one  is correct).  This seems like a poor fit to this situation. 
>> GV: I am confused -- and I think maybe you are confounding my proposal for this SC with another one. (see below).      The document hasn’t been saved -- or hasn’t been saved with a meaningful title.  So clearly it fails -- as it should.   If you pick anything that fails an SC and use it as an example it will of course fail.  
>> 
>> GV:  Remember my proposal was to replace  "web pages" with "documents" and "software".   Since the windows are not software (but internal bits of a program) then you must be evaluating this as to how it applies to documents.   This isn't a document yet (or someone is distributing documents titled 'untitled' -- maybe it is an art piece) or it is something the user is creating and they will know what it is (and they should save soon! -- with a title !
> 
> PK: Nope, I 'm not applying this to documents.  I'm saying we have one software app whose only visible UI is these two documents. 

GV:  right.  and what I was proposing was that we apply this at the software level (software as a single object) -- not to parts of the software.   So looking at windows isn't relevant. 

> And I'm scratching my head trying to figure out what the "page titled" should be for this software.

GV:  I would be -- is the software titled.    Not pieces inside it. 

>   Note my "Note" below, that starts with "Note: Since Understanding for 2.4.2 begins with...".  There is no obvious, user-visible text to be the "page title" for this two-windows-showing software app that addresses the user needs described in Intent.  Therefore I question whether this applies (as you have proposed writing it for software).

GV:  it does -- and if you look at real world apps -- I see the apps name on the menubar 
> 
> I strongly suggest we start doing what we discussed last Friday: writing a specific "WCAG2ICT Notes" for all language we are proposing for the remaining unconsensed SCs (and as a separate background task, write them for the consensed ones), describing how the user needs described in Understanding are addressed in the non-web context.  I commit to doing that for any text proposals I make.

GV:  I agree. 
> 
> 
>>> 
>>> Looking at Changed? Example #3: Tabbed panes we don't know for sure what the application name is.  If it is "Media Center" then this would be helpful; if not... then not.  This seems like may not be a good fit to this situation. 
>> GV: These aren't documents or software programs.  So Im not sure why you mention them when you want to talk about my proposal.  You are looking at subparts of a software program and trying to evaluate if you can identify  the program from the piece.  That isn't part of what I was proposing.
> 
> PK: No - I'm taking the example and saying "if this is the only visible part of the software application at this moment in time, then how would the proposed text for 2.4.2 apply in practice?".  And then I'm recording my answer above: "This seems like it may not be a good fit to this situation".  Again, take this in context with my Note below, looking at Intent for this SC.

GV:  it would be helpful if you used screen shots of real programs.  These look like hypothetical drawings that don't have all the detail on them.    Are these screen shots from a real OS?  Ah -  see that you picked up on this below.


> 
>> 
>> GV: I DO think it would be useful for a person to know what program each bit of UI on the screen belonged too -- and that they all had a program name on them.   But that is not what the success criterion requires and not what I proposed.  
>> 
>> What I proposed was that it was possible to identify the software program.  On a mac - when I am in a program, its name appears at the top of the screen.
>> 
>> On a PC - every program I opened (and I opened a dozen or so) had its name on the top title bar of the main window in one form or another.   So it doesn’t look like it would be hard to do.
> 
> PK: Ahhh.... So what you are really saying is that (some of) my examples are wrong, and that the application name WOULD NORMALLY BE APPEARING in the title bars of these windows, and should be to satisfy your proposed text of the SC.  

GV:  yes. bingo

> 
>>> Looking at Changed? Example #24 calender appointments it is pretty obvious to folks raised with a cultural familiarity with the Julian calendar that this is a calendar / appointment application.  It is not at all clear what the software title is; it isn't "October".  And consuming a significant portion of a small screen to display the software application name would come at significant cost, and somewhat questionable benefit.  This seems like may not be a good fit to this situation. 
>> GV: What program and operating system did you get this screen capture from?   It looks like only part of a program -not the whole program.  
> 
> PK: This is an abstraction derived from the iOS calendar application when viewed on an iPhone.  I do see additional text (with the word "calendars" on it) when in portrait mode, so that too isn't a real life example of a mobile UI that is missing anything that would help orient a user with cognitive impairment as to what is going on.  Rotate that screen 90 degrees to landscape mode, and you will loose the word "calendar".  Also go to just about any mobile phone's dialing application, and you won't see the word "phone" on it - just the NumPad for entering numbers (plus perhaps the word "Call" appearing on one of the buttons no where near where one would look for a "title" to the software).

GV:  this is to orient you to the program.  not within it.   in a single-screen (non-windowing) app like you are talking about -- the user knows what app they are looking at .  
> 
> Do you propose that the landscape view of the iOS calendar on an iPhone, and the dialing apps of most mobile phones, should fail this SC?  The visual layout at least of the latter is pretty clearly different and so I would question the need for a title in that case for folks with cognitive impairments (something perhaps to discussion with Clayton Lewis and other cognitive impairment experts).
> 
>> 
>>> Note: Since Understanding for 2.4.2 begins with "The intent of this Success Criterion is to help users find content and orient themselves within it", and specific benefits include "People with visual disabilities will benefit from being able to differentiate content when multiple Web pages are open" and "People with cognitive disabilities, limited short-term memory and reading disabilities also benefit from the ability to identify content by its title".   
>> 
>> GV:  Yes.  So substituting Software for "web page" you get "differentiate content when they have multiple programs open".  The SC would apply to figuring out which program you are using -- in the same way WCAG would apply to knowing which page you were on.
> 
> PK: A key difference is that in WCAG, the "which page you are on" is about the pages WITHIN a website,

GV2: WCAG isn't about web sites.    It is about web pages.    So the comparison is a web page to an app.     And within an application would map to within a page.    
 
> not over the entire Internet.  Most of the programs you run likely aren't from Oracle; so is it Oracle's responsibility to help you distinguish our programs from whatever else you might decide to run?

GV2:  no.  and not suggesting that you do. 

>   It certainly isn't our responsibility for things outside our website with regards WCAG.

GV2:  right.
> 
> In any case, as I mentioned above and tying back to our Friday conversation, I think this SC needs to have "proposed WCAG2ICT Notes" describing how Intent from WCAG is being carried forward into the non-web software world, for us to better discuss it.

GV2:   agree 
> 
>> 
>> GV: It would be good to have orientation at levels inside a program and inside a web page -- but as you know-- when we try that we run into all sorts of problems.   Then people start saying that it doesn’t apply.   
>> 
>> My proposal it so apply it as the level that is parallel (web page = web app = software app)  and then it works.    Drilling down and finding it doesn’t work, and then saying it doesn’t apply doesn’t seem to be the way to go or to make sense. 
>> 
>> So - two down. 
> 
> PK: Sorry, this one isn't settled yet.  Not even close.

GV2:  OK -- look back at it and think APP level rather than "inside the app"  and I think you will see how it falls out.   it would be good to also have "inside the app" guidelines but that can come as advisory techniques -- and then we don't need to worry about each technique or guideline applying everywhere. 
> 
>>  
>>> 2.4.5 Multiple Ways:
>>> 
>>> Looking at How many Example #1: two document windows it wouldn't apply, as there isn't a "set of software products" visible in the example.  
>> GV:   Huh?  I lost you.   It doesn’t apply to OK buttons in a dialog box either.  or any other pieces of a program.     But that isn't what is proposed.   I don't follow you here.   My proposal was that it applied to software programs in a set of software programs.   You don't have a set of software programs so it automatically meets -- just like all the SC when applied to something that are not addressed in the SC.   
>>> 
>>> Looking at Changed? Example #3: Tabbed panes again it wouldn't apply, as there isn't a "set of software products" visible in the example. 
>> GV:   Ditto.   why are you citing examples that don't have anything to do with the SC as proposed? 
>>> 
>>> Looking at Changed? Example #24 calender appointments again it wouldn't apply, as there isn't a "set of software products" visible in the example.  
>> GV:   Ditto.
> 
> PK: I'm looking at a handful of examples - only specifically chosen at the outset to help illustrate the first of your four SCs in this thread, and then carried forward to the other three late on a Sunday night.

GV2: I see that -- but don't understand why since they don't relate ? 

> 
> 
>>> 
>>> Note that Understanding is tied to locating content & information, not locating applications and functions; not clear how much application 2.4.5 has to software UIs.  Or perhaps none of these (or any of our) examples are useful to illustrate where 2.4.5 would be helpful.  Perhaps we need other examples for software, showing where and how it would work.  AND more especially, describing HOW the helpfulness in WCAG 2.0 Understanding translates into similar helpfulness in the software world!
>> GV:  Again - if you look at WCAG you will see that it only applies to pages.  So if a web app is a page-- it only applies to finding the Web App -- not to finding any information in the Web app.  Same for documents.    
>>     Yes - it would be  good to have multiple ways to find content WITHIN a web page or WITHIN a web app -- but WCAG doesn’t require it.  Similarly, it would be good to find have multiple ways to find content WITHIN a single doc or WITHIN a single application.  But that would go beyond what is parallel with WCAG.   
>>     My proposal is to apply it to documents and software to the same level as it is applied in  WCAG for at least the most common forms of web content (docs that are on a page and web apps at one URL). 
>>  And it does work for that. 
>> 
>> 
>> So three down - though this won't come up terribly often.    IT does give us a good place to hand all the advisory techniques that WOULD drill down into docs and apps. 
> 
> PK: Until we have positive, real-world examples where it would apply that we can discuss and reach consensus on, this one isn't "down" either.

GV2:  Fair enough.   After all - I'm asking for you to use real world examples.

> 
>> 
>>> 3.2.3: Consistent Navigation: 
>>> Looking at How many Example #1: two document windows since the windows are simply repeated except with different non-GUI content, if any of the UI components are termed "navigation" this would be automatically met.  If none are termed "navigation", then it doesn't apply.  This seems like it could be OK; certainly no harm is done.
>> GV:  OK
>>> Looking at Changed? Example #3: Tabbed panes it looks like it wouldn't apply, as there aren't any "repeated navigation mechanisms" visible in the example. 
>> GV:  You misunderstand the way conformance works in WCAG.   Look at CR1 and at the definition of "satisfies the success criterion"
>> satisfies a success criterion
>> the success criterion does not evaluate to 'false' when applied to the page
>> GV: so for example, if a page has no images on it then the requirement that all images have alt text will not evaluate to "false" and the success criterion is satisfied. 
>> GV: now take your example.  Since there are no repeated navigation mechanisms
>> Navigational mechanisms that are repeated on multiple Web pages within a set of Web pages occur in the same relative order each time they are repeated, unless a change is initiated by the user. 
>> For these pages this is not false -- so the success criterion is satisfied and the pages conform.
>>> Looking at Changed? Example #24 calender appointments again it looks like it wouldn't apply, as there aren't any "repeated navigation mechanisms" visible in the example. 
>> GV: Ditto.  there aren't any movies or  a dozen other things covered by success criterion either.   So the success criterion are all satisfied since none are violated. 
>> 
>> GV:  Think of it this way.  Are you conforming to the law that you not run stop signs if there are no stop signs?   
> 
> PK: Again, unless we can come up with actual real-life examples where this language would apply, and agree on that application, then we haven't done our job.

GV2:  ive cited real world examples dozens of times.   But an easy one is open office.  

Screen shots at the bottom of the page. 

> 
>>> Note that this seems like it is a rare situation to actually occur in most software, other than "content-driven" software like books or other sets of information with things like next/prev links on them (e.g. Help applications and the like, which are essentially similar to HTML/web content).  
>> GV:  not sure what you are referring to.   Consistent navigation -- or repeated navigation -- in apps and doc is very common   But also very easy to meet. 
> 
> PK: Please give me some real-life examples to discuss and review.  That was my core point in my first response to your e-mail: we need to run your text by real-life examples and evaluate them there.

GV2:   see below
> 
>> 
>>> 
>>> 
>>> From this quick analysis, I think we may have something not too unreasonable for 2.4.2 Bypass Blocks. 
>> 
>> GV:   Not sure why it is just "not too unreasonable" 
> 
> PK: See my more positive characterization above.

GV2:  OK

> 
>> 
>> 
>>> We might have something for 2.4.5 Multiple Ways  and for 3.2.3 Consistent Navigation - but I think we need to come up with a set of positive examples where this really occurs & would apply;
>> 
>> GV:  
> 
> PK: Did you mean to write something here?

GV2:  getting old.     See below. 

> 
>> 
>>> it isn't clear from the examples we've generated on the Examples for UI Context discussion that they are particularly useful.  
>> 
>> GV:  those examples were for looking inside of apps and docs and the breakthrough is in realizing that that is like looking inside web pages.   and these were not designed to be applied inside of a web page.   So it is no surprise that those do not fit.
> 
> PK: Yes.  So we need other/better then to move this discussion forward.

GV2:  below

> 
>> 
>>> 
>>> I think this approach fails for 2.4.2 Page Titled.  If we instead say that the "title" of the "software" is the software applications "name" (whether the executable name or the name as it appears in things like the Windows Start menu),
>> 
>> GV:  That is exactly what I proposed. 
>> 
>>> then we have moved significantly away from what Understanding for 2.4.2 is all about -> helping users locate the content & information they want. 
>> 
>> GV:  WCAG does not provide all that user's want.  OR all that can be done.   It is a minimum standard for accessibility.  You can go much further.    Our goal however was to come up with a parallel to WCAG  --- not to go beyond it to meet broader needs.   I would love to -- but not our job here. 
> 
> PK:  I believe it isn't enough to simply have some words that don't fail in the software context.  Those words should also support the user needs expressed in Intent.  Not all of the user needs.  Not writing new SCs - I'm not arguing for that expansion of our charter.  But if seems like a good idea but we can't actually find examples where this helps & works & makes things better for users with disabilities, then we shouldn't write that application text.
> 

GV2:  not sure what you are trying to get to / get at.    All of these are based on user needs.   Some things are more important in some contexts than others.  These success criteria were developed in the Web context and while they apply to software they may not be as important.   The consistency one is though. 

> 
>> 
>>> Rather, if we want to apply 2.4.2 to the GUI environment, going with window title seems a better match.
>> GV:  that is inside the app.   and these do not apply inside a web app.  
>> that would be good -- but beyond what our charge is.   AND as we have found out -- it gets complicated and ambiguous as soon as we go deeper.
> 
> PK: OK, for Page Titled, this is pretty clearly about a VISIBLE page title, helping the user orient themselves to the correct content.  
> 
> What is the content of a document editor that when launched opens a blank page?
> 

GV2:  Good to have -- but beyond what is proposed here.  

> until a document is published it does not need to conform to anything.
> and windows inside of an application are not covered as entities if the unit of conformance is software.  So for the TITLE provision -- I applies to the unit of conformance which for WCAG was a web page but for WCAG2ICT it would be the software application.    Now in WCAG we would then attach any advisory techniques (for things that are not required but good to do) to that success criterion.   We aren't doing that in WCAG2ICT  but that is where all the techniques you want to document would be stored. 

>> 
>>>   But then what do we do about the burgeoning world of mobile software UIs?  And what about audio UIs?  Does Page Titled really make sense in those worlds?  Maybe not...
>> 
>> GV:  yep.  part of the complexity and ambiguity I was referring too.
>> 
>> Go back through this will fresh eyes and see if you can see what I saw.    It eluded me / us for some time.  But once you grasp it -- these last 4 fall out nicely like the others.   Some are not as profound as what we were shooting for -- but they are what is parallel to WCAG and a number of the WCAG items were also not profound-- but were included to give a place to tie a whole raft of untestable, ambiguous but extremely helpful advisory techniques to. 
>> 
>> When you or others define techniques to go along with this -- then there will be these provisions to tie them all on to, and to go all the places you want to go - without worrying about whether they apply everywhere (they won't) or are all testable (they won't be).  But instead can worry about if they are helpful and powerful - which many of them will be. 
> 
> PK: To repeat myself, I think each of these four need a paragraph or two of "WCAG2ICT Notes" describing how the user needs expressed in Intent are addressed in the non-web contexts of non-web documents & non-web software.
> 

GV2: agreed.     Now to find the time.  

> 
> Peter
> 
> 
>> 
>>> 
>>> 
>>> Peter
>>> 
>>> 
>>> On 9/14/2012 5:04 AM, Gregg Vanderheiden wrote:
>>>> 
>>>> We have just 4 success criterion left.   And I think we are overthinking ourselves.
>>>> 
>>>> Taking a cue from Mike -- we need to take a step back and look at what it is that we are trying to do.  Substituting individual words works for much but not all.    But if we look at the objective of the success criteria -- and we look at the fact that 
>>>> Web Apps often (usually?) are just a single web page -  then we can equate  "software" with "web page" in many places.  
>>>> "web page in a set of web pages" also often (usually?) is intended to apply to a set of pages that work as an entity on the web.  So the equiv of "web page in a set of web pages" for these SC would also be "software" (or document).
>>>> 
>>>> this then leads us to something like the following  (Which I have put into the worksite as proposals.
>>>> 
>>>> but look at them here and we may be able to close these.
>>>> 
>>>>  Replace “web pages” with “documents” and “software”
>>>> 
>>>> We have just 4 success criterion outstanding
>>>>  
>>>>  2.4.1  Bypass Blocks: A mechanism is available to bypass blocks of content that are repeated on multiple Web pages.
>>>> 
>>>> Replace “ multiple web pages” with “in a document” and  “in software"
>>>> Note that the INTENT section of WCAG already says:
>>>> 
>>>> “Examples of repeated blocks of content include but are not limited to navigation links, heading graphics, and advertising frames. Small repeated sections such as individual words, phrases or single links are not considered blocks for the purposes of this provision”
>>>> 
>>>>  
>>>> 
>>>> 2.4.2: Page Titled: Web pages have titles that describe topic or purpose.
>>>> 
>>>>  Replace “web pages” with “documents” and “software”
>>>> 
>>>> Note that web pages are often full applications,  so a software application would be parallel.
>>>> 
>>>>  
>>>> 
>>>> 2.4.5: Multiple Ways:  More than one way is available to locate a Web page within a set of Web pages except where the Web Page is the result of, or a step in, a process.
>>>> 
>>>> replacing "web pages" with "documents" and replacing "set of web pages" with "set of documents"
>>>> replacing "web pages" with "software products" and replacing "set of web pages" with "set of software products"
>>>> NOTES:
>>>> 
>>>> 1.     A set of documents (or software products) is a group of documents (or software products) that are
>>>> 
>>>> 1.     published together, and
>>>> 
>>>> 2.     labeled as a set within at least one of the member documents (or software products).
>>>> 
>>>> 
>>>> 
>>>> 2.     Republishing or bundling previously published documents or software products as a collection does not constitute a set of documents. (i.e. They do not become a set if bundled but not originally published as a set)
>>>> 
>>>> 3.     A set that is broken apart and distributed is no longer a set.
>>>> 
>>>> 4.     A file directory would be the equivalent of a site map for documents (or software products) in that it provides a link to each of the documents (software products) in the set of documents (software products).  The directory also acts as the HOME for the set.
>>>> 
>>>> 5.     A search function in an operating systems (that finds documents or software products) would be equivalent to a web search function for web pages.
>>>> 
>>>> 6.     Authors can assume that the non-web documents or software products will be stored and accessed on a major operating system with browse and search abilities unless they have specific information to the contrary.
>>>> 
>>>> Final note to those evaluating 2.4.5:
>>>> 
>>>> Although this provision is easily met, it is not always met.  The presence of this success criteria also makes it easier for people creating support materials to later include a wide range of advisory techniques that, while not always applicable, would
>>>> 
>>>>  
>>>> 
>>>> 3.2.3: Consistent Navigation: Navigational mechanisms that are repeated on multiple Web pages within a set of Web pages occur in the same relative order each time they are repeated, unless a change is initiated by the user.
>>>> 
>>>> Replace “multiple Web pages within a set of Web pages”  with “in documents” and “in software”
>>>>  
>>>> 
>>>> And ask WCAG to add the following or something like it to the Understanding WCAG 2.0 document
>>>> 
>>>> "In this success criteria the term 'navigation mechanisms' is meant to refer to active lists of standard (not user generated) locations in the content that are provided by the author and that, when activated, cause the user to move to that particular standard location. 
>>>> 
>>>>     Navigation bars, a pull down menu that jumps you to different locations, and a set of tabs provided by the author, would be examples.   
>>>> 
>>>>     The following may be used for navigation but are not included in what is meant by navigation mechanisms in this success criterion :  escape keys, arrow keys, page down keys, headers that are only in the text of the document, tabs that a user creates or re-orders (because they are initiated by the user), the OK and Cancel buttons on a dialog (don't take you to consistent locations)."
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> -- 
>>> <oracle_sig_logo.gif>
>>> Peter Korn | Accessibility Principal
>>> Phone: +1 650 5069522 
>>> 500 Oracle Parkway | Redwood City, CA 94065 
>>> <green-for-email-sig_0.gif> Oracle is committed to developing practices and products that help protect the environment
>> 
> 
> -- 
> <oracle_sig_logo.gif>
> Peter Korn | Accessibility Principal
> Phone: +1 650 5069522 
> 500 Oracle Parkway | Redwood City, CA 94065 
> <green-for-email-sig_0.gif> Oracle is committed to developing practices and products that help protect the environment

Received on Monday, 17 September 2012 22:08:57 UTC