W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > April to June 2017

Re: Low Vision and COGA should Drop Support for WCAG 2.1 if the AG WG is not willing make real change.

From: Joshue O Connor <josh@interaccess.ie>
Date: Fri, 07 Apr 2017 09:53:48 +0100
Message-ID: <58E7539C.4020904@interaccess.ie>
To: "Patrick H. Lauke" <redux@splintered.co.uk>
CC: w3c-wai-gl@w3.org
I'm glad to see this thread diverge from its original content.

Please initiate/use separate threads to continue this conversation.

Thanks

Josh

> Patrick H. Lauke <mailto:redux@splintered.co.uk>
> 7 April 2017 at 08:29
>
>
> Part of me thinks this is inherent with the way (or perhaps the 
> perception of the way) W3C/WAI works, with task forces, membership to 
> working groups, invited experts etc, rather than working completely in 
> the open / open to all (while of course there's no hard door slam for 
> non-members, it's still the impression that the average developer may 
> have...and it's exemplified by having a First *Public* Working Draft, 
> which suggests any previous work was no "public").
>
> P
> Jonathan Avila <mailto:jon.avila@ssbbartgroup.com>
> 7 April 2017 at 03:59
>
> I’ll throw in my two cents – what has been most frustrating for me has 
> been that we have been working on these criteria for over 3 years in 
> the case of the mobile task force and we solicited help from all W3C 
> members and welcomed invited experts to the table.  Unfortunately some 
> of the larger companies that now are raising concerns did not jump in 
> before now even though we requested and welcomed their assistance.  
> These companies have the ability to dedicate resources to this task 
> and we could be further along now and have less at risk success 
> criteria had some of these organizations with concerns come to the 
> table sooner.  At each stage over the last three years as new people 
> have come into the TFs and lists we have to repeat and reiterate the 
> same concerns and arguments over several times and go back and forth 
> over wording sometimes reverting back to what we had before.  
> Releasing the WCAG 2.1 FPWD certainly received more high level 
> attention than original mobile TF note in my opinion and finally 
> brought out the stakeholders that we needed access to and dialog with 
> all along.
>
> Best Regards,
>
> Jonathan
>
> Jonathan Avila
>
> Chief Accessibility Officer
>
> SSB BART Group
>
> jon.avila@ssbbartgroup.com <mailto:jon.avila@ssbbartgroup.com>
>
> 703.637.8957 (Office)
>
> Visit us online: Website <http://www.ssbbartgroup.com/> | Twitter 
> <https://twitter.com/SSBBARTGroup> | Facebook 
> <https://www.facebook.com/ssbbartgroup> | LinkedIn 
> <https://www.linkedin.com/company/355266?trk=tyah> | Blog 
> <http://www.ssbbartgroup.com/blog/>
>
> /Download our CSUN Presentations Here!/ 
> <http://info.ssbbartgroup.com/CSUN-2017_Gateway-Sig-Slide-Decks-2017.html>
>
> The information contained in this transmission may be attorney 
> privileged and/or confidential information intended for the use of the 
> individual or entity named above. If the reader of this message is not 
> the intended recipient, you are hereby notified that any use, 
> dissemination, distribution or copying of this communication is 
> strictly prohibited.
>
> *From:*John Foliot [mailto:john.foliot@deque.com]
> *Sent:* Thursday, April 06, 2017 1:40 PM
> *To:* Michael Pluke
> *Cc:* GLWAI Guidelines WG org; Wayne Dick
> *Subject:* Re: Low Vision and COGA should Drop Support for WCAG 2.1 if 
> the AG WG is not willing make real change.
>
> > I think what Wayne is suggesting is similar to the extension model.
>
> ​>​
>
> ​> In other words, basic wcag 2.1 address some disabilities  well, 
> with some benefits for other disabilities. People should use the 
> extensions when it is important to include everyone.
>
> Hi Lisa,
>
> I would strongly oppose any return to piecemeal "extensions" such as 
> that, which will have the net effect of both ghetto-izing impacted 
> user-groups, as well as essentially ensuring that *NONE* of those 
> extended SC will be taken up by larger organizations. You would also 
> likely find that regulatory bodies would also 'discount' the 
> extensions as "supplemental" as well (witness what happened to AAA 
> SC), and may very-well not gain the force of any regulatory backing. I 
> fail to see how that would benefit those core constituencies.
>
> This was the argument presented 14 months ago when we shifted 
> direction of this WG towards a dot.extension evolution, and while this 
> WG can continue to debate the wisdom of our change of direction taken 
> last summer (which included a re-chartering that took our attention 
> and focus away from other important activities), please note that I 
> for one will protest quite strongly if we start second or 
> third-guessing ourselves and seek to return to the previous model of 
> 'extensions'.
>
> **********
>
> > Right now I live in a country that has a policy that leaves me out.
>
> Hi Wayne,
>
> While this is indeed concerning, what can the W3C do about this? That 
> is a serious queston.
>
> The W3C, and the AG WG, are not regulatory bodies; this group can 
> neither grant nor remove "rights", nor can it claim to be establishing 
> a legal requirement anywhere - that is up to governments and other 
> regulatory bodies to do. The W3C did not make WCAG part of the 
> refreshed Section 508 (if they could have done that, I don't think 
> they would have waited 16 years to do so) - it was the US Federal 
> Government and their internal processes that both delayed the 
> adoption, and also mandates specific entities to compliance - the W3C 
> isn't in that game.
>
> > With that admission, people with these disabilities could then 
> proceed to devise guidelines that would help us without the 
> interference of WAI.
>
> Interference? Hang on a minute... there is absolutely *NOTHING* that 
> restricts user-groups of any stripe to go off and make their own 
> guidelines and recommendations elsewhere. Choosing to do so inside of 
> the W3C has supplemental benefits, but there is nothing stopping you 
> from writing the "Wayne Dick Web Accessibility Guidelines" - anyone 
> could do similar. The trick is getting those recommendations adopted 
> by developers at scale - and eventually (one presumes) entrenched in 
> laws and regulations. Failing to achieve _that_ is simply an exercise 
> in wishing and hoping.
>
> The advantage of doing this work inside of the W3C is that it has 
> wider review and input, and whatever finished product we arrive at 
> will be looked at with serious intent, because it is being published 
> by an entity with a history and pedigree.
>
> However, getting published at the W3C has its costs as well, and one 
> of those costs is that you can't always get everything you want - 
> every stakeholder must be listened to and their concerns need to be 
> understood and addressed as well. Consensus and compromise are 
> critical here, yet repeatedly some members of both COGA and LV 
> approach this list and process as an us-versus-them activity, and then 
> take on the position of aggrieved party who are being ignored or 
> turned away.
>
> > This discussion is upsetting.
>
> You're darned right it is.
>
> A large number of people from all kinds of backgrounds dedicate (often 
> unpaid volunteer) time and effort to work on this activity, towards a 
> shared common goal - making the web *more* accessible (and not 
> "perfectly accessible"), and rants, diatribes, and accusations that 
> some of us are simply leaving LV (or COGA) folk behind is 
> counter-productive. When somebody like myself or others point out 
> problems, it is not because we don't want to succeed, in fact quite 
> the opposite - if I can see a problem, I'll bet a tidy sum others will 
> as well (go look at some of the feedback we've received from 
> non-participants so far).
>
> Most of us understand the frustration being expressed here, but I will 
> politely suggest you are "dumping" on the wrong people - we've all 
> shown up here to try and make things better, not worse, and suggesting 
> otherwise is simply slamming the door in the face of your friends.
>
> A case in point was on our teleconference today, where I actually was 
> pushing back on minimum target sizes and what happens when it 
> introduces horizontal scroll (because, honestly and truthfully, I've 
> heard you say how that - at least as I hear it - is the single largest 
> issue that LV users grapple with - because you did the research and 
> shared it with us).
>
> But I've yet to hear a solution to the problem I presented: an 
> onscreen keyboard with 10 "keys" across the first row @ 44px will 
> scroll horizontally on many mobile devices, and "reflowing" the 
> keyboard keys breaks a visual convention (likely bad for COGA, and 
> will simply not be taken up by web designers, who already feel 
> 'constrained' by some of our requirements). As I noted on the call, 
> this is a King Solomon decision/problem, because personally I cannot 
> see a way out today, but in the context of this email, note that I 
> actually stood up for one of the LVTF's larger issues - so accusations 
> that this group doesn't care or isn't willing to address LV concerns 
> is simply untrue.
>
> This is hard, there is no question about it, but hard-line responses 
> without some degree of flexibility will likely be met with the equal 
> force of resistance, if not within this working group, certainly in 
> the wider world of non-expert developers and their senior administrators.
>
> As a former manager used to say to me, we cannot let perfect be the 
> enemy of good, and I will suggest that this is a very good idea to 
> keep in mind as we continue to move forward.
>
> Respectfully,
>
> JF
>
> On Thu, Apr 6, 2017 at 11:11 AM, Michael Pluke 
> <Mike.Pluke@castle-consult.com <mailto:Mike.Pluke@castle-consult.com>> 
> wrote:
>
> If this debate continues, which I wish it would not, then we must keep 
> a sense of perspective. We shouldn't be making statements like "State 
> explicitly that Low vision and Cognitive disabilities are not 
> included" in WCAG 2.0 (or 2.1).
>
> When we created the European EN 301 549 standard we had a "Functional 
> Performance Statement" (FPS) titled "Usage with limited cognition" 
> which expressed the general need to meet the needs of persons with 
> cognitive disabilities. To help people interpret this we created a 
> table that mapped WCAG 2.0 SCs to these FPSs. Therefore, long before 
> this controversy exploded we identified 17 SCs that directly supported 
> the needs of people with cognitive disabilities and a further 15 that 
> provided some secondary benefits. Although this mapping was not a 
> mandatory part of the standard, and therefore it may have received 
> less scrutiny, nobody challenged this mapping during the extensive 
> reviewing of the standard. The identification of which SCs were 
> beneficial was largely done by looking at "Understanding WCAG" 
> statements that explained how an SC was beneficial.
>
> On this basis, saying that cognitive disabilities are not included in 
> WCAG 2.0 is very badly misleading.
>
> I'm sure that there is universal acceptance that there will be 
> significant accessibility barriers that people with Low Vision and 
> Cognitive Disabilities will still encounter, after WCAG 2.1 is 
> completed. Knowing this is one thing, being able to draft SCs that 
> solve these issues is a much more challenging task. However abandoning 
> 2.1, which should enhance overall accessibility for a wide range of 
> users, would benefit precisely nobody.
>
> Currently very many countries around the world incorporate WCAG 2.0 
> into their laws in order to ensure that public sector websites meet 
> the minimum level of accessibility that WCAG 2.0 should guarantee. At 
> least in Europe, there is a desire to incorporate WCAG 2.1 into the 
> law related to public sector websites and mobile applications. If WCAG 
> 2.1 included SCs that fail to adhere to the agreed (and well 
> understood and accepted) criteria that the text of an SC must meet, I 
> am certain that this would lead to a rejection of WCAG 2.1 and a 
> reversion to WCAG 2.0. Again, as I said in my earlier email, who is 
> going to benefit from that - precisely nobody.
>
> If we are totally unable to create enough LV and COGA SCs that meet 
> the necessary criteria, then we may need to see how the good guidance 
> that we have already identified can be packaged in a form that may be 
> able to influence the design of content that is more LV and COGA 
> friendly. But this would be in addition to WCAG 2.1, not instead of. 
> In Europe we have already created a guidelines document related to 
> COGA and ISO are also heading towards their own guidance standard for 
> COGA.
>
> Mike
>
> Get Outlook for iOS <https://aka.ms/o0ukef>
>
> _____________________________
> From: Wayne Dick <wayneedick@gmail.com <mailto:wayneedick@gmail.com>>
> Sent: Wednesday, April 5, 2017 11:51 pm
> Subject: Low Vision and COGA should Drop Support for WCAG 2.1 if the 
> AG WG is not willing make real change.
> To: GLWAI Guidelines WG org <w3c-wai-gl@w3.org <mailto:w3c-wai-gl@w3.org>>
>
>
>
> The assumptions of WCAG 2.0 cannot support low vision or cognitive 
> disabilities in ways essential to access.  A page can pass WCAG 2.0 at 
> level AAA and fail to be usable by people with low vision and 
> cognitive disabilities.
>
> WCAG 2.0 did worse than nothing for low vision and cognitive 
> disabilities. It created the illusion that we were helped when we were 
> being left out. This may be hard to accept if you worked hard on WCAG 
> 2.0. However, it is time to accept this fact and start solving the 
> problem.
>
> There is no point of 2.1 continuing the false illusion that it 
> provides meaningful help, when it does not.
>
> Low vision needs a few fundamental things. Personalization of text: 
> font-family, spacing, color. The precise limits are these: any font 
> family the user chooses, spacing that has been proven to be useful, 
> and 16M colors. We need ability to enlarge significantly at least  
> 400% with word wrapping. We need single column access. That is what is 
> needed. If the WCAG 2.0 assumptions cannot support this need then we 
> need to change the assumptions.
>
> I am sure there are similar bedrock issues for Cognitive Disabilities.
>
> The basic idea of accessibility for a disability is that a person with 
> the disability can use the resource. Right now WCAG does not support 
> access for the majority of people with visual disabilities and most 
> people with cognitive disabilities. That is just a fact. COGA and LVTF 
> have documented this decisively.
>
> ​ If the AG cannot change some WCAG 2.0 assumptions then would the W3C 
> just stop claiming they make guidelines that provide access to people 
> with disabilities when it fails to do so. Just say the WAI gives 
> guidance on how to help some disabilities​. State explicitly that Low 
> vision and Cognitive disabilities are not included.
>
> With that admission, people with these disabilities could then proceed 
> to devise guidelines that would help us without the interference of WAI.
>
> Right now WAI is harming these disabilities because developers and 
> legislators believe that if they follow the WCAG guidelines than most 
> disabilities are covered. This is false. Low Vision and Cognitive 
> Disabilities are not covered.
>
> The WAI just failed these disabilities. Live with it. WAI can do 
> something about it, live in denial, or leave the field to people who 
> know how to help.
>
>
>
> -- 
>
> John Foliot
>
> Principal Accessibility Strategist
>
> Deque Systems Inc.
>
> john.foliot@deque.com <mailto:john.foliot@deque.com>
>
> Advancing the mission of digital accessibility and inclusion
>
> John Foliot <mailto:john.foliot@deque.com>
> 6 April 2017 at 18:40
> > I think what Wayne is suggesting is similar to the extension model.
> ​>​
> ​> In other words, basic wcag 2.1 address some disabilities  well, 
> with some benefits for other disabilities. People should use the 
> extensions when it is important to include everyone.
>
> Hi Lisa,
>
> I would strongly oppose any return to piecemeal "extensions" such as 
> that, which will have the net effect of both ghetto-izing impacted 
> user-groups, as well as essentially ensuring that *NONE* of those 
> extended SC will be taken up by larger organizations. You would also 
> likely find that regulatory bodies would also 'discount' the 
> extensions as "supplemental" as well (witness what happened to AAA 
> SC), and may very-well not gain the force of any regulatory backing. I 
> fail to see how that would benefit those core constituencies.
>
> This was the argument presented 14 months ago when we shifted 
> direction of this WG towards a dot.extension evolution, and while this 
> WG can continue to debate the wisdom of our change of direction taken 
> last summer (which included a re-chartering that took our attention 
> and focus away from other important activities), please note that I 
> for one will protest quite strongly if we start second or 
> third-guessing ourselves and seek to return to the previous model of 
> 'extensions'.
>
> **********
>
> > Right now I live in a country that has a policy that leaves me out.
>
> Hi Wayne,
>
> While this is indeed concerning, what can the W3C do about this? That 
> is a serious queston.
>
> The W3C, and the AG WG, are not regulatory bodies; this group can 
> neither grant nor remove "rights", nor can it claim to be establishing 
> a legal requirement anywhere - that is up to governments and other 
> regulatory bodies to do. The W3C did not make WCAG part of the 
> refreshed Section 508 (if they could have done that, I don't think 
> they would have waited 16 years to do so) - it was the US Federal 
> Government and their internal processes that both delayed the 
> adoption, and also mandates specific entities to compliance - the W3C 
> isn't in that game.
>
> > With that admission, people with these disabilities could then 
> proceed to devise guidelines that would help us without the 
> interference of WAI.
>
> Interference? Hang on a minute... there is absolutely *NOTHING* that 
> restricts user-groups of any stripe to go off and make their own 
> guidelines and recommendations elsewhere. Choosing to do so inside of 
> the W3C has supplemental benefits, but there is nothing stopping you 
> from writing the "Wayne Dick Web Accessibility Guidelines" - anyone 
> could do similar. The trick is getting those recommendations adopted 
> by developers at scale - and eventually (one presumes) entrenched in 
> laws and regulations. Failing to achieve _that_ is simply an exercise 
> in wishing and hoping.
>
> The advantage of doing this work inside of the W3C is that it has 
> wider review and input, and whatever finished product we arrive at 
> will be looked at with serious intent, because it is being published 
> by an entity with a history and pedigree.
>
> However, getting published at the W3C has its costs as well, and one 
> of those costs is that you can't always get everything you want - 
> every stakeholder must be listened to and their concerns need to be 
> understood and addressed as well. Consensus and compromise are 
> critical here, yet repeatedly some members of both COGA and LV 
> approach this list and process as an us-versus-them activity, and then 
> take on the position of aggrieved party who are being ignored or 
> turned away.
>
> > This discussion is upsetting.
>
> You're darned right it is.
>
> A large number of people from all kinds of backgrounds dedicate (often 
> unpaid volunteer) time and effort to work on this activity, towards a 
> shared common goal - making the web *more* accessible (and not 
> "perfectly accessible"), and rants, diatribes, and accusations that 
> some of us are simply leaving LV (or COGA) folk behind is 
> counter-productive. When somebody like myself or others point out 
> problems, it is not because we don't want to succeed, in fact quite 
> the opposite - if I can see a problem, I'll bet a tidy sum others will 
> as well (go look at some of the feedback we've received from 
> non-participants so far).
>
>
>
> Most of us understand the frustration being expressed here, but I will 
> politely suggest you are "dumping" on the wrong people - we've all 
> shown up here to try and make things better, not worse, and suggesting 
> otherwise is simply slamming the door in the face of your friends.
>
> A case in point was on our teleconference today, where I actually was 
> pushing back on minimum target sizes and what happens when it 
> introduces horizontal scroll (because, honestly and truthfully, I've 
> heard you say how that - at least as I hear it - is the single largest 
> issue that LV users grapple with - because you did the research and 
> shared it with us).
>
> But I've yet to hear a solution to the problem I presented: an 
> onscreen keyboard with 10 "keys" across the first row @ 44px will 
> scroll horizontally on many mobile devices, and "reflowing" the 
> keyboard keys breaks a visual convention (likely bad for COGA, and 
> will simply not be taken up by web designers, who already feel 
> 'constrained' by some of our requirements). As I noted on the call, 
> this is a King Solomon decision/problem, because personally I cannot 
> see a way out today, but in the context of this email, note that I 
> actually stood up for one of the LVTF's larger issues - so accusations 
> that this group doesn't care or isn't willing to address LV concerns 
> is simply untrue.
>
> This is hard, there is no question about it, but hard-line responses 
> without some degree of flexibility will likely be met with the equal 
> force of resistance, if not within this working group, certainly in 
> the wider world of non-expert developers and their senior administrators.
>
> As a former manager used to say to me, we cannot let perfect be the 
> enemy of good, and I will suggest that this is a very good idea to 
> keep in mind as we continue to move forward.
>
> Respectfully,
>
> JF
>
>
>
>
>
> -- 
> John Foliot
> Principal Accessibility Strategist
> Deque Systems Inc.
> john.foliot@deque.com <mailto:john.foliot@deque.com>
>
> Advancing the mission of digital accessibility and inclusion
> Michael Pluke <mailto:Mike.Pluke@castle-consult.com>
> 6 April 2017 at 17:11
> If this debate continues, which I wish it would not, then we must keep 
> a sense of perspective. We shouldn't be making statements like "State 
> explicitly that Low vision and Cognitive disabilities are not 
> included" in WCAG 2.0 (or 2.1).
>
> When we created the European EN 301 549 standard we had a "Functional 
> Performance Statement" (FPS) titled "Usage with limited cognition" 
> which expressed the general need to meet the needs of persons with 
> cognitive disabilities. To help people interpret this we created a 
> table that mapped WCAG 2.0 SCs to these FPSs. Therefore, long before 
> this controversy exploded we identified 17 SCs that directly supported 
> the needs of people with cognitive disabilities and a further 15 that 
> provided some secondary benefits. Although this mapping was not a 
> mandatory part of the standard, and therefore it may have received 
> less scrutiny, nobody challenged this mapping during the extensive 
> reviewing of the standard. The identification of which SCs were 
> beneficial was largely done by looking at "Understanding WCAG" 
> statements that explained how an SC was beneficial.
>
> On this basis, saying that cognitive disabilities are not included in 
> WCAG 2.0 is very badly misleading.
>
> I'm sure that there is universal acceptance that there will be 
> significant accessibility barriers that people with Low Vision and 
> Cognitive Disabilities will still encounter, after WCAG 2.1 is 
> completed. Knowing this is one thing, being able to draft SCs that 
> solve these issues is a much more challenging task. However abandoning 
> 2.1, which should enhance overall accessibility for a wide range of 
> users, would benefit precisely nobody.
>
> Currently very many countries around the world incorporate WCAG 2.0 
> into their laws in order to ensure that public sector websites meet 
> the minimum level of accessibility that WCAG 2.0 should guarantee. At 
> least in Europe, there is a desire to incorporate WCAG 2.1 into the 
> law related to public sector websites and mobile applications. If WCAG 
> 2.1 included SCs that fail to adhere to the agreed (and well 
> understood and accepted) criteria that the text of an SC must meet, I 
> am certain that this would lead to a rejection of WCAG 2.1 and a 
> reversion to WCAG 2.0. Again, as I said in my earlier email, who is 
> going to benefit from that - precisely nobody.
>
> If we are totally unable to create enough LV and COGA SCs that meet 
> the necessary criteria, then we may need to see how the good guidance 
> that we have already identified can be packaged in a form that may be 
> able to influence the design of content that is more LV and COGA 
> friendly. But this would be in addition to WCAG 2.1, not instead of. 
> In Europe we have already created a guidelines document related to 
> COGA and ISO are also heading towards their own guidance standard for 
> COGA.
>
> Mike
>
> Get Outlook for iOS <https://aka.ms/o0ukef>
> Wayne Dick <mailto:wayneedick@gmail.com>
> 5 April 2017 at 23:50
> The assumptions of WCAG 2.0 cannot support low vision or cognitive 
> disabilities in ways essential to access.  A page can pass WCAG 2.0 at 
> level AAA and fail to be usable by people with low vision and 
> cognitive disabilities.
>
> WCAG 2.0 did worse than nothing for low vision and cognitive 
> disabilities. It created the illusion that we were helped when we were 
> being left out. This may be hard to accept if you worked hard on WCAG 
> 2.0. However, it is time to accept this fact and start solving the 
> problem.
>
> There is no point of 2.1 continuing the false illusion that it 
> provides meaningful help, when it does not.
>
> Low vision needs a few fundamental things. Personalization of text: 
> font-family, spacing, color. The precise limits are these: any font 
> family the user chooses, spacing that has been proven to be useful, 
> and 16M colors. We need ability to enlarge significantly at least  
> 400% with word wrapping. We need single column access. That is what is 
> needed. If the WCAG 2.0 assumptions cannot support this need then we 
> need to change the assumptions.
>
> I am sure there are similar bedrock issues for Cognitive Disabilities.
>
> The basic idea of accessibility for a disability is that a person with 
> the disability can use the resource. Right now WCAG does not support 
> access for the majority of people with visual disabilities and most 
> people with cognitive disabilities. That is just a fact. COGA and LVTF 
> have documented this decisively.
>
> ​If the AG cannot change some WCAG 2.0 assumptions then would the W3C 
> just stop claiming they make guidelines that provide access to people 
> with disabilities when it fails to do so. Just say the WAI gives 
> guidance on how to help some disabilities​. State explicitly that Low 
> vision and Cognitive disabilities are not included.
>
> With that admission, people with these disabilities could then proceed 
> to devise guidelines that would help us without the interference of WAI.
>
> Right now WAI is harming these disabilities because developers and 
> legislators believe that if they follow the WCAG guidelines than most 
> disabilities are covered. This is false. Low Vision and Cognitive 
> Disabilities are not covered.
>
> The WAI just failed these disabilities. Live with it. WAI can do 
> something about it, live in denial, or leave the field to people who 
> know how to help.
>

-- 
Joshue O Connor
Director | InterAccess.ie
Received on Friday, 7 April 2017 08:54:29 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 21:08:12 UTC