[Contrib: Evaluation System] [WG: Accessibility] Do radio buttons for compact likert scale have associated labels?

Daphne Ogle daphne at media.berkeley.edu
Fri Jan 13 15:13:47 PST 2012


Yes, I think that's true.  So are you suggesting that for a screen  
reader user the system would automatically use a full scale even if a  
compact scale was selected?

That doesn't of course solve the cognitive load but I think that  
comes  down to the choice being made by the evaluation author since  
they can choose other scales that include labels for all.

-Daphne

On Jan 13, 2012, at 2:51 PM, Aaron Zeckoski wrote:

> I believe that is correct.
> -AZ
>
>
> On Fri, Jan 13, 2012 at 5:42 PM, Gonzalo Silverio  
> <gsilver at umich.edu> wrote:
>> If it helps, in the Eval tool a compact display is (I think) a full  
>> scale, with all labeled items, where only the end point labels are  
>> rendered. So it would be trivial to re-add the labels for screen  
>> readers.  I think it is most commonly used grouped, where  a raft  
>> of questions are all using the same scale.  When that is the case  
>> the labels are there, but hidden.
>>
>>       - Gonzalo
>>
>> ------------------------------
>>
>> On Jan 13, 2012, at 5:27 PM, Daphne Ogle  
>> <daphne at media.berkeley.edu> wrote:
>>
>>> Good points Brian.  Since our likert scale includes 7 options I  
>>> think it  carries an even more significant cognitive load even for  
>>> those without a cognitive impairment.  However, at the moment we  
>>> are committed to a 7 point likert scale with only 3 descriptors  
>>> (both end points & a mid-point).  This is for historical reasons  
>>> at the university and is another discussion altogether here.  This  
>>> gives me another perspective to push on it with.  In the meantime,  
>>> I'm thinking we have 1 of 2 choices:
>>>
>>> 1)  if technically feasible, try something like Gonzalo was  
>>> suggesting
>>> 2)  come up with labels for all the choices and figure out how to  
>>> associate them with the radio buttons.
>>>
>>> I'm guessing #2 is likely the easiest (at least short term)  
>>> solution.  I'm not a developer so I can't get into the details but  
>>> given a conversation I had with Gary at Unicon (copied here), it  
>>> isn't clear that there is a way to make those associations at this  
>>> point.  Does anyone know if that's the case or we are missing  
>>> something?
>>>
>>> -Daphne
>>>
>>> On Jan 13, 2012, at 1:14 PM, Richwine, Brian L wrote:
>>>
>>>> Hmmm... Sorry, I'm no expert on Likert items. My HCI class always  
>>>> had each item option labeled, and we were taught to keep the  
>>>> option values symmetrical about the middle and have a definite  
>>>> qualifier / description for each -- that is where my response was  
>>>> coming from!
>>>>
>>>> The problem I see in not providing a label is at least two fold.  
>>>> First, that the visual nature of the likert item will be lost on  
>>>> non-visual (blind) users. It seems to me having a distinct  
>>>> description for each would be rather important in their case.  
>>>> Second, anytime a screen-reader user hits a form control that  
>>>> isn't labeled, it is going to concern them and make them have  
>>>> doubts as to what it is for. Especially since so many web  
>>>> applications through in hidden input controls that have  
>>>> absolutely no meaning (Samigo is famous for doing this, for  
>>>> example). A very common use case is a user with traumatic brain  
>>>> injury + blindness where there is significant cognitive  
>>>> impairment. The radio buttons would need to have some label...
>>>>
>>>> -Brian
>>>>
>>>> -----Original Message-----
>>>> From: gsilver [mailto:gsilver at umich.edu]
>>>> Sent: Friday, January 13, 2012 3:42 PM
>>>> To: Aaron Zeckoski
>>>> Cc: Richwine, Brian L; Gary Thompson; evaluation at collab.sakaiproject.org 
>>>> ; Sakai Accessibility WG
>>>> Subject: Re: [Contrib: Evaluation System] [WG: Accessibility] Do  
>>>> radio buttons for compact likert scale have associated labels?
>>>>
>>>> This seems like a case for hidden labels reflecting the collapsed  
>>>> choices.
>>>>
>>>> If you group several alike collapsed scales you can see the  
>>>> labels in the source, for example.
>>>>
>>>> I wonder though: a Likert scale is traditionally composed of two  
>>>> poles and an indeterminate set of unlabeled choices between the  
>>>> poles. Users select from these based on proximity to one pole or  
>>>> the other.  The absence of a label in itself is important in the  
>>>> instrument, is what am trying to say.  When the scale is  
>>>> presented non-visually, like in a phone poll, this is recast as:
>>>>
>>>> "On a scale of 0 to 10 where 0 is 'I strongly disagree' and 10 is  
>>>> 'I strongly agree'  ....."
>>>>
>>>>    -Gonzalo
>>>>
>>>> On Jan 13, 2012, at 3:22 PM, Aaron Zeckoski wrote:
>>>>
>>>>> Brian,
>>>>> This is current functionality in the tool. You can see it on the  
>>>>> test server.
>>>>> http://qa5-us.sakaiproject.org/portal
>>>>>
>>>>> The screens Daphne sent are of a look and feel change but for the
>>>>> accessibility exercise it may make more sense to look at the  
>>>>> current
>>>>> stuff.
>>>>>
>>>>> -AZ
>>>>>
>>>>>
>>>>> On Fri, Jan 13, 2012 at 3:14 PM, Richwine, Brian L <brichwin at indiana.edu 
>>>>> > wrote:
>>>>>> Is it possible to get access to a live version of this, or is  
>>>>>> it only in the high-fidelity wireframe stage?
>>>>>>
>>>>>> It would be quite possible to label the radio buttons in the  
>>>>>> compact likert scale for accessibility without a change in the  
>>>>>> visual rendering.
>>>>>>
>>>>>> Besides using the label element, a radio button can be labeled  
>>>>>> using the title attribute. If the radio button does not have a  
>>>>>> corresponding label attribute, then most adaptive technologies  
>>>>>> will look to see if a title attribute is present and will use  
>>>>>> the title attribute as a fall back label (if present). So, the  
>>>>>> left most radio button could be labeled with the visible "Not  
>>>>>> at all" text and the right most radio button labeled with the  
>>>>>> "Very" text. The rest could be labeled using title attributes  
>>>>>> on the input element. For example:
>>>>>>
>>>>>> <label> Strongly agree <input type="radio" ...></label> <input
>>>>>> type="radio" title="agree" ...> <input type="radio"  
>>>>>> title="neutral"
>>>>>> ...> <input type="radio" title="disagree" ...> <label><input
>>>>>> type="radio" title="agree" ...> Strongly disagree</label>
>>>>>>
>>>>>> Hope this helps... The title attribute is a common technique  
>>>>>> for label form elements for adaptive technologies when the  
>>>>>> designer does not want the label to be visible. For more info,  
>>>>>> see:
>>>>>>
>>>>>> H65: Using the title attribute to identify form controls when the
>>>>>> label element cannot be used
>>>>>> http://www.w3.org/TR/WCAG20-TECHS/H65
>>>>>>
>>>>>> -Brian
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: accessibility-bounces at collab.sakaiproject.org
>>>>>> [mailto:accessibility-bounces at collab.sakaiproject.org] On  
>>>>>> Behalf Of
>>>>>> Daphne Ogle
>>>>>> Sent: Friday, January 13, 2012 2:44 PM
>>>>>> To: evaluation at collab.sakaiproject.org; Sakai Accessibility WG
>>>>>> Cc: Gary Thompson
>>>>>> Subject: [WG: Accessibility] Do radio buttons for compact  
>>>>>> likert scale have associated labels?
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> For eval sys, it looks like the inputs for the compact likert  
>>>>>> scale do not allow for associated labels.  And the endpoint  
>>>>>> labels that visually display aren't semantically associated to  
>>>>>> the end point inputs/radio buttons.  Is that true?  If so, this  
>>>>>> seems like a pretty major accessibility issue that we should  
>>>>>> look at.
>>>>>>
>>>>>> Thanks for any insight!
>>>>>>
>>>>>> - Daphne
>>>>>>
>>>>>> Daphne Ogle-Glenn
>>>>>> Senior Interaction Designer
>>>>>> University of California, Berkeley
>>>>>> Educational Technology Services
>>>>>> daphne at media.berkeley.edu
>>>>>> cell (925)348-4372
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> accessibility mailing list
>>>>>> accessibility at collab.sakaiproject.org
>>>>>> http://collab.sakaiproject.org/mailman/listinfo/accessibility
>>>>>>
>>>>>> TO UNSUBSCRIBE: send email to accessibility-unsubscribe at collab.sakaiproject.org 
>>>>>>  with a subject of "unsubscribe"
>>>>>> _______________________________________________
>>>>>> accessibility mailing list
>>>>>> accessibility at collab.sakaiproject.org
>>>>>> http://collab.sakaiproject.org/mailman/listinfo/accessibility
>>>>>>
>>>>>> TO UNSUBSCRIBE: send email to accessibility-unsubscribe at collab.sakaiproject.org 
>>>>>>  with a subject of "unsubscribe"
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
>>>>> _______________________________________________
>>>>> evaluation mailing list
>>>>> evaluation at collab.sakaiproject.org
>>>>> http://collab.sakaiproject.org/mailman/listinfo/evaluation
>>>>>
>>>>> TO UNSUBSCRIBE: send email to evaluation-unsubscribe at collab.sakaiproject.org 
>>>>>  with a subject of "unsubscribe"
>>>>>
>>>>>
>>>>
>>>
>>> Daphne Ogle-Glenn
>>> Senior Interaction Designer
>>> University of California, Berkeley
>>> Educational Technology Services
>>> daphne at media.berkeley.edu
>>> cell (925)348-4372
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>
>
>
> -- 
> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile

Daphne Ogle-Glenn
Senior Interaction Designer
University of California, Berkeley
Educational Technology Services
daphne at media.berkeley.edu
cell (925)348-4372







More information about the evaluation mailing list