- From: James Nurthen <james.nurthen@oracle.com>
- Date: Fri, 12 May 2017 16:47:54 -0700
- To: "Bradley Montgomery, Rachael L." <rbradley@mitre.org>, "w3c-wai-gl@w3.org" <w3c-wai-gl@w3.org>
- Message-ID: <e7b2f712-b461-f39c-4757-e59c31f4774f@oracle.com>
But instant messenger applications are not just a simple text field. They have buttons to add photos, change formatting etc. in them so I didn't see that exemption as applying Adding a comment to github would be another example where a confirmation is not really necessary and would be really annoying. Was this another example which the single field exception was meant to cover? I certainly wouldn't call that a simple text field. Another example would be something like google sheets. Again this certainly fits the definition of a an exchange of information between individuals or groups - as these can be shared documents. But I'm not even sure how I would go about presenting the summary of changes I made to a spreadsheet, nor would I even know when the submit actually is happening (most of these apps are continuously saved). To be honest I have no idea how to solve these issues. IMO requiring confirmations is a design decision based on a whole host of parameters and not something that can be mandated in all circumstances. Requiring it would make UIs worse in as many places as it would make them better. Regards, James On 5/12/2017 4:26 PM, Bradley Montgomery, Rachael L. wrote: > > James, > > The intent of the single text field exception was to handle situations > like instant messaging. > > I’m noting areas that may need more clarification. J > > Regards, > > Rachael > > *From:*James Nurthen [mailto:james.nurthen@oracle.com] > *Sent:* Friday, May 12, 2017 7:12 PM > *To:* Bradley Montgomery, Rachael L. <rbradley@mitre.org>; > w3c-wai-gl@w3.org > *Subject:* Re: Request for Review and Comment: Confirm Important > Information (Issue #33) > > If I'm understanding this correctly, with this wording if I had an > instant messaging application I would also be required to confirm > every message I sent? > > Regards, > > James > > On 5/12/2017 3:54 PM, Bradley Montgomery, Rachael L. wrote: > > Hello James, > > I understand the concern. The intent of defining transaction as an > exchange of information being between individuals or groups was an > attempt to exclude development work. Do you have a suggestion on > rewording the definition or SC to better clarify that this type of > task is outside the scope? > > Thank you for the feedback. > > Rachael > > *From:*James Nurthen [mailto:james.nurthen@oracle.com] > *Sent:* Friday, May 12, 2017 6:43 PM > *To:* w3c-wai-gl@w3.org <mailto:w3c-wai-gl@w3.org> > *Subject:* Re: Request for Review and Comment: Confirm Important > Information (Issue #33) > > This seems to add a lot of burden to expert users on systems. For > example, when I am doing DB development work (which I'm doing > quite lot at the moment) in a system I do not want every > transaction I do to be confirmed. This would slow down development > work and be really frustrating. > > Most of these systems will ask to confirm drop or truncate > operations but will not ask to confirm simple updates or inserts. > To be honest if they did it would reduce the effect of them asking > for confirmations of truly catastrophic operations. This meets > WCAG today as you can simply change or delete the data to undo the > operation if required - but it would not meet this new standard. > > Regards, > James > > On 5/12/2017 3:07 PM, Bradley Montgomery, Rachael L. wrote: > > Hello, > > We have been working on Issue #33 and after a number of > revisions believe we are nearing completion. We have limited > time on the call so I would like to get a sense of where this > stands with the broader group. > > Please respond with a +1 if you feel this is ready to go or > send suggested changes or concerns to this list. > > Thank you, > > Rachael > > > Purpose > > The purpose of this SC is to provide users with a chance to > review the data they input before they complete a > transaction. We feel that validation and other automatic > error checking is covered in other SC but that some errors can > only be caught by user review. Examples of errors that can’t > be caught by a machine include when a user picks Berlin, New > Hampshire instead of Berlin, Germany or when the button is hit > twice and the final count in a purchase is higher than > intended. This SC should codify what is already common > practice on most sites by requiring a site present a summary > of the information for review before the user commits. > > This SC has gone through a number of iterations as we have > compared it with other suggested SC and existing SC. Feel free > to look at the current text on rawGIT > <https://urldefense.proofpoint.com/v2/url?u=https-3A__rawgit.com_w3c_wcag21_error-2Dprevention-2Dlegal-2Dfinancial-2Ddata-5FISSUE-2D33_guidelines_sc_21_error-2Dprevention-2Dlegal-2Dfinancial-2Ddata.html&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=ELX2morANsauwtoroVrFb2wD7s1u7PsR47DTXqRvJ34&m=-T7Z_ijVFzfXB18cKcRIbj6LP6ij__lNzJ5TBpPPKFE&s=g6YDk7PoGbJBwwLoXv8UC5GoQtaafhkBwnUOTENApMQ&e=> > or the history and discussion > <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_w3c_wcag21_blob_error-2Dprevention-2Dlegal-2Dfinancial-2Ddata-5FISSUE-2D33_guidelines_sc_21_error-2Dprevention-2Dlegal-2Dfinancial-2Ddata.html&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=ELX2morANsauwtoroVrFb2wD7s1u7PsR47DTXqRvJ34&m=-T7Z_ijVFzfXB18cKcRIbj6LP6ij__lNzJ5TBpPPKFE&s=swQAaefP2wyzE9fwU_F4djC2mMQLOcdFDxictZ_9BH8&e=> > but I’ve pasted the text below for ease of viewing > > > *SC Title: Confirm Important Information* > > *Level:*A > > Where a user is required to enter data to complete a > transaction, a read-only summary of the data is provided so > the user can confirm the final information before submission. > > *Note:*Log-ins and single, simple text field transactions are > exempt. > > *Proposed New Definition* > > Transaction: An exchange of information between individuals or > groups > > ** > > -- > 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 <sip:james.nurthen@oracle.com> > OracleCorporate 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 > > -- > 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 > <sip:james.nurthen@oracle.com> > OracleCorporate 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 > -- 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 <sip: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 Friday, 12 May 2017 23:47:59 UTC