Re: [WSG] strong element being more semantical and accessible for required field
i have written up results from some tests i carried out: Screen Readers lack emphasis - http://www.paciellogroup.com/blog/?p=41 On 27/02/2008, tee [EMAIL PROTECTED] wrote: Hi Steven, On Feb 26, 2008, at 6:49 AM, Steven Faulkner wrote: don't know if this has been pointed out yet, but as far as screen readers like JAWS and Window Eyes are concerned the strong element does not convey any meaning. It is not recognised by them. bottom line is that for users these screen readers using strong as an indication of a required field won't be of any help. Thanks for the great info. Exactly what I am after. I like the way Mike grouped the required elements, will borrow the idea for the next form. tee *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** -- with regards Steve Faulkner Technical Director - TPG Europe Director - Web Accessibility Tools Consortium www.paciellogroup.com | www.wat-c.org Web Accessibility Toolbar - http://www.paciellogroup.com/resources/wat-ie-about.html *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] strong element being more semantical and accessible for required field
Hi Matt, I guess I would prefer verbose and have them fill the form out once than have them have them misinterpret and have to fix errors, [...] I agree. [...] which I imagine can be tedious using a screen reader. Is this the case? Can be a horror show. My understanding is that client side (using JavaScript alerts) is actually pretty accessible. For server side, my v2 [1] form script bookmarks the success/error message (#results) bringing the user directly to the message. The message tells them what's wrong, they go back and fix the issue. Going back doesn't take them directly to the culprit input so they have to navigate to it. This is the version (modified a bit more) I'm using (have to for now) on the site I had mentioned. The error management was noted, favorably. Even better, dare I say the best way, is how I manage errors on my v3 [2] form. The user is directed to the error, on the same page, and links are provided taking the user directly to the culprit input/s. All errors now do this, and some take it a step further. For example, if the anti-spam question is wrong the script returns the error, a link, and also gives the user the right answer (my attempt to better satisfy the needs of those with cognitive disabilities). Also, there is a honeypot input (to lure 'bots). Users are told to keep it empty in the label, but if they mistakenly fill it in they are notified of the error, the input is cleared for them, and they are given a link to the submit and asked to try again. Balancing accessibility and the security is delicate. It would be great if you could keep us posted about any feedback you get in March when the site goes live. Will do. Nothing's perfect so I'm sure I'll get useful feedback from people who see it. Hope so anyway. what I think I will do is run a few simple A\B tests on some of my sites and log the amount of JavaScript errors for each of the different methods described That'd be great, Matt. Thanks. Mike Live Demo Forms: [1] http://green-beast.com/gbcf/gbcf_form.php [2] http://green-beast.com/gbcf-v3/test-form.php *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] strong element being more semantical and accessible for required field
don't know if this has been pointed out yet, but as far as screen readers like JAWS and Window Eyes are concerned the strong element does not convey any meaning. It is not recognised by them. They do not change the way text within strong elements are announced, but neither do they do it for em or b or i etc. JAWS does have a speech and sound scheme that includes modified announements of italicised or bolded text (amogst other things), this is not a default scheme, though and is provided for tasks such as proofreading. but this facility is based on how the text is rendered on screen, not on how it is marked up. bottom line is that for users these screen readers using strong as an indication of a required field won't be of any help. On 25/02/2008, tee [EMAIL PROTECTED] wrote: I have this question about strong element being more semantical and accessible for required field in the web form and like to hear your opinion. I came to the conclusion after conducting my little user testing - it first started with an intention of spam and error monitoring over the form script I use, I then learned that despite the indication that asterisk is marked as required field, many people who took time to submit the forms on clients' sites still missed the *. Because I use no JS validation for the form, I decided to bold the required field using strong element for two new sites. It seems working as the bold texts caught people attention and I received no errors email notification on missing to enter requried fields. The result also gave me a though on how screen readers treat the strong element and that it's indeed more accessible and semantically correct. Working on a site, and thanks to Matt Fellows and his futher assistance, I implemented his JS form validation script to the web form. Using asterik to indicate the required field no longer is an issue with JS validation, however I decided to stick with the strong element. Much work had put into it to modify the code and css, but client came back to me to want the '*' over the strong because it's a conventional practice. Really want to stick with the strong element for the reason above, however I am also doubting my conclusion that it's more accessible for screen readers as I never tested on one. Before I try to convince client the strong element is better approach, I would love to hear your opinion. Thank you! tee *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** -- with regards Steve Faulkner Technical Director - TPG Europe Director - Web Accessibility Tools Consortium www.paciellogroup.com | www.wat-c.org Web Accessibility Toolbar - http://www.paciellogroup.com/resources/wat-ie-about.html *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] strong element being more semantical and accessible for required field
Something quick I just thought of was that you could use some small icon to indicate required fields, and specify the alt for that to say required. That way, sighted users don't have to look at the word required repeated 50 times, while unsighted users will be able to hear that the field is required. Just a thought. Steven Faulkner wrote: don't know if this has been pointed out yet, but as far as screen readers like JAWS and Window Eyes are concerned the strong element does not convey any meaning. It is not recognised by them. They do not change the way text within strong elements are announced, but neither do they do it for em or b or i etc. JAWS does have a speech and sound scheme that includes modified announements of italicised or bolded text (amogst other things), this is not a default scheme, though and is provided for tasks such as proofreading. but this facility is based on how the text is rendered on screen, not on how it is marked up. bottom line is that for users these screen readers using strong as an indication of a required field won't be of any help. On 25/02/2008, *tee* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I have this question about strong element being more semantical and accessible for required field in the web form and like to hear your opinion. I came to the conclusion after conducting my little user testing - it first started with an intention of spam and error monitoring over the form script I use, I then learned that despite the indication that asterisk is marked as required field, many people who took time to submit the forms on clients' sites still missed the *. Because I use no JS validation for the form, I decided to bold the required field using strong element for two new sites. It seems working as the bold texts caught people attention and I received no errors email notification on missing to enter requried fields. The result also gave me a though on how screen readers treat the strong element and that it's indeed more accessible and semantically correct. Working on a site, and thanks to Matt Fellows and his futher assistance, I implemented his JS form validation script to the web form. Using asterik to indicate the required field no longer is an issue with JS validation, however I decided to stick with the strong element. Much work had put into it to modify the code and css, but client came back to me to want the '*' over the strong because it's a conventional practice. Really want to stick with the strong element for the reason above, however I am also doubting my conclusion that it's more accessible for screen readers as I never tested on one. Before I try to convince client the strong element is better approach, I would love to hear your opinion. Thank you! tee *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] *** -- with regards Steve Faulkner Technical Director - TPG Europe Director - Web Accessibility Tools Consortium www.paciellogroup.com http://www.paciellogroup.com | www.wat-c.org http://www.wat-c.org Web Accessibility Toolbar - http://www.paciellogroup.com/resources/wat-ie-about.html *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** -- Christian Snodgrass Azure Ronin Web Design http://www.arwebdesign.net/ http://www.arwebdesign.net Phone: 859.816.7955 *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] strong element being more semantical and accessible for required field
Hi Steven, On Feb 26, 2008, at 6:49 AM, Steven Faulkner wrote: don't know if this has been pointed out yet, but as far as screen readers like JAWS and Window Eyes are concerned the strong element does not convey any meaning. It is not recognised by them. bottom line is that for users these screen readers using strong as an indication of a required field won't be of any help. Thanks for the great info. Exactly what I am after. I like the way Mike grouped the required elements, will borrow the idea for the next form. tee *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] strong element being more semantical and accessible for required field
On Feb 25, 2008, at 3:34 PM, tee wrote: I have this question about strong element being more semantical and accessible for required field in the web form and like to hear your opinion. I came to the conclusion after conducting my little user testing - it first started with an intention of spam and error monitoring over the form script I use, I then learned that despite the indication that asterisk is marked as required field, many people who took time to submit the forms on clients' sites still missed the *. Because I use no JS validation for the form, I decided to bold the required field using strong element for two new sites. It seems working as the bold texts caught people attention and I received no errors email notification on missing to enter requried fields. The result also gave me a though on how screen readers treat the strong element and that it's indeed more accessible and semantically correct. Working on a site, and thanks to Matt Fellows and his futher assistance, I implemented his JS form validation script to the web form. Using asterik to indicate the required field no longer is an issue with JS validation, however I decided to stick with the strong element. Much work had put into it to modify the code and css, but client came back to me to want the '*' over the strong because it's a conventional practice. Really want to stick with the strong element for the reason above, however I am also doubting my conclusion that it's more accessible for screen readers as I never tested on one. Before I try to convince client the strong element is better approach, I would love to hear your opinion. I can't speak for screen readers since I've never used one my self... But would there be any reason you couldn't do both and please the client and the screen reader(assuming it does help them)? a simple strong* First Name/strong Just something I thought of :) -- Jason Pruim Raoset Inc. Technology Manager MQC Specialist 3251 132nd ave Holland, MI, 49424-9337 www.raoset.com [EMAIL PROTECTED] *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] strong element being more semantical and accessible for required field
I can't speak for screen readers since I've never used one my self...
But would there be any reason you couldn't do both and please the
client and the screen reader(assuming it does help them)? a simple
strong* First Name/strong
Just something I thought of :)
Interesting discussion. You could also use more meaningful flags like the
word Required instead of * and style this content in red/bold. This
means that everyone, including screen reader users understand the
implications much more clearly (as long as this information is included
inside the label element.
For example:
label for=details-email
Email span class=required(Required)/span:
/label
Or...
label for=details-email
Email strong(Required)/strong:
/label
Then you could easily style it with something like:
label strong (or label span.required)
{
color: red;
font-weight: bold
text-transform: uppercase;
font-size: 85%;
}
You can even position this required content after the input element
using absolute positioning as Derek Featherstone has proposed.
HTH
Russ
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] strong element being more semantical and accessible for required field
Interesting indeed!
Actually Tee I was going to pose the same question to the list
following our discussions the other day :) I would like to get it
right in GValidator so the core doesn't need to be modified by clients
such as yourself.
I would like to see the results of reliable and publicly available
research. Does anyone know of any? A quick Google search doesn't turn
up anything overly exciting or empirical.
Maybe we can do some testing of our own?
So there are actually three interrelated things here: The first is the
semantics of the span class=required*/span element, then there
is the usability and accessibility of it's use.
In terms of usability and accessibility, my initial thoughts would be
that given a sufficiently prominant key just before and in close
proximity to the form, that sighted users should have no problem
identifying which form elements need to be filled in. Users with
screen readers however might have a little more trouble with this
approach, so an approach similar to Russ's suggestion seems like the
best approach.
In terms of semantics, w3c says this about the strong element:
The strong element indicates higher importance for its contents than
that of the surrounding content.
I am unsure as to if it is more important that the label? But I can
see a clear benefit for blind users. So what do we do?
Cheers,
Matt
P.S. Although a while away, we do have these sorts of things to look forward to:
* http://www.w3.org/TR/2008/WD-html5-diff-20080122/#new-attributes
* http://www.w3.org/TR/WCAG20-TECHS/ARIA2.html
On 2/26/08, russ - maxdesign [EMAIL PROTECTED] wrote:
I can't speak for screen readers since I've never used one my self...
But would there be any reason you couldn't do both and please the
client and the screen reader(assuming it does help them)? a simple
strong* First Name/strong
Just something I thought of :)
Interesting discussion. You could also use more meaningful flags like the
word Required instead of * and style this content in red/bold. This
means that everyone, including screen reader users understand the
implications much more clearly (as long as this information is included
inside the label element.
For example:
label for=details-email
Email span class=required(Required)/span:
/label
Or...
label for=details-email
Email strong(Required)/strong:
/label
Then you could easily style it with something like:
label strong (or label span.required)
{
color: red;
font-weight: bold
text-transform: uppercase;
font-size: 85%;
}
You can even position this required content after the input element
using absolute positioning as Derek Featherstone has proposed.
HTH
Russ
***
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] strong element being more semantical and accessible for required field
On Behalf Of russ - maxdesign Sent: Monday, February 25, 2008 1:37 PM To: Web Standards Group Subject: Re: [WSG] strong element being more semantical and accessible for required field I can't speak for screen readers since I've never used one my self... But would there be any reason you couldn't do both and please the client and the screen reader(assuming it does help them)? a simple strong* First Name/strong Just something I thought of :) Interesting discussion. You could also use more meaningful flags like the word Required instead of * and style this content in red/bold. This means that everyone, including screen reader users understand the implications much more clearly (as long as this information is included inside the label element. For example: label for=details-email Email span class=required(Required)/span: /label What about using a fieldset with *legend* if the required fields can be grouped together. Because the legend (required fields) would be read aloud before each label. -- Regards, Thierry | http://www.TJKDesign.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] strong element being more semantical and accessible for required field
What about using a fieldset with *legend* if the required fields can be grouped together. Because the legend (required fields) would be read aloud before each label. I thought about this, but I think it makes more sense to have related elements grouped together and in most cases not all of these will be required. For example, many forms ask for personal details such as addresses, phone numbers, work details etc. Not all will be mandatory, but it definately makes sense to group these together. I think it might be a little confusing to enter in details out of order, especially if the form is broken over several pages (have I already entered this information?). Cheers, Matt *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] strong element being more semantical and accessible for required field
I believe a more semantically correct method would be to use strong: label for=details-email Email: strong(Required)/strong /label Darren Lovelock Munky Online Web Design http://www.munkyonline.co.uk T: +44 (0)20-8816-8893 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thierry Koblentz Sent: 26 February 2008 00:02 To: wsg@webstandardsgroup.org Subject: RE: [WSG] strong element being more semantical and accessible for required field On Behalf Of russ - maxdesign Sent: Monday, February 25, 2008 1:37 PM To: Web Standards Group Subject: Re: [WSG] strong element being more semantical and accessible for required field I can't speak for screen readers since I've never used one my self... But would there be any reason you couldn't do both and please the client and the screen reader(assuming it does help them)? a simple strong* First Name/strong Just something I thought of :) Interesting discussion. You could also use more meaningful flags like the word Required instead of * and style this content in red/bold. This means that everyone, including screen reader users understand the implications much more clearly (as long as this information is included inside the label element. For example: label for=details-email Email span class=required(Required)/span: /label What about using a fieldset with *legend* if the required fields can be grouped together. Because the legend (required fields) would be read aloud before each label. -- Regards, Thierry | http://www.TJKDesign.com *** 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] strong element being more semantical and accessible for required field
What about abbr title=Required*/abbr? tee wrote: I have this question about strong element being more semantical and accessible for required field in the web form and like to hear your opinion. I came to the conclusion after conducting my little user testing - it first started with an intention of spam and error monitoring over the form script I use, I then learned that despite the indication that asterisk is marked as required field, many people who took time to submit the forms on clients' sites still missed the *. Because I use no JS validation for the form, I decided to bold the required field using strong element for two new sites. It seems working as the bold texts caught people attention and I received no errors email notification on missing to enter requried fields. The result also gave me a though on how screen readers treat the strong element and that it's indeed more accessible and semantically correct. Working on a site, and thanks to Matt Fellows and his futher assistance, I implemented his JS form validation script to the web form. Using asterik to indicate the required field no longer is an issue with JS validation, however I decided to stick with the strong element. Much work had put into it to modify the code and css, but client came back to me to want the '*' over the strong because it's a conventional practice. Really want to stick with the strong element for the reason above, however I am also doubting my conclusion that it's more accessible for screen readers as I never tested on one. Before I try to convince client the strong element is better approach, I would love to hear your opinion. Thank you! tee *** 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] strong element being more semantical and accessible for required field
Hi Mike, What about using a fieldset with *legend* if the required fields can be grouped together. Because the legend (required fields) would be read aloud before each label. In some cases that's an excellent solution (what I've been using for a while) but unfortunately power users will dial down verbosity so much that they will quiet legends as well. A blind power user I know told me * is best. He also told me nothing else is needed, but he's a person and that part my be his opinion. For all-around safety, one of these might be best: label* denotes required field/label fieldset legendRequired/legend label for=nameName * input name=name label for=emailEmail * input name=email /fieldset fieldset legendRequired/legend label for=nameName (required) input name=name label for=emailEmail (required) input name=email /fieldset I think using legend *and* plain text in the label may be a bit overkill. If I get it right, best case scenario the user listens to it once, worst case scenario the text in the label is repeated after the legend :-( imho, if it is part of the label already, then I'd not use legend. I don't think we should make it super safe as it could create UE issues on its own; if only legend is used and the user misses it because of his custom settings, then hopefully the validation routine will bring him to a place where he'll be able to find out what went wrong. -- Regards, Thierry | http://www.TJKDesign.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] strong element being more semantical and accessible for required field
Darren Lovelock wrote:
I believe a more semantically correct method would be to use strong:
label for=details-email
Email: strong(Required)/strong
/label
Indeed, that's the approach I've taken in recent years. For aesthetic
considerations, I sometimes style drop in a style like
label strong { font-weight: normal; font-size: 0.75em; }
to make it less obtrusive, but still quite readable and understandable.
It may make labels slightly longer, but on the plus side it saves those
awful * denotes a required field explanations and is immediately obvious.
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/
__
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] strong element being more semantical and accessible for required field
On Feb 25, 2008, at 1:05 PM, Jason Pruim wrote: I can't speak for screen readers since I've never used one my self... But would there be any reason you couldn't do both and please the client and the screen reader(assuming it does help them)? a simple strong* First Name/strong Just something I thought of :) Hi Jason, That was my first thought for a quick fix actually :) I thought strong* First Name/strong is a bit too excessive. Will the screen reader reads out asterisk strong? That maybe annoying for the ears. tee *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] strong element being more semantical and accessible for required field
On Feb 25, 2008, at 4:55 PM, Darren Lovelock wrote: I believe a more semantically correct method would be to use strong: label for=details-email Email: strong(Required)/strong /label Same here. One of the reason I dislike using fieldset is that FF and IE are both buggy with the legend. If a form needs extra visual styling, it takes more codes to make these two browsers behave. tee *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] strong element being more semantical and accessible for required field
In some cases that's an excellent solution (what I've been using for a while) but unfortunately power users will dial down verbosity so much that they will quiet legends as well. A blind power user I know told me * is best. He also told me nothing else is needed, but he's a person and that part my be his opinion. For all-around safety, one of these might be best: Thanks Mike that's really interesting. I would argue, based on the anecdotal evidence you've given, that the following legend is superflous and prevents logical grouping. fieldset legendRequired/legend label for=nameName (required) input name=name label for=emailEmail (required) input name=email /fieldset I am definitely leaning toward the following: fieldset legendPersonal Details/legend label for=nameName span class=required(required)/span/label input name=name label for=emailEmail span class=required(required)/span/label input name=email label for=phonePhone/label input name=phone ... /fieldset Giving in to other's suggestions perhaps the span class=required could become strong class=required :) The benefits here are: * Easily scannable for the regular user * Will be read out for screen readers * Semantically intact * Inputs can be grouped logically * No need for annoying legends Does this seem to be a combination of the general consensus? *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] strong element being more semantical and accessible for required field
Hi Matt, that the following legend is superflous and prevents logical grouping. fieldset legendRequired/legend label for=nameName (required) input name=name label for=emailEmail (required) input name=email /fieldset I agree, actually. With that example (and the image one I gave) using the word required, in the case of a user listening with a setting that reads the legends (default), would make it too verbose. It'd read: Required Name Required Required Email Required Though I guess there'd be no missing it. ;-) The use of the Required legend seems to work well with the asterisk, with its meaning defined in a non-associated label (one with no for attribute). It's a compromise method. I do have one form on a real-deal AAA WCAG 2.0 site I made (to be officially announced Mar. 11-12th) with this specific configuration. It's open now by invite to a few disabled users/testers and a couple of key WCAG 2.0 Editors, and I got more very positive comments about that particular set-up tonight... a few minutes ago actually. fieldset legendPersonal Details/legend label for=nameName span class=required(required)/span/label input name=name That is a solid method for sure, but there's only one problem and that is to *some* users (default settings) it might sound too verbose. Personal Details Name Required Personal Details Email Required Personal Details Phone The problem is not the technique, yours or mine, or any of the other accessible methods. It's the myriad configurations possible that really challenge us. There are so many variables (not even including those of sighted users) that while there are a number of feasible methods, there seems no perfect one-size fits-all answer. It's all a compromise. Mike *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] strong element being more semantical and accessible for required field
Thanks Mike. I guess I would prefer verbose and have them fill the form out once than have them have them misinterpret and have to fix errors, which I imagine can be tedious using a screen reader. Is this the case? It would be great if you could keep us posted about any feedback you get in March when the site goes live. For the average user however, what I think I will do is run a few simple A\B tests on some of my sites and log the amount of JavaScript errors for each of the different methods described (there seems to be at least three plausible options). It will take some time to get statistical significance however so it might be a while before I have something useful. Cheers, Matt On 2/26/08, Mike at Green-Beast.com [EMAIL PROTECTED] wrote: Hi Matt, that the following legend is superflous and prevents logical grouping. fieldset legendRequired/legend label for=nameName (required) input name=name label for=emailEmail (required) input name=email /fieldset I agree, actually. With that example (and the image one I gave) using the word required, in the case of a user listening with a setting that reads the legends (default), would make it too verbose. It'd read: Required Name Required Required Email Required Though I guess there'd be no missing it. ;-) The use of the Required legend seems to work well with the asterisk, with its meaning defined in a non-associated label (one with no for attribute). It's a compromise method. I do have one form on a real-deal AAA WCAG 2.0 site I made (to be officially announced Mar. 11-12th) with this specific configuration. It's open now by invite to a few disabled users/testers and a couple of key WCAG 2.0 Editors, and I got more very positive comments about that particular set-up tonight... a few minutes ago actually. fieldset legendPersonal Details/legend label for=nameName span class=required(required)/span/label input name=name That is a solid method for sure, but there's only one problem and that is to *some* users (default settings) it might sound too verbose. Personal Details Name Required Personal Details Email Required Personal Details Phone The problem is not the technique, yours or mine, or any of the other accessible methods. It's the myriad configurations possible that really challenge us. There are so many variables (not even including those of sighted users) that while there are a number of feasible methods, there seems no perfect one-size fits-all answer. It's all a compromise. Mike *** 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] ***
