Re: [WSG] Cynthia Reports Warnings 9.4 and 9.5 as relates to form

2006-11-10 Thread Terrence Wood


On 11/11/2006, at 4:49 AM, Mike at Green-Beast.com wrote:
 the label should probably be the same as the name (and the ID, if  
needed, may as well match too).


Disagree Mike, the name attribute on form controls is used server  
side to process the form. Example: radios should/could have the same  
name. Don't confuse it with the name attribute on other elements.




 Strongly  
Agree

 Agree
 Ambivalentlabel>


kind regards
Terrence Wood.




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***



Re: [WSG] Cynthia Reports Warnings 9.4 and 9.5 as relates to form

2006-11-10 Thread Mike at Green-Beast.com
Nick wrote:
> For other input fields, the name is needed if the form is going to be
submitted to the server, as otherwise there's no way to form a
name:value pair, and so the field can't be submitted.

Good to know. I've always used the name attribute on form inputs. Now I know 
why ;-)

Mike




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***



Re: [WSG] Cynthia Reports Warnings 9.4 and 9.5 as relates to form

2006-11-10 Thread Mike at Green-Beast.com
Patrick wrote:
> [...] the ID can't match the name, as the former needs to be unique [...]

Good point Patrick. Being it's a radio button you're right on.

---

David wrote:
> You mean the text used to label the control with should be the same as
the value of the name and id attributes?

Actually I didn't mean the label text but label for="" attribute.

> Why alt text on a radio button? The purpose of the attribute is to
provide an textual alternative for image inputs.

I just copied what Mel posted and I agree that the alt attribute isn't 
needed in that. I wouldn't use it.

---

Emma wrote:
> Being picky, the name isn't actually required (unless being used in
scripts etc).

True. Most of my work is scripted so I tend to use the name attribute.

---

My main focus was to have a label's for attribute match but I understand 
there are unique circumstances here being it's a radio button.

Have a great weekend everyone.

Mike



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***



Re: [WSG] Cynthia Reports Warnings 9.4 and 9.5 as relates to form

2006-11-10 Thread Nick Fitzsimons

On 10 Nov 2006, at 16:11:14, Emma Sax wrote:


alt="make

your mark" id="answer" />Text


Being picky, the name isn't actually required (unless being used in
scripts etc).  The 'for' attribute of the label gets matched with the
'id' attribute of the associated form field.



The name is needed for each member of a group of radio buttons: it's  
how they're grouped.


For other input fields, the name is needed if the form is going to be  
submitted to the server, as otherwise there's no way to form a  
name:value pair, and so the field can't be submitted.


Cheers,

Nick.
--
Nick Fitzsimons
http://www.nickfitz.co.uk/





***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***



RE: [WSG] Cynthia Reports Warnings 9.4 and 9.5 as relates to form

2006-11-10 Thread Emma Sax
> I echo what Mel said, though I'd like to add that the label should
> probably
> be the same as the name (and the ID, if needed, may as well match
too).
> 
> Text

Being picky, the name isn't actually required (unless being used in
scripts etc).  The 'for' attribute of the label gets matched with the
'id' attribute of the associated form field.

M


**
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
[EMAIL PROTECTED] or the sender of the e-mail.

It is your responsibility to protect your system from viruses and any other  
harmful code or device. This e-mail message has been scanned for the presence 
of computer viruses; However LMUK accepts no liability for any which remain. We 
may monitor or access any or all e-mails sent to us.

**



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***



Re: [WSG] Cynthia Reports Warnings 9.4 and 9.5 as relates to form

2006-11-10 Thread David Dorward
On Fri, Nov 10, 2006 at 10:49:43AM -0500, Mike at Green-Beast.com wrote:
> I echo what Mel said, though I'd like to add that the label should probably 
> be the same as the name (and the ID, if needed, may as well match too).

You mean the text used to label the control with should be the same as
the value of the name and id attributes?

That is not always reasonable. The two key examples being multilingual
websites and radio buttons (where the name and id have to be different).
 
> Text

Why alt text on a radio button? The purpose of the attribute is to
provide an textual alternative for image inputs.

-- 
David Dorward  http://dorward.me.uk



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***



RE: [WSG] Cynthia Reports Warnings 9.4 and 9.5 as relates to form

2006-11-10 Thread Patrick Lauke
> Mike at Green-Beast.com

> I echo what Mel said, though I'd like to add that the label 
> should probably 
> be the same as the name (and the ID, if needed, may as well 
> match too).

Just being mindful that obviously, for radio buttons, the ID can't match the 
name, as the former needs to be unique, while the latter needs to match the 
other radio buttons in the same group so that they're mutually exclusive.

P

Patrick H. Lauke
Web Editor
External Relations Division
University of Salford
Room 113, Faraday House
Salford, Greater Manchester
M5 4WT
UK

T +44 (0) 161 295 4779
[EMAIL PROTECTED]

www.salford.ac.uk

A GREATER MANCHESTER UNIVERSITY  


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***



Re: [WSG] Cynthia Reports Warnings 9.4 and 9.5 as relates to form

2006-11-10 Thread Mike at Green-Beast.com
Hello Sharon,

I echo what Mel said, though I'd like to add that the label should probably 
be the same as the name (and the ID, if needed, may as well match too).

Text

Respectfully,
Mike Cherim




- Original Message - 
From: "Mel" <[EMAIL PROTECTED]>
To: 
Sent: Friday, November 10, 2006 10:07 AM
Subject: Re: [WSG] Cynthia Reports Warnings 9.4 and 9.5 as relates to form


