[Athen] Survey Monkey and Accessibility

Terrill Thompson tft at u.washington.edu
Fri Mar 13 08:09:39 PDT 2009

Hi Dan,

What you're describing sounds like correct behavior for screen readers when
confronting a choice of related options, according to the W3C's User Agent
Accessibility Guidelines (UAAG) 1.0.

For example, take the following question, and the three options that follow:

What is your favorite vegetable?

The choices are corn, peas, and tomatoes, so the label element should be
used to explicitly associate each of these labels with the corresponding
radio button. However, these options are meaningless unless the user knows
what the question is. The recommendation therefore is to enclose the whole
kit and kaboodle in a <fieldset> element, with the question marked up as a
<legend>. UAAG 1.0 recommends that screen readers read both the legend and
the label as each item receives focus, and that's exactly what JAWS does (at
least through version 9, I haven't checked 10). I agree that this can be
cumbersome, particularly if the legend has a lot of text in it. However, on
the opposite end of the spectrum we have Window-Eyes which doesn't read
legends and labels together, and arguably that lack of association between
the two could result in lack of user clarity.

This is all explained very well in an older post on the Paciello Group Blog:


It seems to me that the markup isn't the problem - it's the screen readers
(and maybe the UAAG recommendation). Window-Eyes provides too little
information, and JAWS (following the UAAG recommendation) provides too much.
Maybe there's middle ground somewhere. Maybe users could access the legend
at any time with a function key, but not be bothered by it unless they
request it. Of course, then you have the problem of users actually knowing
this function exists, and most probably won't. In fact, maybe this already
exists in a JAWS verbosity setting, but if it does I'm not aware of.

The problem with SurveyMonkey is different. They're not using standard
markup at all (no fieldsets, no legends). They instead have tucked hidden
span elements throughout their forms that provide additional prompts to
screen reader users, sort of replicating what JAWS would do if they had used
proper HTML. This may be enough to be "Section 508 compliant" in someone's
opinion, but it seems to me to be a very bad idea. They, and all web
developers, should develop according to the HTML specification and leave it
to screen reader developers to figure out how best to present that markup to
the user. If users don't like how one screen reader does it, they can use
another one that does it differently, or they can influence the screen
reader developer and/or W3C to approach the problem differently. Speaking of
which, does anyone know how UAAG 2.0 is approaching this problem?

Terrill Thompson
Technology Accessibility Specialist
DO-IT, Accessible Technology
UW Technology Services
University of Washington
tft at u.washington.edu

> -----Original Message-----

> From: athen-bounces at athenpro.org [mailto:athen-bounces at athenpro.org] On

> Behalf Of Burke, Dan (DSS)

> Sent: Thursday, March 12, 2009 8:52 AM

> To: Access Technologists in Higher Education Network

> Subject: [Athen] Survey Monkey and Accessibility


> I am going to take this opportunity to whine about Survey Monkey's

> accessibility. I've taken two surveys this week at Survey Monkey, and

> the problem the site has interacting with a screen-reader remains.


> Survey Monkey, despite their certification for accessibility, presents

> one ongoing problem for screen-readers. Namely, the entire question is

> echoed when I arrow over the first choice of the item - on every item.

> It is possible, therefore, on some of the more complex and long-worded

> items that the cacophony results in obscuring the first choice, and

> that

> I may not make a choice I otherwise would have made. I tried to be

> aware of this, and even double-checked a couple of them to find that I

> had made omissions.


> I noted this problem last year, and tried to engage in a conversation

> with Survey Monkey. But being the kind of enterprise that they are,

> they don't do direct e-mail - and don't even think about phone calls.

> They use a back-end tracking system of their own for such messaging

> which, unfortunately, I found even more troublesome as far as

> accessibility goes. As a result, I didn't tell them as much as I have

> posted here about their problems with access.


> Done whining.


> Daniel J. Burke

> Assistant Director/Coordinator

> Disability Services for Students

> Emma B. Lommasson 154

> The University of Montana

> Missoula, MT 59812


> www.umt.edu/dss/


> 406.243.2243 voice/text

> 406.243.4424 direct line

> 406.243.5330 fax




> _______________________________________________

> Athen mailing list

> Athen at athenpro.org

> http://athenpro.org/mailman/listinfo/athen_athenpro.org

More information about the athen-list mailing list