Re: Is this covered by 2.2.1 (Timing Adjustable)

I concur.   If all it does is require an additional log-in with no loss in data or status - then it still allows the user to take all the time they need - while still protecting them and  others from having their account hijacked if they step away from there computer for very long. 

So it would pass the SC. (in my opinion) 

gregg

----------------------------------
Gregg Vanderheiden
gregg@raisingthefloor.org




> On Sep 30, 2015, at 4:07 PM, Sailesh Panchang <sailesh.panchang@deque.com> wrote:
> 
> James,
> I second Andrew and I was drafting a similar response.
> I have seen a mutual fund (Sec 529)  site that have required
> re-logging in before submitting a transaction ... a user may not
> realize that he has been logged out  previously. The re-logging in
> appears to the user as a requirement for security reasons.
> 
> Besides the note at the end of the SC, also  consider the statements
> from the Understanding doc:
> -Designing functions that are not time-dependent will help people with
> disabilities succeed at completing these functions.
> -  From example#5: However, the site does move as much of the process
> out of the time-critical period as possible, for instance allowing
> users to provide necessary information like name, payment method,
> etc., before entering the time-critical stage.
> 
> It appears that the critical tasks in the process  alone really
> require authentication in your workflow too in line with the example
> above.
> Regards,
> Sailesh
> 
> On 9/30/15, Andrew Kirkpatrick <akirkpat@adobe.com <mailto:akirkpat@adobe.com>> wrote:
>> I think that a case can be made that the user’s session hasn’t expired at
>> all, and this is supported by the site allowing the user to continue to
>> shop.  As such I think that this makes 2.2.1 not coming into play.  If the
>> user isn’t losing anything then the only issue is one of re-authentication,
>> and that seems well addressed and meets 2.2.5.
>> 
>> The goal of 2.2.1 is "The intent of this Success Criterion is to ensure that
>> users with disabilities are given adequate time to interact with Web content
>> whenever possible. “ and it sounds like you are doing that.
>> 
>> That all said, I do think that there is a need to make 2.2.1 more clear to
>> handle such scenarios.
>> 
>> Thanks,
>> AWK
>> 
>> Andrew Kirkpatrick
>> Group Product Manager, Accessibility
>> Adobe Systems
>> 
>> akirkpat@adobe.com
>> http://twitter.com/awkawk
>> http://blogs.adobe.com/accessibility
>> 
>> From: Jonathan Avila
>> Date: Wednesday, September 30, 2015 at 09:15
>> To: James Nurthen, WCAG
>> Subject: RE: Is this covered by 2.2.1 (Timing Adjustable)
>> Resent-From: WCAG
>> Resent-Date: Wednesday, September 30, 2015 at 09:15
>> 
>> James, I agree with you – a pop up would be more intrusive.  Interestingly
>> your approach seems to meet Level AAA 2.2.5 Re-authenticating: When an
>> authenticated session expires, the user can continue the activity without
>> loss of data after re-authenticating. (Level AAA)
>> 
>> Understanding SC
>> 2.2.5<http://www.w3.org/TR/UNDERSTANDING-WCAG20/time-limits-server-timeout.html <http://www.w3.org/TR/UNDERSTANDING-WCAG20/time-limits-server-timeout.html>>
>> The intent of this Success Criterion is to allow all users to complete
>> authenticated transactions that have inactivity time limits or other
>> circumstances that would cause a user to be logged out while in the midst of
>> completing the transaction.
>> 
>> A shopping site checkout
>> A user with extremely limited use of the hands is logged into a shopping
>> site. It takes so long to enter credit card information into the application
>> that a time limit occurs while the user is performing the checkout process.
>> When the user returns to the checkout process and submits the form, the site
>> returns a login screen to re-authenticate. After the user logs in, the check
>> out process is restored with the same information and at the same stage. The
>> user did not lose any data because the server had temporarily accepted and
>> stored the submission even though the session had timed out and restored the
>> user to the same state after re-authentication was completed.
>> 
>> So – is this one of those odd situations where you meet an equivalent level
>> AAA requirement but not level AA?  I would say it’s unfortunate and should
>> not be that way.
>> 
>> Best Regards,
>> 
>> Jonathan
>> 
>> --
>> Jonathan Avila
>> Chief Accessibility Officer
>> SSB BART Group
>> jon.avila@ssbbartgroup.com <mailto:jon.avila@ssbbartgroup.com><mailto:jon.avila@ssbbartgroup.com <mailto:jon.avila@ssbbartgroup.com>>
>> 
>> 703-637-8957 (o)
>> Follow us: Facebook<http://www.facebook.com/#%21/ssbbartgroup <http://www.facebook.com/#%21/ssbbartgroup>> |
>> Twitter<http://twitter.com/#%21/SSBBARTGroup <http://twitter.com/#%21/SSBBARTGroup>> |
>> LinkedIn<http://www.linkedin.com/company/355266?trk=tyah <http://www.linkedin.com/company/355266?trk=tyah>> |
>> Blog<http://www.ssbbartgroup.com/blog <http://www.ssbbartgroup.com/blog>> | Newsletter<http://eepurl.com/O5DP <http://eepurl.com/O5DP>>
>> 
>> From: James Nurthen [mailto:james.nurthen@oracle.com <mailto:james.nurthen@oracle.com>]
>> Sent: Tuesday, September 29, 2015 7:36 PM
>> To: w3c-wai-gl@w3.org <mailto:w3c-wai-gl@w3.org><mailto:w3c-wai-gl@w3.org <mailto:w3c-wai-gl@w3.org>>
>> Subject: Is this covered by 2.2.1 (Timing Adjustable)
>> 
>> We have a shopping site where users can browse the site when they are either
>> logged in or not. We are looking to see how 2.2.1 impacts logged-in users on
>> this site.
>> We want the session timeout to be as unobtrusive as possible -  as such this
>> is what happens currently for logged in users.
>> 
>> Scenario 1) If a logged-in shopper’s session times out while they are
>> shopping, they can continue shopping seamlessly. Only when they go to check
>> out or access their account information are they asked to log in. When they
>> log in, any changes they had made to their shopping cart while timed out are
>> intact.
>> 
>> My strict reading of 2.2.1 is that in this case the application should have
>> provided a method for the user to extend the session before the timeout
>> occurred. Do others concur on this? I feel that the conventional methods of
>> extending the session (like a popup as seen on many bank sites) would be
>> more distracting to a user than the current behaviour.  I really don't want
>> to ask the application to implement something which would IMO make the UI
>> worse for everybody.
>> 
>> Scenario 2)    If a logged-in shopper’s session times out while they are
>> editing account information, they are prompted to log in again when they
>> attempt to save their changes. Their unsaved edits are intact.
>> 
>> Again this seems to require a timeout prompt before the session expires with
>> a strict reading of 2.2.1. I would generally be ok with asking the
>> application to add a timeout warning here, as it is within a constrained
>> process - but, again, I'm not sure it would actually make the user
>> experience better for anyone.
>> 
>> I would appreciate any input on these scenarios and how others have coped
>> with them in the past.
>> 
>> --
>> Regards, James
>> 
>> [Oracle]<http://www.oracle.com <http://www.oracle.com/>>
>> James Nurthen | Principal Engineer, Accessibility
>> Phone: +1 650 506 6781<tel:+1%20650%20506%206781> | Mobile: +1 415 987
>> 1918<tel:+1%20415%20987%201918> | Video:
>> james.nurthen@oracle.com <mailto:james.nurthen@oracle.com><mailto:james.nurthen@oracle.com <mailto:james.nurthen@oracle.com>>
>> Oracle Corporate Architecture
>> 500 Oracle Parkway | Redwood Cty, CA 94065
>> [Green              Oracle]<http://www.oracle.com/commitment <http://www.oracle.com/commitment>>Oracle is
>> committed to developing practices and products that help protect the
>> environment