on 10/11/2006 05:03 [EMAIL PROTECTED] said the following:
> Please could someone tell me what I'm obviously missing?


Your text for each input isn't enclosed by the label element so the
explicit association is being lost.

Instead of:

Text

It should be

Text


Personally I'd also:

1. Scrap the accesskeys. All of the keys you're using conflict with
keystrokes reserved for JAWS, Home Page Reader, Firefox/Mozilla and
Opera 7:

http://www.wats.ca/show.php?contentid=43

2. Get rid of the tabindexing. If your natural tab order is intuitive,
you don't need it. The last thing you should do is interfere with the
intuitive tab ordering on a page. It can drive keyboard navigators up
the wall.

3. Get rid of the tabled layout. What you posted is simple enough to
achieve without tabling.

4. Change the title attribute on your link from "Off Site Link" to
"Opens in new window". In fact, consider either not spawning a new
window or placing the warning in clear text and, if necessary, using css
to position it offscreen. A significant number of screen reader users
configure their software to ignore the title attribute (because it's so
over-used) so will not be pre-warned about the new window.

Automated accessibility parser warnings about tab indexes and access
keys can be safely ignored provided you've actually tested the keybaord
navigation of the page yourself and you're happy that it behaves logically.

Hope that helps

Mel





***
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] Cynthia Reports Warnings 9.4 and 9.5 as relates to form

2006-11-10 Thread Mel

on 10/11/2006 05:03 [EMAIL PROTECTED] said the following:
Please could someone tell me what I'm obviously missing? 



Your text for each input isn't enclosed by the label element so the 
explicit association is being lost.


Instead of:

Text


It should be

Text



Personally I'd also:

1. Scrap the accesskeys. All of the keys you're using conflict with 
keystrokes reserved for JAWS, Home Page Reader, Firefox/Mozilla and 
Opera 7:


http://www.wats.ca/show.php?contentid=43

2. Get rid of the tabindexing. If your natural tab order is intuitive, 
you don't need it. The last thing you should do is interfere with the 
intuitive tab ordering on a page. It can drive keyboard navigators up 
the wall.


3. Get rid of the tabled layout. What you posted is simple enough to 
achieve without tabling.


4. Change the title attribute on your link from "Off Site Link" to 
"Opens in new window". In fact, consider either not spawning a new 
window or placing the warning in clear text and, if necessary, using css 
to position it offscreen. A significant number of screen reader users 
configure their software to ignore the title attribute (because it's so 
over-used) so will not be pre-warned about the new window.


Automated accessibility parser warnings about tab indexes and access 
keys can be safely ignored provided you've actually tested the keybaord 
navigation of the page yourself and you're happy that it behaves logically.


Hope that helps

Mel





***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***



[WSG] Cynthia Reports Warnings 9.4 and 9.5 as relates to form

2006-11-09 Thread sharron




Please 
could someone tell me what I'm obviously missing? Below are WARNING results for 
Cynthia test as relates to the form shown at the bottom. Thanks for any 
help.
 
Sharron
 
HiSoftware® Cynthia Says™ - Web Content Accessibility Report
 
9.4 Create a logical tab order through 
links, form controls, and objects. 


  Rule: 9.4.1 - All Anchor, AREA, BUTTON, INPUT, OBJECT, SELECT and TEXTAREA 
  elements are required to use the 'tabindex' attribute. 
  
Warning - One or more Anchor, AREA, BUTTON, INPUT, OBJECT, SELECT and 
TEXTAREA elements do not use the 'tabindex' attribute.  Warning 
 
9.5 Provide keyboard shortcuts to important 
links (including those in client-side image maps), form controls, and groups of 
form controls. 


  Rule: 9.5.1 - All Anchor, AREA, BUTTON, INPUT, LABEL, LEGEND, and TEXTAREA 
  elements are required to use the 'accesskey' attribute. 
  
Warning - One or more Anchor, AREA, BUTTON, INPUT, LABEL, LEGEND, and 
TEXTAREA elements do not use the 'accesskey' attribute.    Warning
This one does not say not 
passed or warning, but it does not say it passed either
 10.2 Until user agents support explicit associations 
between labels and form controls, for all form controls with implicitly 
associated labels, ensure that the label is properly positioned. 


  Rule: 10.2.1 - Identify all LABEL elements used within FORM elements. 
  
Note: LABEL Element found at Line: 109, Column: 66 is in FORM element at 
Line: 109, Column: 1.
Note: LABEL Element found at Line: 118, Column: 1 is in FORM element at 
Line: 109, Column: 1.
Note: LABEL Element found at Line: 119, Column: 1 is in FORM element at 
Line: 109, Column: 1.
Note: LABEL Element found at Line: 120, Column: 1 is in FORM element at 
Line: 109, Column: 1.
Note: LABEL Element found at Line: 121, Column: 1 is in FORM element at 
Line: 109, Column: 1.
Note: LABEL Element found at Line: 122, Column: 1 is in FORM element at 
Line: 109, Column: 1.
Note: LABEL Element found at Line: 123, Column: 1 is in FORM element at 
Line: 109, Column: 1.
Note: LABEL Element found at Line: 124, Column: 1 is in FORM element at 
Line: 109, Column: 1.
Note: LABEL Element found at Line: 130, Column: 5 is in FORM element at 
Line: 109, Column: 1.
 
Form :



Vote:Text...TextTextTextTextTextTextbr />Texthttp://www.###" target="_blank" title="Off Site 
Link">Text
 
 
 

***List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfmUnsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfmHelp: [EMAIL PROTECTED]***