Call for Topics:
Please reply with suggested topics for our February Drupal Accessibility Skype Meeting.
Tuesday, February 14, 2011
5pm UTC-GMT / 11am CST
on Skype (contact m.gifford or brandonbowersox on Skype to be added to the group if this is your first time joining)
Anyone interested in working on Accessibility using Drupal is invited.
Please respond with suggested topics
The call is a voice conference call on Skype. We'll be asking for a volunteer to post notes to the g.d.o. group so that people who could not attend can still review the notes and post comments. We will try to limit the main agenda to one hour.
This a regular monthly event the Second Tuesday of each month. (Note: We missed holding a January meeting, but we'll get back into the Second Tuesday groove for 2012.)
What would you like us to discuss this month?
Comments
testing - ignore
Just testing. Please ignore.
Stuff to talk about
It's right before CSUN February 27- March 3 - http://csun.edu/cod/conference/sessions - I'm not going, but it sounds great.
There might be some Drupal focus, but mostly is anyone going?
There's preparing for a sprint at DrupalCon which has been talked about.
Everett's always got a good list of great topics. More on D8 work I assume.
I'm concerned that there hasn't been much move on FAPI improvements in D8.
--
OpenConcept | Twitter @mgifford | Drupal Security Guide
Regrets, I won't be available
Regrets, I won't be available for this call. Can I suggeest that you go over the notes from last meeting, and see if there is anything outstanding?
I also would recommend some brainstorming for how we can get support (financial) for a full review of D7 against WCAG 2.0 AA. Perhaps we can appeal to big Drupal firms, or to other community partners.
Thanks and have a great meeting.
Accessibility Consultant & Web Developer - Zufelt.ca
@ezufelt on Twitter | LinkedIn profile
Regrets also - have reposted Mollom Audio Captcha issue
I'm just a lurker on these calls, but really would suggest the audio captcha is very close to resolution for keyboard users to just be able to play the button without Flash. Note this sems to be a Mollom service issue and I had entered via contact form on mollom.com where I did not find a link to the Mollom support ticket system.
Yes, accessibility is a large confusing issue to some & issues will remain, but this problem IS fixable and could use this group's attention to finally get clarified & fixed - thanks!
Suggested Agenda
Forms API Proposal - bowersox
http://groups.drupal.org/node/209513
Mollom Audio Captcha - k8?
I believe k8 won't be able to attend, but since there has been so much conversation about Mollom and Captcha, anyone on the call who wants to ask about this or discuss certainly can.
DrupalCon Plans
Ideas for BoF groups, code sprints, or other work next month in Denver.
www.pixotech.com
Optional Topic
If time allows and if the group is interested, we could also review what progress was made on the 4 issues we discussed in December:
Focus jumps to tab when pressing enter on a form element within tab - http://drupal.org/node/1361218
December notes: Nobody on the call felt it was too important to keep this particular interaction, given the down-sides. There was general consensus to proceed with a patch that we can test with JAWS or other combinations (to investigate removing this functionality).
Simplify names of "element-x" helper classes - http://drupal.org/node/1363112
December notes: There was general support. The only concern raised was whether the simple name "invisible" would collide with that name used by other scripts or other CSS.
Add WAI-ARIA roles to Core blocks - http://drupal.org/node/1183042
December notes: This is a Drupal 8 patch and it needs testing and review.
Expose visually-hidden visibility for Field's Label in Manage Display - http://drupal.org/node/1361102
December notes: This is an important issue that simply needs to be fixed in D8 and D7.
www.pixotech.com
Hello all, I apologize cannot
Hello all, I apologize cannot make the call due to conflict but just received the following from Mollom support. I disagree with 'solved' status which indicates to others that it 'works' and/or no more followup coming. I will respond that they should track this as 'needs work', etc. Isn't accessibility the whole point of the audio captcha? Correct me if I'm wrong on this and hope the a-group can help prioritize this. It is close to being solved, still misunderstood. Thanks! - Kathy Kahl, DAISY Consortium
Keith Smith notifications-support@mollom.zendesk.com to me
Your request (#3734) has been marked "solved".
To review, comment and reopen the request, follow the link below:
http://mollom.zendesk.com/tickets/3734
Keith Smith, Feb 14 06:21 pm (CET):
I'll pass on the infor about the audio being non-understandable -- let me point out that the audio captcha that is played does NOT match the captcha being displayed by design.
In terms of this entire issue, especially for your non-sighted users, we realize the importance of providing accessible CAPTCHAs to the visually impaired community, but have determined we've got some major challenges in doing so. We've scheduled some time in the upcoming year to address this issue from the bottom up, and potentially redesign our audio CAPTCHA solutions as well as analyze exactly how screen readers are reacting to the information we're displaying on the page, with an eye toward making both those things work as well for the visually impaired as we can. This isn't going to be an easy fix, however, and will likely take us some time to implement.
I'm going to mark ths issue solved right now -- even though it isn't -- to move the ticket out of our daily queue trouble tickets. As we work toward resolving this, we may email you back to ask you to beta test or otherwise provide some feedback to evaluate the solutions we come up with (we've made a note of your email address and the other helpful information you provided in this ticket). Either way, we'll announce any major changes on this issue with an email to you as well as posts on the blogs at Mollom.com and buytaert.net.
Don't think we're closing the ticket because we don't want to work on this issue -- it's just that this issue is different from the normal types of things we track in ZenDesk, and ZenDesk is not well suited to handling interactions for what may be a lengthy type of feature-request design process.
Thanks for bringing this to our attention again -- we've known that we needed to improve accessibility -- as do many other vendors on the web -- but it is tickets like yours that spur us to do so. We reallly do appreciate the feedback.
Re: needs work
Hi Kathy,
Thanks for sharing this. We discussed this issue briefly in today's Skype meeting, and a number of people were interested in doing outreach to the Mollom team and helping make sure this gets handled in a way everyone is proud of.
Regarding the 'solved' ZenDesk ticket, I actually understand where they are coming from. It sounds like they use a different issue tracker to actually manage their developer tickets. I suggest you ask whether you can get a URL or be cc'd on that developer issue queue ticket so you can offer help along the way or track progress.
There are a number of ways we can offer support: Providing testing in screen readers when they have a draft; Educating Mollom maintainers about how to test the audio captcha themselves (like providing a test plan); Helping suggest an automated test approach.
Also, if they are going to redesign audio captcha from the ground up, maybe we can provide some best practices or examples for them to look at. Siddhant says the LinkedIn audio captcha is a good example, but the Google/Gmail audio captcha is not.
-Brandon (bowersox)
www.pixotech.com
Other options
It's also good to post Mollom issues here - http://drupal.org/project/issues/mollom?categories=All
Also, if its for implementation on a Drupal.org site there's always - http://drupal.org/project/issues/webmasters?text=mollom&status=Open&prio...
--
OpenConcept | Twitter @mgifford | Drupal Security Guide
Skype Meeting Notes 2/14/2012
Below are rough notes from today's Skype meeting.
Present
Mike Gifford - mgifford
Julius - julius_charles - just started using Drupal with D7; learning; works as an accessibility consultant
Dan Mouyard - dcmouyard - front-end developer
Bojhan Somers - bsomers - UX team
Siddhant Chothe
1. Forms API Proposal - bowersox
Brandon introduced the topic: http://groups.drupal.org/node/209513. Siddhant likes the idea: having the error messages be a the link is important. When an error is validated on client side by javascript the focus can be immediately set to the field with the error. Mike suggests we have a demo of this working for people to try out. Bojhan says this is promising, and case 3 is good because it solves the problem of multiple errors. Perhaps we should always do what case 3 does and always just show the error in one place rather than duplicating it. There is also the cases like Fields UI where there is no room for inline errors. Maybe we can design all the different form errors. The group discussed possible patterns we could develop.
The group discussed whether the duplication is a benefit or not and why. One idea for FAPI is to allow form creators to specify an optional #error-location value = "top", "inline", or "tooltip".
Mike also reminded us that we have more Form API issues to tackle including fieldsets for Dates, Checkboxes and Radios.
2. Mollom Audio Captcha
We discussed the general Mollom issue: http://groups.drupal.org/node/207703#comment-691608 .
Mike suggested that we need to make sure we have the ear of whoever is implementing Mollom. We should make sure when there are issues that effect accessible participation that there is follow-up to fix that issue. We can help educate Mollom maintainers about how to test the audio captcha, provide automated testing ideas, and we can provide testing. Siddhant would be happy to test it--he likes LinkedIn audio captcha; he is not as happy with Gmail and Google forms.
3. DrupalCon Plans
Dan and Brandon will be there in Denver. Mike and others expressed interest in joining Accessibility BoF events by Skype.
We had lots of new ideas for specialty BoF events:
"Accessibility Testing Show and Tell" can be a BoF where we share our tools and best practices for accessibility testing.
"Accessibility Strategy Session" can be for networking and organizing D8 accessibility work, much like we've had at past DrupalCons.
"Designing for Accessibility" is Dan's suggestion of giving a presentation based on his session at Drupal Camp Maryland: http://drupalcampmd.org/sessions/designing-accessibility.
www.pixotech.com
An answer for Mollom: BOTCHA
I didn't say the answer, because BOTCHA only bats about .946 on the site I've used it on. But if the bogus registrations are down to 10 or so a day, that's easily manageable.
For those of you not into the all-American pastime, a batting average of .946 corresponds to blocking 94.6 percent of the bogus registrations. When I inherited it, the site, The Progressive Christian, was getting inundated with bogus registrations and spam submissions, largely due to the failure to use any countermeasures at all for several months.
I immediately changed registration requirements to require admin approval, but sorting through scores of registrations a day to find the one or two, at most, that were legitimate? That would never work.
Then I discovered BOTCHA. I fell in love with it immediately. Without special configuration, BOTCHA automatically protects all the key forms on a typical site, starting with registration. And its philosophy is different. It uses honeypots, not tasks, to separate bots from people. The bots, not the people, have to do the extra work. When fields that people don't perceive are populated, the form is rejected. And the accessibility, from what I hear from others who have tested it, is reasonably good.
Since I installed BOTCHA about 9 days ago, there have been 1905 registrations attempted. BOTCHA rejected 1802 of them. Of the other 103, only three were real people. Still, that's a small number of registrations for the admin to review over the course of that many days. And I haven't yet looked at the BOTCHA settings to see if I can increase its effectiveness.
Check it out!