- From: Sailesh Panchang <sailesh.panchang@deque.com>
- Date: Wed, 30 Sep 2015 10:07:09 -0400
- To: Andrew Kirkpatrick <akirkpat@adobe.com>
- Cc: "jon.avila@ssbbartgroup.com" <jon.avila@ssbbartgroup.com>, James Nurthen <james.nurthen@oracle.com>, "w3c-wai-gl@w3.org" <w3c-wai-gl@w3.org>
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> 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> > 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> > > 703-637-8957 (o) > Follow us: Facebook<http://www.facebook.com/#%21/ssbbartgroup> | > Twitter<http://twitter.com/#%21/SSBBARTGroup> | > LinkedIn<http://www.linkedin.com/company/355266?trk=tyah> | > Blog<http://www.ssbbartgroup.com/blog> | Newsletter<http://eepurl.com/O5DP> > > From: James Nurthen [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> > 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> > 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> > Oracle Corporate Architecture > 500 Oracle Parkway | Redwood Cty, CA 94065 > [Green Oracle]<http://www.oracle.com/commitment>Oracle is > committed to developing practices and products that help protect the > environment >
Received on Wednesday, 30 September 2015 14:07:39 UTC