CAPTCHA document

Thanks, Jennie.

A few comments in line.

Also with cc to RQTF and Steve Noble of the RQTF, who has offered to help add
COGA relevant content to the CAPTCHA draft ...

So, if you draft something, please be sure to Reply to All!

Delisi, Jennie (MNIT) writes:
> Hi,
> Janina and I met over the phone and discussed the CAPTCHA document. Because I cannot attend today’s COGA meeting, I’m posting to the list both the items we discussed, and some draft language for proposed changes. In addition, we discussed the need for images that illustrate some of the types of CAPTCHAs and possibly issues that are being discussed. We are gathering some of these issues, but if you have images with creative commons license that could be added please send them to Janina.
> 
> Maybe add additional paragraph: (draft language needed. Jennie should have time to create a paragraph on Thursday evening if others do not already have something to propose)
> 
> -inclusion of anxiety issues. Challenge + multiple failures will lead to abandonment of task
> 
> -consideration of those using computers at a library or other community computer? They do not necessarily have download capabilities.
> 
> -add a bit about these two issues, and add references to stroke research re anxiety and failure.
> 
> - add documentation citation; or other disabilities and age related issues if appropriate
> 
> 
> 
> Section 1.3 - need to spell out AI since first use, or have as a glossary term (in Google quote, 2nd last paragraph.) Especially because visually the I looks like an L.
> 

Unfortunately, this is part of a direct quote, and an important direct quote
from Google. I'll add this to the Glossary as a workaround for this
issue.

> 
> 
> Section 2.1.4.3 movement-based and game CAPTCHA - issues for those with vestibular issues? Direction following issues? (give her language - include John R on email and COGA list)
> 
> 
> 
> 2.2.1 - is there any concern that messages from those with spelling related disabilities' messages will go into the spam filters? (add some type of caution, letting people know a first time correspondence may have significant spelling errors, and then get caught in the SPAM filter, and may be a person reaching out for government services therefore monitoring SPAM filters is very important).
> 

The more I think about this, the less concerned I am with spelling this
out. It's a common situation for all users, especially those who type
with their thumbs. So, I would expect spelling mistakes are already
expected by spam filering technology, and they're not adversely
affecting our users. And, if they are, we probably need research we can
point to to make the case.

> 
> 
> 3.1.1 - could this section title be misconstrued to mean someone missed the section called Version 1? Would quotation marks be appropriate?
> 


Version 1 is now mentioned in the CAPTCHA document as no longer
supported with a point to the Google reCAPTCHA FAQ which clearly states
that Version 1 is no longer supported, i.e. you can't use the API any
longer.

> 
> 
> 3.1.1, paragraph 2: "The date" has a capital letter on The, but this is the middle of a sentence (line 3). Also "All cookies" - all has a capital. And "All Javascript" - is this purposeful?
> 

Excellent catch! Thanks, Jennie. Hopefully, it's now all fixed.

> 
> 
> 3.1.2: 1st paragraph has misspelling? Promising
> 

Fixed, also mispelling of "accrue."

> 
> 
> 3.1.3: define DTMF key, TTS
> 

The technical term is not needed to make the point. The paragraph has
been written to remove the term.

> 
> 
> Section 4, paragraph 4 - would it be important to disclose to end users what types of data is being shared? Users with cognitive disabilities may not be able to make a knowledgeable decision about participating if they are unaware this data is being shared. (it is even more dramatic because they may not follow through on the steps to research issues not disclosed within the page)
> 

This is an item in a 5 item unordered list of research conclusions. The
points Jennie is asking about are made in the body of the document. We
include a long list of what Google collects, as well as some legal
references on data collection requirements in the U.S. and the E.U.

I'm still evaluating how to add a phrase here to remind authors and
developers, but I wouldn't want to put more than a short phrase here--in
the Conclusion Section.


I think there's need for balance. Overburdening a document or web page
with legal disclaimers and TOS statements seems to compete with the
desire to keep things simple and clear.

Thanks Jennie and all!

Janina

> Thanks,
> Jennie
> Jennie Delisi, MA, CPWA
> Accessibility Analyst | Office of Accessibility
> Minnesota IT Services | Partners in Performance
> 658 Cedar Street
> St. Paul, MN 55155
> O: 651-201-1135
> Information Technology for Minnesota Government | mn.gov/mnit<http://mn.gov/mnit>
> [Minnesota IT Services Logo]
> [Facebook logo]<https://www.facebook.com/MN.ITServices>[LinkedIn logo]<https://www.linkedin.com/company/mn-it-services>[Twitter logo]<https://twitter.com/mnit_services>






-- 

Janina Sajka

Linux Foundation Fellow
Executive Chair, Accessibility Workgroup: http://a11y.org

The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Chair, Accessible Platform Architectures http://www.w3.org/wai/apa

Received on Thursday, 13 June 2019 13:41:15 UTC