So we use CSS to style elements and keep semantic separate from aesthetics. and CSS is great and getting better at allowing almost any layout option regardless of the mark up so it’s hard for me to find excuses to use mark up for … well … layout.
The question is this say you sad quiz in the form (pun) of a form ( or anything like this the example is fictional). so each question is a fieldset with the question text. That simple enough and each answer option is a… hmmm? Well a radio button and a label seem like a good idea; it cuts down codeand is totally semantic. One could even place the input inside the label tag.
<fieldset>
<legend>So this could be the question here. It could be long or short or it could just be a header for multiple questions coded as follows.<legend>
<label><input type='radio' name='answer'>an answer option and its corresponding button. I dont even need an ID if its wrppped this way and it seems perfectly semantic and streamlined</label>
<label><input type='radio' name='answer'>another answer</label>
<label><input type='radio' name='answer'>another answer</label>
<label><input type='radio' name='answer'>another answer</label>
<label><input type='radio' name='answer'>another answer</label>
</fieldset>
Again with a little CSS one can layout this in to to a nice looking easily readable AND ACCESSIBLE FORM. But what if CSS is OFF? Then you have a long line of text punctuated by radio buttons. That is perfectly accessible, but a pain to read and use. We can solve this by placing BRs between each label or wrapping each label in a block level tag. But in each case we are adding extra mark up and purely for presentational reasons. Damned if I do damned if I don’t.
So I was wondering what the forum expert consider the right approach to this kind of conundrum?
I’d do the <br> approach, purely because if CSS is off, then at least I have a fallback. So what if it’s extra markup? We add markup all the time for text/image replacement techniques where we use a <span> normally.
It may bloat the HTML with “unneeded” code, although it would essentially cover the CSS off option.
Like Ryan, I’d use BR. What good does it do to have less markup at the cost of readability? The BR tag is for breaks and a perfectly valid way of separating form elements.
That defeats the purpose of having it there though. If you’re going to have it, why bother removing it just so you can accomplish the same effect another way? You’re just creating work for yourself ;).
You missed my point. Raptor tried explaining. If you have <br> there and leave it like that (no effort at all) and just keep everything the same (because it shows how you want it to), why would you add extra work to display:none the BR and get the same effect the <br> gave you, with an alternative way with CSS, when you COULD just leave everything alone!
The OP asked what we would do if we had the two options. Both kohoutek and myself picked the <br> flat out and no CSS added, since it does the same job and is less code to deal with. Perhaps you wanted to do the CSS approach instead, which is fine. I don’t judge that much :).
D_P also talked about keeping the aesthetics apart from the semantics. I was just looking for a way to do just that while still having a fallback if CSS wasn’t working or was turned off.
Yes. taht was my original concerned. Though , after reading how this thread has progress I think therer e comes a time when you can be TOO hard core for your own good. Along with the separation of style and content… accessibility is an issue. Face it, when CSS IS OFF:
my old fallback , btw… would have been to WRAP a block level element such as a DIV around each element. But reconsidering what has been said I think I will star to implement BRs ( in MOST cases… you can never say ALL in web design) because of the following reasoning:
accomplishes line breaks when CSS is off
does not ACTUALLY alter the semantics ( using any block element but a DIV would)
Eliminates/simplifies the need for CSS styling for dropping each element to its own line
it’s “reversible”… if you want to still stile each element as if the BR wasn’t there BR { display:none ; } applied
Yeah Am still entertaining arguments to the contrary… but so bar the BR seems to be in the lead.
I’d also use BR, but that’s because I prefer label and input to be siblings to each-other. That way I can set the label to inline-block, fix it’s width, and then I don’t have to mess with floats to get them to all line-up properly.
Be careful wrapping inputs in labels. Some AT and some browsers seem to sometimes have bugs when doing this, even though it’s perfectly legal HTML. In accessibility circles the wrapping with label isn’t recommended because of this. AT tends to lag browsers in terms of software updates.
Jim Thatcher of IBM has consistently recommended keeping the label and input tags separate. Window-Eyes had a bug where the input didn’t seem to exist. Some versions of OSX seemed to not allow Safari users to click on the inputs… but this was a very intermittant and so hard to find the cause. There may be other AT with issues as well. It was also asked in the a11y community about “anything wrong with the redundancy of for-id and wrapping” and the replies were “if you do that be prepared to do way more testing, so don’t.”
That said, I’ve still done it on occasion but I try not to. I also use BR to stop inline labels and inline inputs from running into each other. One of Jakob Nielsen’s big usability no-no’s was when you have an inline row of radio buttons or check boxes where it’s difficult to see which input belongs to which label. You would think wrapping the input in the label would help this, and I’ve done that too (and used background colours and outlines and extra margins on the label to help with this) but nowadays I tend to either margin the hell out of the labels or sometimes use an inline wrapper (like a span) for styling, and if no-CSS is an issue then br’s with “display: none” as mentioned above do the trick nicely.
