Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

Working with a 3rd party vendor for a SP 2010 implementation. Have noticed that form elements are not so desirable in that we're not getting our markup replicated 100% when it comes to label "for" attributes matching corresponding input "id" attributes. This is so if you click on the label, for example, the radio button becomes checked. It basically makes for much larger target/clickable areas, which are much better for users.

<input id="php_member" type="radio" name="member" checked="checked">
<label for="php_member">PHP member</label>

I've filed a bug on this and here is the developers response:

"The for/id attributes combination won't work in sharepoint for serverside controls. The example you given above is for html controls and when we make them to run at server side sharepoint will automatically change the values for 'ID' and 'name' attributes for all server side controls on every webpart page. I mean the following tags: ( No PHP member ID) will appear as follows on a sharepoint page (As we added runat="server") : No PHP member ID Thus 'for/id' is not maintained here. Sharepoint does this because a webpart can be added multiple times on a page and a page donot allow two controls with same Id."

I understand what he's saying, I'm just wondering if it's possible in 2010 to correct this. I don't know why these are server side controls or if they really need to be - I assume so, otherwise they would have been implemented some other way.

Can you not tie for/id elements together? This is one of the basic things you can do to make your forms more accessible. I'm obviously not a SP dev so here I am seeking any info we can possibly look into. :)

share|improve this question

2 Answers 2

Moving on from my comments on my other answer: here's a code sample which I think may work (using server side controls)

Label myLabel = new Label();
Button myButton = new Button();

myLabel.Text = "Do something: ";
myButton.Text = "Go!";

myLabel.AssociatedControlID = myButton.ClientID;

I think this should produce markup close to this:

<label for="[guid]">Do Something: </label> 
<input id="[guid]" type="Button" value="Go!" />
share|improve this answer
    
Cool, thanks, I've included this info as well. –  user2558 Mar 4 '11 at 17:57

Nope, you can't. Not in SharePoint. As the developer said, it's because a web part could be added many times in a page, breaking the "uniqueness" of the id attribute in the tags. This ensures the markup stays as close to XHTML 4 Strict as it can get.

If you really, really wanted your form elements to render this way, render it manually through an ASP Literal tag - though you loose the safety of the uniqueness of that element if another web part was added.

share|improve this answer
    
The web part won't be added many times in a page, it's a form. It isn't like a promo module that could appear in a sidebar where you could have 4 of them. –  user2558 Mar 3 '11 at 23:14
    
That might be the case, but the ASP.NET design of Web Parts (ie: not just SharePoint) is that they are designed to be added multiple times, regardless if that is the intent or not. –  James Love Mar 3 '11 at 23:43
    
So how would you make a form accessible if you can't tie for/id attributes? What if you had to make a 508 compliant site? I'm no SP expert, but I thought 2010 was supposed to produce much more accessible code. –  user2558 Mar 4 '11 at 15:36
    
I've did a bit of digging in the SDK - you can tie the for/id attributes - but the id attributes (if using ASP.NET controls) will be generated dynamically at page render (using GUIDS) - you can get this ID property with the AssociatedControlID property of the control you want to tie in. So you would have do something like MyLabel.Attributes["for"] = MyRadioButton.AssociatedControltID. –  James Love Mar 4 '11 at 16:42
    
I might have mis-read the stuff I found (very quickly scanned before heading home from the office) and got something mixed up/wrong way round - but the AssociatedControlID is where you want to be looking I think. msdn.microsoft.com/en-us/library/… –  James Love Mar 4 '11 at 16:48

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.