Accessibility issue...

Jul 19, 2008 at 4:22 PM
Does anyone have a recommendation for how to make an AIP-protected form accessible?

Obviously this is a feature that'd be nice to see in a future version.

Many CAPTCHAs provide an alternative audio challenge, or some kind of text-based affair, although some kind of text-based pop quiz would obviously be easier to break with bots.

CAPTCHA stands for "Completely Automated Public Test to tell Computers and Humans Apart" (as I'm sure you're all aware).

But a blind human can't read an image and therefore the CAPTCHA is considered incomplete by its own definition.

Any thoughts or suggestions on this?

Jul 19, 2008 at 8:14 PM


I'll consider adding an accessibility-friendly alternative to the library and include a property on the AIP web control that allows you to flip it on.  Perhaps a simple Q&A would do, or maybe something a bit more complicated such as an audio stream.

Accessibility wasn't consider in my original architecture so I guess now's a good time to think about it for the next production release.  There may need to be some refactoring to get the pieces to fit in, but I'd like to keep the alternative solution as open as the base CAPTCHA implementation is so that custom providers can be written as well; e.g., if I provide something like an AlternativeProvider implementation for Q&A then anybody else using AIP should be able to easily plug-in an exisiting audio implementation for AlternativeProvider and set it as the default (obviously I just made up the name AlternativeProvider so it'll probably change).

I'm first going to see if I can just create new providers and add a new property to the AIP web control, which will perhaps show a hyper link under the image that, when clicked, will route event handling to a specialized provider.  We'll see were it goes from there.

There should be a new work item for this so I'll add one now.

- Dave

Jul 19, 2008 at 8:24 PM
Work item: