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

[Daphne Ogle]

Hmmm... interesting point Gonzalo.  I like your thinking.  And in fact  
it really helps us at Berkeley because we don't have textual  
descriptors for each choice.  Building on your recast, is there a way  
to technically handle this (sorry if this is totally naive coming from  
someone that doesn't code) if the screen reader read something like  
you are suggesting.  Then how could we take their input?  Could they  
use a number key pad somehow?

-Daphne

On Jan 13, 2012, at 12:42 PM, gsilver wrote:

> 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"
>>
>>
>
> _______________________________________________
> 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