RE: [WSG] Accessible likert scale (disagree/agree/strongly agree/etc) forms
I don't recommend that solution. We have tested this kind of form with a highly proficient screen reader user, and he could not understand it at all. In fact it was one of the few tasks he has ever failed to complete. This is one of those cases where marking up content so it is semantically correct does not mean it can be understood by users. I recommend using label elements for each radio button and hiding them off-screen. This was discussed at length on GAWDS very recently but I don't have time to dig out the thread. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nick Lo Sent: 03 December 2007 12:34 To: wsg@webstandardsgroup.org Subject: [WSG] Accessible likert scale (disagree/agree/strongly agree/etc) forms Hello All, I'm working on a Likert scale questionnaire (Strongly Agree/Agree/ Undecided/Disagree/Strongly Disagree) with 20 questions and some Googling came up with the following approach... http://www.enterpriseaccessibility.com/articles/ AccessibleRadioButtons.html ...and I was wondering what the general opinion of this or any other solutions was. Thanks, Nick *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Accessible likert scale (disagree/agree/strongly agree/etc) forms
Hi Nick, The sample code on this page you link to does not look ideal. As has been mentioned on this list a few times, title attributes are often ignored by screen readers. And the use of a table element to lay out the form is a little odd. Unless I am missing something, I'd say it would be much better if it marked up with standard form elements. For example (warning - code below thrown together very quickly): form action=# method=get fieldset legendThe product is a good value for the dollar/legend label for=strongly-agreeinput name=likert id=strongly-agree type=radio /strongly agree/label label for=agreeinput name=likert id=agree type=radio /agree/label label for=disagreeinput name=likert id=disagree type=radio /disagree/label label for=undecidedinput name=likert id=undecided type=radio /undecided/label label for=strongly-disagreeinput name=likert id=strongly-disagree type=radio /strongly disagree/label input name=submit id=submit type=submit value=Submit / /fieldset /form You can then use CSS (and a hammer if needed) to position these form elements exactly as you want. HTH Russ Hello All, I'm working on a Likert scale questionnaire (Strongly Agree/Agree/ Undecided/Disagree/Strongly Disagree) with 20 questions and some Googling came up with the following approach... http://www.enterpriseaccessibility.com/articles/ AccessibleRadioButtons.html *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Accessible likert scale (disagree/agree/strongly agree/etc) forms
Steve Green wrote: I recommend using label elements for each radio button and hiding them off-screen. Possibly even better for keyboard and screenreader users: swapping out the radio buttons approach with a single SELECT. However, this of course throws the expected visual design out the window... P -- Patrick H. Lauke __ re·dux (adj.): brought back; returned. used postpositively [latin : re-, re- + dux, leader; see duke.] www.splintered.co.uk | www.photographia.co.uk http://redux.deviantart.com __ Co-lead, Web Standards Project (WaSP) Accessibility Task Force http://webstandards.org/ __ Take it to the streets ... join the WaSP Street Team http://streetteam.webstandards.org/ __ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Accessible likert scale (disagree/agree/strongly agree/etc) forms
Hi Patrick, Actually I had already prepared one as an alternative version to discuss with the client so glad you brought it up independently. Nick On 04/12/2007, at 5:10 AM, Patrick H. Lauke wrote: Steve Green wrote: I recommend using label elements for each radio button and hiding them off-screen. Possibly even better for keyboard and screenreader users: swapping out the radio buttons approach with a single SELECT. However, this of course throws the expected visual design out the window... P -- Patrick H. Lauke __ re·dux (adj.): brought back; returned. used postpositively [latin : re-, re- + dux, leader; see duke.] www.splintered.co.uk | www.photographia.co.uk http://redux.deviantart.com __ Co-lead, Web Standards Project (WaSP) Accessibility Task Force http://webstandards.org/ __ Take it to the streets ... join the WaSP Street Team http://streetteam.webstandards.org/ __ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Accessible likert scale (disagree/agree/strongly agree/etc) forms
Hi Steve, I don't recommend that solution. We have tested this kind of form with a highly proficient screen reader user, and he could not understand it at all. In fact it was one of the few tasks he has ever failed to complete. This is one of those cases where marking up content so it is semantically correct does not mean it can be understood by users. I recommend using label elements for each radio button and hiding them off-screen. Yes that is what I thought. Even some vague testing with FANGS over 20 questions just looked so complex I wondered how usable even a correctly marked up one would be. For this reason I played with a SELECT solution mentioned by Patrick. Thanks, Nick This was discussed at length on GAWDS very recently but I don't have time to dig out the thread. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nick Lo Sent: 03 December 2007 12:34 To: wsg@webstandardsgroup.org Subject: [WSG] Accessible likert scale (disagree/agree/strongly agree/etc) forms Hello All, I'm working on a Likert scale questionnaire (Strongly Agree/Agree/ Undecided/Disagree/Strongly Disagree) with 20 questions and some Googling came up with the following approach... http://www.enterpriseaccessibility.com/articles/ AccessibleRadioButtons.html ...and I was wondering what the general opinion of this or any other solutions was. Thanks, Nick *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Accessible likert scale (disagree/agree/strongly agree/etc) forms
On 04/12/2007, at 12:07 AM, russ - maxdesign wrote: Hi Nick, The sample code on this page you link to does not look ideal. As has been mentioned on this list a few times, title attributes are often ignored by screen readers. And the use of a table element to lay out the form is a little odd. Unless I am missing something, I'd say it would be much better if it marked up with standard form elements. For example (warning - code below thrown together very quickly): form action=# method=get fieldset legendThe product is a good value for the dollar/legend label for=strongly-agreeinput name=likert id=strongly-agree type=radio /strongly agree/label label for=agreeinput name=likert id=agree type=radio /agree/label label for=disagreeinput name=likert id=disagree type=radio /disagree/label label for=undecidedinput name=likert id=undecided type=radio /undecided/label label for=strongly-disagreeinput name=likert id=strongly-disagree type=radio /strongly disagree/label input name=submit id=submit type=submit value=Submit / /fieldset /form You can then use CSS (and a hammer if needed) to position these form elements exactly as you want. That does help Russ, thanks. As I said to Steve though I do wonder how much fun using JAWS or such like would be going through all that for 20 similar questions! Nick *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Accessible likert scale (disagree/agree/strongly agree/etc) forms
The problem with the code below is that the content of the legend will be read before every label. That makes it very difficult for a screen reader user to read it fast. I would just have the question in a p or possibly even a header element. Once the user has read through a few questions and realises that the structure is consistent, they won't need to listen to the whole of each label and they can very quickly skip through the form. What is your opinion on the idea of using SELECT mentioned by Patrick? Nick *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Accessible likert scale (disagree/agree/strongly agree/etc) forms
Steve Green wrote: The problem with the code below is that the content of the legend will be read before every label. That makes it very difficult for a screen reader user to read it fast. I would just have the question in a p or possibly even a header element. However, if the user is in JAWS' forms mode, are headers/paragraphs not ignored (say as they're tabbing from input to input)? Sorry, been a while since I actually sat in front of a proper JAWS installation... P -- Patrick H. Lauke __ re·dux (adj.): brought back; returned. used postpositively [latin : re-, re- + dux, leader; see duke.] www.splintered.co.uk | www.photographia.co.uk http://redux.deviantart.com __ Co-lead, Web Standards Project (WaSP) Accessibility Task Force http://webstandards.org/ __ Take it to the streets ... join the WaSP Street Team http://streetteam.webstandards.org/ __ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] Accessible likert scale (disagree/agree/strongly agree/etc) forms
The problem with the code below is that the content of the legend will be read before every label. That makes it very difficult for a screen reader user to read it fast. I would just have the question in a p or possibly even a header element. Once the user has read through a few questions and realises that the structure is consistent, they won't need to listen to the whole of each label and they can very quickly skip through the form. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nick Lo Sent: 03 December 2007 22:40 To: wsg@webstandardsgroup.org Subject: Re: [WSG] Accessible likert scale (disagree/agree/strongly agree/etc) forms On 04/12/2007, at 12:07 AM, russ - maxdesign wrote: Hi Nick, The sample code on this page you link to does not look ideal. As has been mentioned on this list a few times, title attributes are often ignored by screen readers. And the use of a table element to lay out the form is a little odd. Unless I am missing something, I'd say it would be much better if it marked up with standard form elements. For example (warning - code below thrown together very quickly): form action=# method=get fieldset legendThe product is a good value for the dollar/legend label for=strongly-agreeinput name=likert id=strongly-agree type=radio /strongly agree/label label for=agreeinput name=likert id=agree type=radio /agree/label label for=disagreeinput name=likert id=disagree type=radio /disagree/label label for=undecidedinput name=likert id=undecided type=radio /undecided/label label for=strongly-disagreeinput name=likert id=strongly-disagree type=radio /strongly disagree/label input name=submit id=submit type=submit value=Submit / /fieldset /form You can then use CSS (and a hammer if needed) to position these form elements exactly as you want. That does help Russ, thanks. As I said to Steve though I do wonder how much fun using JAWS or such like would be going through all that for 20 similar questions! Nick *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] Accessible likert scale (disagree/agree/strongly agree/etc) forms
Undoubtedly it's the cleanest way to achieve the required functionality, and there are fewer accessibility issues. However, it is less easy for a user to quickly review their answers because they have to read the text rather than just look at the physical position of the selected radio button. Also it doesn't give an indication of the trend, although this will not always be relevant. For most users it will take longer to fill in a form using select rather than radio buttons; at least two actions compared with one. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nick Lo Sent: 03 December 2007 23:51 To: wsg@webstandardsgroup.org Subject: Re: [WSG] Accessible likert scale (disagree/agree/strongly agree/etc) forms The problem with the code below is that the content of the legend will be read before every label. That makes it very difficult for a screen reader user to read it fast. I would just have the question in a p or possibly even a header element. Once the user has read through a few questions and realises that the structure is consistent, they won't need to listen to the whole of each label and they can very quickly skip through the form. What is your opinion on the idea of using SELECT mentioned by Patrick? Nick *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Accessible likert scale (disagree/agree/strongly agree/etc) forms
I have made such radio inputs highlight the selected item to make it even more clear what the user has selected. Thats the radio and label obviously, not just the radio. Of course that is only possible via javascript however it still seems worthwhile. Steve Green wrote: You're right, and this is a problem we always have. Users develop different ways of approaching forms, and some will jump in and out of forms mode to make sure they read anything that is not in a label e.g. validation rules. However, in the example given, I think the legend is way too long and will deter the user from filling in the form at all. Without user testing you can't be certain what people will do, but my experience suggests that users will work out that they need to go in and out of forms mode, and that it is not unduly onerous to do so. As long as the structure is consistent they will be able to navigate quickly. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Patrick H. Lauke Sent: 04 December 2007 00:00 To: wsg@webstandardsgroup.org Subject: Re: [WSG] Accessible likert scale (disagree/agree/strongly agree/etc) forms Steve Green wrote: The problem with the code below is that the content of the legend will be read before every label. That makes it very difficult for a screen reader user to read it fast. I would just have the question in a p or possibly even a header element. However, if the user is in JAWS' forms mode, are headers/paragraphs not ignored (say as they're tabbing from input to input)? Sorry, been a while since I actually sat in front of a proper JAWS installation... P *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] Accessible likert scale (disagree/agree/strongly agree/etc) forms
You're right, and this is a problem we always have. Users develop different ways of approaching forms, and some will jump in and out of forms mode to make sure they read anything that is not in a label e.g. validation rules. However, in the example given, I think the legend is way too long and will deter the user from filling in the form at all. Without user testing you can't be certain what people will do, but my experience suggests that users will work out that they need to go in and out of forms mode, and that it is not unduly onerous to do so. As long as the structure is consistent they will be able to navigate quickly. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Patrick H. Lauke Sent: 04 December 2007 00:00 To: wsg@webstandardsgroup.org Subject: Re: [WSG] Accessible likert scale (disagree/agree/strongly agree/etc) forms Steve Green wrote: The problem with the code below is that the content of the legend will be read before every label. That makes it very difficult for a screen reader user to read it fast. I would just have the question in a p or possibly even a header element. However, if the user is in JAWS' forms mode, are headers/paragraphs not ignored (say as they're tabbing from input to input)? Sorry, been a while since I actually sat in front of a proper JAWS installation... P -- Patrick H. Lauke __ re.dux (adj.): brought back; returned. used postpositively [latin : re-, re- + dux, leader; see duke.] www.splintered.co.uk | www.photographia.co.uk http://redux.deviantart.com __ Co-lead, Web Standards Project (WaSP) Accessibility Task Force http://webstandards.org/ __ Take it to the streets ... join the WaSP Street Team http://streetteam.webstandards.org/ __ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
