Errata/clarification of 2.2.1 Timing Adjustable extension #1040
Conversation
Based on the discussion in https://lists.w3.org/Archives/Public/w3c-wai-gl/2020JanMar/0161.html this is a first attempt at making it more explicit what the confusing "at least ten times" means. It appears this has been misinterpreted by some as "ten times" meaning that a site needs to provide ten separate warnings/options to extend, when in fact it appears this, like the previous point about adjusting timing, is meant as "ten times the length of time".
|
happy for people to take the language here and refine this initial attempt, for clarity. we'd also likely want to clarify this point further in the understanding document |
|
Is it possible to change the SCs? |
|
if it doesn't change the meaning (and, from the discussion, this was indeed the intended meaning), then yes - it's just clarifying what the intent of the SC has always been, but has been misunderstood by some, it does not introduce any new/changed requirements. |
|
like the addition, the "either in one extension" part was not on my radar till now |
likewise. i literally interpreted it in the "they're given at least 10 individual opportunities, regardless of how long each one is" sense. which in hindsight yeah, is odd...but there we are |
|
I'm fine with it |
alastc
added
ErratumRaised
|
-1 because the exception for extending ten times does not mean that the total time-out duration is ten times longer. For example, supposed the default time out is an hour. After the hour, the person is given 20 seconds to ask for five minutes more. This offer of 20 seconds for 5 minutes more is repeated ten times but, in the end (at the most), the person only ends up with an hour and fifty minutes (not ten hours). So this scenario passes original 2.2.1 but not the proposed re-write. It seems to me that this option would be important for some metered (or otherwise closely monitored) web services. It would be a bother to have to re-authenticate/re-initiate the service, but there could be business case reason for asking the user to log back into the queue from scratch. I agree that this SC could use some editorial clean-up. |
when i asked in the email thread about clarification, the consensus there seemed to be that no, this WAS in fact the intended meaning at the time. so i'm confused now...which is it? (and yes, the fact that AGWG is confused about this is not a good sign) |
|
also, to take it ad absurdum ... what if they are given 10 opportunities to extend, but each time they can only extend by a second? it would pass this other interpretation (that the "10 times" refers to opportunities, rather than duration), but help absolutely nobody. and i have a hard time believing that no, THIS was in fact the intended meaning. because otherwise, we have even more problems than anticipated... (but the fact that the understanding doc then talks about the choice of "10 times the length" in general does seem to lend credence to what was said, that the intention was indeed that the "10 times" also refers to total duration, not number of opportunities) |
Sorry to have missed that email thread!
I don't think that is correct. My recollection is that we had one exception (ten times for ten time the duration) and decided to split them out to be either/or. But after that, we still ended up adding the essential exception, which I disagreed with (and still do). It seems to me that the essential exception is too big a loophole, and that the Adjust and Extend should be enough to keep the security folks happy. |
|
if "10 times" there was meant as "10 individual opportunities to extend", then this example of a pass in the understanding document would fail...
"some number of times". needs to be at least 10 then. again, I for one remain unconvinced about what the actual intent was. but if it was indeed "10 times" meant as 10 opportunities, then not giving them any time length either just leaves a giant gap for "passing the letter, rather than the spirit" of the SC |
No, but because maybe this was meant as an example of the Real-time Exception? I agree that this Understanding document should go through another editorial review as well. |
So long as the person has twenty seconds for each of those requests for one more second, then it does pass the SC! We have had other conversations about SC phrasing allowing for "malicious compliance". As with this example, those have all been so absurd that they do not trouble me. |
good for you, a solid foundation for a solid standard... |
|
I don't think it is possible to write well enough to preclude malicious compliance. Not that we shouldn't try a little! I don't agree that 2.2.1 should require extending the timeout duration by a whole multiple for each of ten user requests. I am open to the idea that we might want to specify a minimum timeout duration for each user request. |
this rewrite proposes the the cumulative extension be at least 10 times the original length (similar to the adjust). it does not say that there must be ten user requests per se. there can be a single one, or 100...but that the end result be that one way or another users can achieve a total extension of 10 times the default length. |
I do not agree with this proposed edit. The original length might be quite generous (e.g., days), so a requirement to extend to ten times the original length is not reasonable..
That might be a more attractive approach for the developer, especially if the original timeout has a long duration, so why preclude this option? The user experience can still be good. |
as mentioned on the mailing list, if it was that long, it would satisfy the "20 Hour Exception: The time limit is longer than 20 hours" and not have to provide any adjustment nor extension
I am not "precluding" the option. I'm just not setting a hard limit of ten, saying it can be as many or as few as necessary. |
|
Okay, I am sorry I gave the example of days in my comment immediately above. My first counter-example:
IMHO, this scenario is not something that 2.2.1 should preclude, and nor was it meant to. |
|
if it's deemed ok for a site with a 1h timeout to offer 10 extensions that come, in total, to a maximum time of 1h 50m, then why if the same site wanted to offer the option to adjust instead, it is required to provide an adjustment of a total of 10h or it fails? and to point out: these aren't just academic little thought experiments. these are the sorts of questions we get from actual developers who may honestly be trying to do the right thing by WCAG, but not quite understanding what the apparent logic there is...or similarly, these are questions from clients who we do an audit for, wondering why their solution was failed, and us having to try and give some sane explanation for something like the above, coupled with a "well, what can ya do?" shrug |
|
Because, as with some other SC, we give the developer several choices as to how they address the user need. Presumably, the developer picks the one that is easiest for them to implement, given their environmental constraints. Maybe a site has no means to provide for an Extend option at all. That might be a reasonable assertion. (Maybe they are using a third party service?) They at least should be able to use Turn Off or Adjust, both of which include prior notification -- but not interactive at-the-time-of-timeout notification. In general, since interactive-as-it-happens notification is a better user experience (for everyone), it makes sense that the use of the Adjust exception is associated with a longer time duration than the Extend exception. |
|
but the point is not the difference between interactive and non-interactive. it's between "if non-interactive, must be able to adjust to at least 10 times the default" vs "if interactive, it just needs to provide at least 10 instances/opportunities, regardless of how much i can extend it in the end". the user need is "they need more time". why should one method of achieving this, which results in them being given far less time, and is more complex to achieve, be equivalent in one that gives them 10x more time and is likely easier to achieve? anyway...i'll let others jump in, but this is weird logic. and it's not about removing choices from developers. it's giving clearer parameters to developers about how long an extension should be to provide users with sufficient time. |
|
also, "turn off", "adjust" and "extend" are not "exceptions". they're ways in which the SC can be satisfied. "real-time exception", "essential exception" "20 hour exception" are exceptions. |
|
Thanks Andrew
This reinforces the fact that the discussion was about extensions that were the length of the default (or longer).
In the end it was set at 10 times the default — as David said in his Friday email where he says that he clearly remembered that as the meaning of the final wording. This confirms what Christophe and I have said we also remember clearly.
So yes - this would be non-normative edit to clarify the meaning of the 3rd bullet ( which might be a good idea since apparently has been mis-read - or mis-applied by some. )
gregg
———————————
Professor, University of Maryland, College Park
Founder and Director Emeritus , Trace R&D Center, UMD
Co-Founder Raising the Floor. http://raisingthefloor.org
The Global Public Inclusive Infrastructure (GPII) http://GPII.net
The Morphic project https://morphic.org
… On Aug 14, 2022, at 3:01 PM, Andrew Kirkpatrick ***@***.***> wrote:
RE: What does the language in 2.2.1 mean. What was the consensus of the group at the time it was adopted?
The provision means what it did when it was written. If there is a different opinion now - then it would be a normative change to change it. (A normative weakening change.)
Changing the 3rd bullet ("Extend") to add "default" into the text would be a normative change, and your opinion is this this is what the language means already, so I'm not sure why this would be a normative weakening change.
My belief, based on the words written in the Extend bullet, is that such a change would be a non-editorial normative strengthening change.
We have now heard from 3 of the most active members of the working group at that time that it was very clear what the meaning and intent of those words were.
Specifically
Users (who needed it) would have 10 times the typical time to respond - - either all at once (2nd bullet) or in stages (3rd bullet).
Action
IF there is any question - or if some people have misunderstood - we should add text to the SC, a note or the Understanding doc that clarifies what the language means.
Looking through the list archives, I'm not sure that it is as clear as you say. There are three members of the WG who are saying that the extend bullet means to repeat the time limit ten times, but David indicated in October 2005 that he felt that the timeline would be extended and that each of the extensions would be 10 times the original allowable time:
David wrote: "I'm not sure if our line about a maximum of 5 extensions (of which each is at least 10 times the original allowable time) should go in the Guide Doc or the SC of the Guidelines. Perhaps we can talk about that for a couple of minutes today." (https://lists.w3.org/Archives/Public/w3c-wai-gl/2005OctDec/0042.html <https://lists.w3.org/Archives/Public/w3c-wai-gl/2005OctDec/0042.html>)
I don't think that anyone would agree that the WG feels that the extend bullet requires a 100x increase in time, but there is no record of any discussion otherwise. There is no discussion about how the SC text became what it is today, and I have a hard time believing that the WG discussed the difference between 100x and 10x and decided that the bullet didn't need any text to clarify this.
RE: If bullet 3 meant 10 times default - why isnt that in bullet 3?
In hindsight - it is unfortunate that the same language about default in bullet 2 was not repeated in bullet 3. We missed that because we had just said it in bullet 2, and didnt see a need to repeat it again in the next variation/option on that bullet. We were thinking it was clear from that - and from the understanding document — that the intent was to give them a LOT more time.
It actually makes little sense to have two bullets as options where one requires 10 times the length and the next could be as little as 1.2 times the length based on discussions here. Why would you ever do bullet 2 if there was a bullet 3 that basically let you get out of providing much additional time — AND would bother the person with a cognitive disability by making them keep hitting the "extend" button and getting an extension much shorter than typical users needed.
I can't answer why it isn't, but it isn't. The reason that was mentioned about why the "extend" bullet was added in October 2005 at all was that some site owners would have concerns about leaving the session open for 10x the length of time. A site owner without such security concerns might prefer to handle the extension once rather than building in the support to allow people to do multiple extensions.
—
Reply to this email directly, view it on GitHub <#1040 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNGDXRPGGM7T23N77TH4CDVZFUBZANCNFSM4KRMQ3IA>.
You are receiving this because you were mentioned.
|
|
Sorry @GreggVan - that isn't the conclusion that I come to when I review the history. |
|
@GreggVan (et al.), it seems to me there are two choices for 2.2:
I don't see a path for 2.2.1 to have what, on its face, is a normative change. Likewise, an update to Understanding asserting that the SC must be read to mean ten times the default time limit will not go anywhere. (Because that would be using Understanding to make a normative change.) The only way to move the needle is (1). |
|
I have to say that I am disappointed that there is an effort to re-interpret this Level A cognitive-based guideline to make it much weaker.
I understand that there was genuine confusion about the wording at first - but by now it has been pretty well established what the proper/original interpretation was (that is, the meaning that the WG reached consensus on).
It was felt that it should be clear from the previous bullet - but there was also affirmation from three of the most active and detailed members of the WCAG at that time (including a co-chair) that the intent was to be 10 times the default length of time (either all at once - bullet 2, or in stages - bullet 3).
Also - one can derive it from logic "Why would the working group provide two alternatives where one is 10 time as much time and the second is as little as 10% - or less- additional time." That would be a huge loophole if it were true. Also the Understanding document talks about 10 times the response time.
As to talking about research into past discussions - there is no evidence from the past research to indicate the proposed re-interpretation. The fact that different things were discussed prior to deciding on the final language is typical. But none of the discussions that were cited talked about a version where it was 10 extensions of length less than the default time.
Since this discussion is starting to just restate positions rather than introduce anything new — this will be my last post on the topic unless a specific question is asked of me.
Since we have been talking about strengthening cognitive coverage - and this is at level A - I hope we can preserve it.
But I guess we will see what the WG thinks on survey - and - as always - I will defer to the decision of the working group.
Best
gregg
———————————
Professor, University of Maryland, College Park
Founder and Director Emeritus , Trace R&D Center, UMD
Co-Founder Raising the Floor. http://raisingthefloor.org
The Global Public Inclusive Infrastructure (GPII) http://GPII.net
The Morphic project https://morphic.org
… On Aug 15, 2022, at 8:00 AM, Bruce Bailey ***@***.***> wrote:
@GreggVan <https://github.com/GreggVan> (et al.), it seems to me there are two choices for 2.2:
Editorial change to Extend bullet of 2.2.1 (i.e., ten times to ten opportunities) to reinforce the plain reading of the SC. Among other advantages, this provide the opportunity for Understanding to emphasize that ten times the default time limit is a best practice.
Leave 2.2.1 alone, preserving the ambiguity that allows people to argue that ten time the time limit is how the SC must be read.
I don't see a path for 2.2.1 to have what, on its face, is a normative change. Likewise, an update to Understanding asserting that the SC must be read to mean ten times the default time limit will not go anywhere.
The only way to move the needle is (1).
—
Reply to this email directly, view it on GitHub <#1040 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNGDXUYK5CM6LDSJZDCLLLVZJLRJANCNFSM4KRMQ3IA>.
You are receiving this because you were mentioned.
|
|
Can anyone point to documented testing protocols that reinforce the ten-times default time duration? Edit to also ask: Has there been real world cases where ten opportunities to extend (less than 10x the default time) is a reported problem? Does anyone disagree the that most common pattern (with a 20+ sec prompt) is that there is essentially an unlimited number of opportunities to extend? DHS Trusted Tested and (the newer) ICT Baseline for Web have always interpreted ten opportunities for Extend. That understanding developed from conformance with the Original 508 Standards (2000) and 1194.22(p) which was not explicit.
Personally, I would like to see 508 adopt 2.2. I have some concern that changing 2.2.1 Extend (to retroactively mean ten times the default time) will complicate that. I also defer to the decision of the working group. |
There is nothing "retroactively" here. The change would be in 2.2, which is a new version. At the moment it feels like the interpretation is a coin toss as written (tho I never thought it made sense to say "extend by either 10 times the duration or 10 times the opportunity to extend a really short time). Websites/applications who extend 10 times and do not hit the 10 times default mark would still conform to WCAG 2.1 but would not to WCAG 2.2. That way it would also not matter a bit what was meant a long time ago, as there is nothing that gets changed in the past. |
Sure there is. Changing 2.2 2.2.1 to require 10 times the default time limit duration means that almost everyone has been reading the 2.0/2.1 2.2.1 SC wrong for fifteen years. |
|
@bruce-usab - Eric is suggesting that the change impact 2.2 only, so it is backward compatible with 2.0/2.1, thus the non-retroactive change. |
The proposal [for 10x duration on Extend] is either a (1) normative change or (2) it's non-normative clarification that almost everyone has been reading/implementing 2.2.1 incorrectly. Both of those choices are quite terrible.
As noted previously, this remain a purely hypothetical defect with the plain reading of the Extend bullet. |
So the argument is what? That we have to keep every SC the way it was because otherwise someone might become aware that the SC had two different readings and have their feelings hurt? My suggestion is the opposite: If you have read it as 10 times the default, you already complied to WCAG 2.2; if you read it as 10 times an undefined amount, you also read it correctly for WCAG 2.0 and 2.1, but 2.2 strengthens the SC and what the user needs.
Why is clarifying an SC “terrible”? The number of hours we have put in here alone, questioning what that one sentence might mean, or might have meant, or will mean in the future, shows that this needs clarification. Because I work with clients every day that say ”oh, I wanted to implement an SC but something can be read in multiple ways”. Adoption of SCs are simpler when the SCs are clear. That should be the goal.
OK, so if it is “purely hypothetical” (that we only have 180 or so comments on this thread about), then why have it not clear in 2.2? Let’s get rid of the hypothetical and make it straight forward to read! |
|
+1 to this sensible clarification which will make it clearer and better support people with disabilities, which is kinda the whole idea of WCAG no? |
Yes, exactly. We have to keep every SC the way it was. It is not about hurt feelings. There is very little appetite in AGWG for normative changes, and I am part of that institutional resistance.
Clarifying an SC is very good. Changing an SC is bad. Changing an SC while asserting the change is merely editorial is terrible.
Yes, and this thread reflects maybe 10% of the considered discussion around 2.2.1 Extend?
Agreed. I would very much like to have the Extend bullet clarified, but that will only happen if enough people are willing to acknowledge the plain reading.
I do agree that 10x duration is better than 10 opportunities for PWD. But there could be work to add that after acknowledging the plain reading of the SC as it exists now. Denial of the plain reading of the current SC is blocking progress. |
That has literally never happened and would make any and all standards unusable over time. There are many normative changes in WCAG 2.2, otherwise it would be WCAG 2.1. It should be in the interest of the Working Group to make their content easy to understand and not leave gaps for interpretation where possible. (That said, I have the feeling this type of feedback is unwelcome and if this wasn’t crucial I would keep my mouth shut as I have learned to do over the years.)
I don't think anyone denies the reading of the SC which says you have to be able to extend 10 times with a warning of 20 seconds.
That does not mean that it is neither nonsensical nor useful for users to do so. Unfortunately people want to apply common sense to WCAG, which means that they carry forward the 10 times the default requirement. And as we have seen some people initially involved intended it that way. Plus changing it in 2.2 does not deny the valid reading of 2.0/2.1 without that requirement. Indeed it acknowledges it. |
@yatil I think Bruce is distinguishing changes from additions here.
I don't think that anyone disagrees that this is the interest of the WG.
I think that the reason that this thread has gone on so long is that there are people who are saying that.
I think that it is very reasonable to discuss a normative addition to WCAG that clarifies this concern. Whether we have time to do it in WCAG 2.2 and whether there is an actual impact of making that change in a "hurry-up" manner are questions that we need to understand and come to agreement on. |
This issue was opened in February 2020. This should have been resolved by the Working group before. Alternatively please tell us how to effectively log feedback so it is addressed in time and what the lead time is. Because if we wait to address it to WCAG 2.3 it will probably take another 2 years. Is it that big of an ask that raised issues are addressed (and that can be "we don't want to make a change and close the issue" ) within 30 months? Having the issues open and lingering around is just harmful and disappointing. |
I'm not in charge of the schedule, but it looks like this was discussed back in June/July 2020 and the WG wasn't able to come to a consensus and as a result it was put into a backlog list of issues raised that the WG could pay attention to later. This was raised again a week ago without any level of agreement on what type of problem it is, which doesn't increase the chances of it being addressed for WCAG 2.2, especially since it was re-raised during the WCAG 2.2 CA CFC.
I'd like issues to be addressed more quickly also, as would I'm sure everyone else, but there is a bandwidth problem. I believe that the Working Group has directed its focus to more pressing issues during WCAG 2.2 development, and while it is unfortunate that not everything raised as an issue can be resolved, that is the current situation. If the WG was more rigid with its issue handling (e.g., if an issue isn't worked on in 6 months then it gets closed) that would prevent long-lived issues, but might be regarded as harmful and disappointing in different ways. This is off-topic for this issue but I'm happy to discuss elsewhere. |
And everyone who raised the issue was patiently waiting for the working group to pick the issue up as it was neither deferred, nor closed or otherwise addressed.
It was raised during WCAG 2.2 CFC because that is when people look at the issues the WG forgot over the years. This is part of the CFC as far as I'm concerned: Finding issues that are not addressed and that should have been. It's a really weird flex to say "trust that the working group will come back to this" and also "well that didn't happen, you would have needed to nag more". This is all super disappointing but I think I got the message of participation as a non-paying non-group participant. (If I was representative of a member org, I would not support 2.2 through to CR in this state. As I am not, I will just explain the same thing again for another 5 years.) |
|
As the person trying to make best use of the group's time on WCAG 2.x related issues, I look at this issue and see a stalemate. I.e. a disagreement with no obvious comprise position. That means it will take a lot of in-meeting time to resolve. Given that it took over 10 years(?) for this issue to come up in the first place, and that either interpretation is better than not having it, the cost-benefit ratio of solving this is not good. Chair hat off: I think the best course would be to accept the PR as a change to WCAG 2.2, without changing WCAG 2.1/2.0. However, that would be seen as adding a new requirement and I don't think it's worth the extra 6 months delay to WCAG 2.2, assuming we could get agreement on that being the best course of action quickly. |
|
I see. unsubscribing from this issue |
|
@alastc – How about this PR for 2.2 and PR #2584 (as errata) for 2.0 and 2.1 ? I agree that clarity of the SC is the more important issue. I would like for AGWG to have another opportunity to vote. My present thinking is that re-interpreting Extend won't put uptake of 2.2 at risk. That is because it would probably be difficult to find a real-world example where the opportunity to extend does not work out to having the option for ten-times-default-time-limit. |
|
This PR is not editorial - if it changes the meaning - which is does.
This would amount to deciding to put a clarification note that directly contradicts the original intent of the SC.
That is clearly not editorial but normative — and also against the practice of not weakening any of the SC.
Deciding to change the text to be weaker because some people thought it was weaker - seems…. unsatisfactory.
But if this topic is just going to keep going in circles - I guess we just leave it like it is.
Seems wrong but better than downgrading it because some people misunderstood it.
Best
Gregg
… On Aug 18, 2022, at 7:07 AM, Bruce Bailey ***@***.***> wrote:
@alastc <https://github.com/alastc> – How about this PR for 2.2 and PR #2584 <#2584> (as errata) for 2.0 and 2.1 ?
I agree that clarity of the SC is the more important issue. I would like for AGWG to have another opportunity to vote.
My present thinking is that re-interpreting Extend won't put uptake of 2.2 at risk. That is because it would probably be difficult to find a real-world example where the opportunity to extend does not work out to having the option for ten-times-default-time-limit.
—
Reply to this email directly, view it on GitHub <#1040 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNGDXVAFTFRMALTUOBODJTVZY7SRANCNFSM4KRMQ3IA>.
You are receiving this because you were mentioned.
|
|
@GreggVan this PR #1040 changes:
to:
Is that not what you want? And what you assert was intended back in 2005/2008? If we use PR #1040 for 2.2 and PR #2584 for 2.0 and 2.1, then we do not need to resolve the question as to which edit is normative. We get unambiguous wording for all three, 2.0/2.1/2.2, and we get the stricter version going forward. |
|
Not exactly
And that kind of retroactively normatively changes 2.0 and 2.1 from what it did mean to what some people thought it meant.
But to bring this to a close - I can live with this.
It preserves this important level A cognitive SC going forward - clearly.
And we have bigger fish to fry - or at least many more fish to fry.
Thanks Bruce
G
… On Aug 18, 2022, at 3:15 PM, Bruce Bailey ***@***.***> wrote:
@GreggVan <https://github.com/GreggVan> this PR #1040 <#1040> changes:
is allowed to extend the time limit at least ten times; or
to:
is allowed to extend the time limit to at least ten times the length of the default setting (either in one extension, or as a cumulative series of extensions); or
Is that not what you want? And what you assert was intended back in 2005/2008?
If we use PR #1040 <#1040> for 2.2 and PR #2584 <#2584> for 2.0 and 2.1, then we do not need to resolve the question as to which edit is normative.
—
Reply to this email directly, view it on GitHub <#1040 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNGDXU3W4F3NLWTVNTQCOTVZ2YYRANCNFSM4KRMQ3IA>.
You are receiving this because you were mentioned.
|
@GreggVan if not:
What would you like to see happen with the 2.2.1 Extend bullet for 2.2? @alastc I think this is worth a survey, as there is at least some faint hope for resolution. I think you would want to:
For each version (2.0, 2.1, 2.2) there are three choices. What we do for 2.2 does not have to be the same as for 2.1 (and/or 2.0).
Then for each of the above nine choices (3x3) there is the temperature question: I feel strongly and would object. / I really do not like. / I am okay either way. Another complicating factor which I suggest to include in the survey is something like this:
For example, I am fine with any of the three choices for 2.2, but if we make a change for 2.2, then I would really want us to do something for 2.0/2.1 – but I "can live with" either opportunities/default length, and I am okay with the choice for 2.1/2.0 being different from the choice for 2.2. Another example is that I think that some people might be okay with with either change, but would really want all three versions to be the same. For the survey to be efficient, it would need to surface/capture those two examples explicitly (and not just as free-form text entry). |
|
I THINK I said - or I intended to say - that I 'could live with' your last proposal to change the language on 2.2 to be the original intent ( up to 10 extensions equal to the default time) and to just put a note on the older versions as part of errata that did NOT require the extensions to be equal to default because people had misunderstood it.
In short "clarify in 2.2 but don’t enforce backward" - if I understood your suggestion.
If so how about
For 2.2
Bullets all bullets/choices but #2 stay the same
Bullet/choice # 2 is has clarifying text added as shown in bold (including the choice before as well for context)
Adjust
The user is allowed to adjust the time limit before encountering it over a wide range that is at least ten times the length of the default setting; or
Extend
The user is warned before time expires and given at least 20 seconds to extend the time limit with a simple action (for example, "press the space bar") that extends the time by another default time limit, and the user is allowed to extend the time limit at least ten times by this amount; or
For 2.0 and 2.1
We add a note that says
"Note: this provision has been updated in 2.2 to clarify that the each extension would be equal to the original time limit. However since this was not clear from the language for this provision in WCAG 2.0 and 2.1, an extension of any length is accepted for conformance to WCAG 2.0 and 2.1.
This still is what I would call a retroactive normative change to the intent of the provision - but I can see that others could argue that the text did not say that - and it is not fair to those following the text and did not understand the intent (which was either unwritten or poorly documented in the Understanding WCAG 2.x).
So I think your path of (clarify in 2.2 but don’t enforce backward) is probably best.
Gregg
… On Aug 19, 2022, at 8:54 AM, Bruce Bailey ***@***.***> wrote:
Not exactly And that kind of retroactively normatively changes 2.0 and 2.1 from what it did mean to what some people thought it meant.
@GreggVan <https://github.com/GreggVan> if not:
is allowed to extend the time limit to at least ten times the length of the default setting (either in one extension, or as a cumulative series of extensions); or
What would you like to see happen with the 2.2.1 Extend bullet for 2.2?
@alastc <https://github.com/alastc> I think this is worth a survey, as there is at least some faint hope for resolution. I think you would want to:
Time-box the conversation.
Ask people not to discuss if either edit is normative or not.
Ask people not to discuss if either edit is actually a substantial change or not.
The survey questions will have to be a bit numerous, I think, because the issue is like a 3x3x3 matrix. But a longish survey might (I hope) uncover a path forward with minimal resistance.
For each version (2.0, 2.1, 2.2) there are three choices. What we do for 2.2 does not have to be the same as for 2.1.
Do nothing.
Change ten times to ten opportunities
Change ten times to ten times the length of the default setting
Then for each of the above nine choices (3x3) there is the temperature question: I feel strongly and would object. I really do not like. I am okay either way.
But another complicating factor to include in the survey is if the decision made for 2.2 impacts the decision made for 2.0 and 2.1. For example, I am fine with any of the three choices for 2.2, but if we make a change for 2.2, then I would really want us to do something for 2.0/2.1.
—
Reply to this email directly, view it on GitHub <#1040 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNGDXQYM5SV7XDWVAGWDV3VZ6U3RANCNFSM4KRMQ3IA>.
You are receiving this because you were mentioned.
|
|
OBE, there is already a survey up. https://www.w3.org/2002/09/wbs/35422/wcag21-errata/ Crossing fingers... |
|
Note to self, one hour before call. Based on the survey results, I predict we are stuck with the status quo. Edit, after the call. Vote was at end of meeting, see: https://www.w3.org/2022/08/23-ag-minutes.html#item09
Plan is to update Understanding to reflect both what some people meant to write (and what most people wish we wrote) — while acknowledging the fact of what we did write (and are unwilling to update). Schrödinger's cat was mentioned. |
|
Agree with all of this
But the only thing we can do at this point — is to add text to clarify what the existing SC means — what it meant when it was adopted - and - as a standard - still means now.
If we want to change it — then that is a normative change and we are WAY too late to introduce that for 2.2 even if we agree that it should be changed and what it should be changed to.
We ALWAYS want to improve. But at this point I think the chairs’/WG's plan is to look to WCAG 3 for normative changes — because there we don’t have the same tight constraints on backward compatibility. We still will want to have backward compatibility as much as we can. But not nearly as tightly as within the 2.x series.
At least that is my understanding of where the WG is thinking — and I think that is a good plan (though it will mean long discussions about lots of topics if we are revisiting too many old SC in addition to all the new work we want to do…)
Best
gregg
… On Aug 10, 2022, at 1:04 AM, Eric Eggert ***@***.***> wrote:
Also, while I appreciate the soul searching on what was meant umpteen years ago, if there is a clearer way to formulate it, that would be useful. If the WG thinks 10 times the default should be meant with this in 2022, then the SC should be updated to say that. I totally agree with not changing the reliable parts of WCAG, but refusing to change unclear and unreliable parts just adds up into a less reliable standard.
I would suggest holding off going to CR until the WCAG 2.1 issues (which are also WCAG 2.2 issues as WCAG 2.1 is fully integrated in WCAG 2.2) are addressed. Thankfully for y’all I’m not part of the working group, so nobody has to listen to me ;-)
—
Reply to this email directly, view it on GitHub <#1040 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNGDXUV2JKQXFUENCM6LXTVYNPB3ANCNFSM4KRMQ3IA>.
You are receiving this because you were mentioned.
|
|
I think the 10 opportunities is the safest (i.e. wouldn't cause sites to suddenly fail), would that be accepted?
Hmmm that seems to imply that they were not already failing.
Making the original provision clear does not make it any harder to pass. Just harder to misunderstand.
Again - before we weaken this we should ask COGA group if they think adding just a series of short increases that do not increase the time for them to respond by very much is ok.
Remember that the example used (of 90 minute checkout of things from the library) has nothing to do with this provision.
That 90 minutes is not a user interface or response time question. And if it was then something that takes a typical user 90 minutes to do — is going to take someone with a cognitive Disabilty a MUCH longer time to do.
(And if the 90 was done to make it easy for everyone and it could be done by a typical user in 5 min — then the easy way to conform is to set the timeout to 8 minutes and allow extensions and it would come in at 90 minutes for those that need it — and the resources would be opened back up faster for everyone else. )
This provision is talking about whether if a typical user has 10 minutes to fill out a complex form, someone with a disability should be able to extend their time in 10 minute increments to 100 minutes (or actually 110 minutes) if they need it (rather than ten 1-or-2-minute increments, as the new interpretation suggests.
I am really having trouble following the logic of changing the original meaning and making it harder for people with cognitive, language, and learning disabilities — at a time when we are trying so hard to better accommodate them.
I understand that the original edge case made it look like it was onerous - but it really isnt. And that was not a valid application of this SC.
Best
gregg
———————————
Professor, University of Maryland, College Park
Founder and Director Emeritus , Trace R&D Center, UMD
Co-Founder Raising the Floor. http://raisingthefloor.org
The Global Public Inclusive Infrastructure (GPII) http://GPII.net
The Morphic project https://morphic.org
… On Aug 11, 2022, at 4:34 PM, Alastair Campbell ***@***.***> wrote:
Hmm, it seems that if this came to survey it wouldn't get through. I'm fairly sure we've asked before and tried to get agreement to go with either 10x default or 10 opportunities, and couldn't get agreement.
I think the 10 opportunities is the safest (i.e. wouldn't cause sites to suddenly fail), would that be accepted?
—
Reply to this email directly, view it on GitHub <#1040 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNGDXSMU6QI72DY6A5NY3LVYWEXRANCNFSM4KRMQ3IA>.
You are receiving this because you were mentioned.
|
Based on the discussion in https://lists.w3.org/Archives/Public/w3c-wai-gl/2020JanMar/0161.html this is a first attempt at making it more explicit what the confusing "at least ten times" means. It appears this has been misinterpreted by some as "ten times" meaning that a site needs to provide ten separate warnings/options to extend, when in fact it appears this, like the previous point about adjusting timing, is meant as "ten times the length of time".