Stylizing a stubborn form

HTML & CSS
1

I have been messing around with trying to add some simple design to a search form, and it is giving me a huge headache … I’m always ‘almost’ get it right, but its not ‘almost’ enough. I even managed to get it right in Firefox, but in Chrome and Safari its completely different. AGH! Here is the basic html:


<div id="searchbar">
            <form method="post" action="/cgi-bin/showsearch.cgi">
             
                        <input type="text" size="30" name="bustype" value="Business Name">
                        <input type="text" size="30" name="buslocation" value="Location (City/State)">
                       
                        <!-- submit button -->
                        <!--<input class="submitbutton" type="image" src="images/btn_search.png" name="submit">-->
                        <input class="submitbutton" type="submit" name="submit" value="">
                     
            </form>
            
        </div><!--searchbar-->

And the CSS is as follows:

#searchbar {
	padding-top: 10px;
	padding-left: 50px;
	
}

#searchbar form {
	margin: auto 0;
	background: url(images/bg_search.png) repeat-x;
	padding: 5px;
	display: inline;
}

#searchbar form input {
	display: inline;
	font-family: "Century Gothic", Arial, sans-serif;
	color: #999;
	margin-right: 20px;
	
}

#searchbar form input.submitbutton {
	padding: 0px;
	background: url(images/btn_search.png);
	height: 44px;
	width: 72px;
	border: none;
}

The problem that I am having is the submit button does not center with the two form boxes. I have added the button in the CSS ‘and’ the HTML, and both times it is always about 10px higher or lower (depending where I put it). I’ve played with the display, and nothing. What it currently shows it looks perfectly how I want it in Firefox, but in Chrome and Safari, it sent the entire form up and the “button” down, and is all wacky macky. I imagine that its just as wacked in IE, too …

Any help would be very appreciated. I’ve gotten tunnel vision, I think …

Thanks :slight_smile:

2

Another reason I don’t like to set the value in the HTML is that I usually make the inputs “sticky”, so that if the user makes a mistake, the information that’s been typed is still there. (This applies to things like contact forms, of course.)

Not sure what you mean by this. If you’re talking about, on page refresh, that depends on the browser.

Try it: set a select dropdown to something other than the default, in a few browsers, and refresh. Some will keep what you’ve chosen; some will reset to the default value. For inputs type=“text”, if there is no default value, they’ll default to empty string. If there’s a hard-coded value, they’ll default to that value. Which, if there are no labels anyway, maybe you’d rather lose the info you’ve typed instead of trying to guess what you were supposed to fill in that field anyway… ah yeah, another disadvantage of no labels. For checkboxes/radio buttons, so far all my browsers will leave them all unchecked if nobody has checked or selected, but the specs warn that user agents may (apparently randomly) choose one radio out of a set to be selected by default (I guess in keeping with the concept of a car radio button lawlz).

If you mean when the user gets response from the server with error messages, sessions ftw.

Yes, the “star star star star” thing is pretty funny to listen to, but I guess there’s no real alternative, given that you don’t want sensitive info read aloud.

At least I still get feedback that I had hit the key hard enough : ) This happens with my phone when I have to type in the PIN as well… which is nice because sometimes the first time I hit the button I get no reaction.

3

You could try adding this:

input {vertical-align: middle;}

Given the code you supplied, that seems to do the trick. :slight_smile:

4

Lol … what the heck! How did I never notice that before in all the years I have been doing CSS …

You are a life saver. I almost threw my laptop … almost…

THANK YOU!!! :slight_smile:

5

You’re welcome! I’m glad your laptop got a reprieve. vertical-align is really handy on inline elements, so it’s handy one to keep up the sleeve. :slight_smile:

EDIT: I guess I should have mentioned that it would be good to have some labels associated with those text inputs. Not sure what you are planning there, though.

6

I will never forget it now, that’s for sure. Thanks again.

Also, and this may make me sound like a derpa der, but what do you mean labels? Beyond value and names for them?

7

Yes, sorry, I forgot that you used values inside the inputs, but this can be a bit clunky for people, as they have to wipe away the default text (unless you use JavaScript). Also, those using screen readers may have trouble knowing what they are dealing with, which is why it’s good to have labels associated with each form input:

<form method="post" action="/cgi-bin/showsearch.cgi">
    		<label [COLOR="Red"]for="bustype"[/COLOR]>Business Type</label><input type="text" [COLOR="Red"]id="bustype"[/COLOR] size="30" name="bustype">
         	<label [COLOR="Blue"]for="busloc"[/COLOR]>Business Location</label><input type="text" [COLOR="Blue"]id="busloc"[/COLOR] size="30" name="buslocation" value="">
        	<input class="submitbutton" type="submit" name="submit" value="Submit">
</form>

If you don’t think the labels are needed by sighted users, you could hide them via CSS, but I still think it’s generally better to have them for everyone anyhow.

8

Ah! Yes, huge derpa der moment.

Thank you for mentioning that. You make a great point about users with screen readers … I will have to work it into the design.

Much appreciated :slight_smile:

9

I’m not very experienced with screen readers, but have been tinkering with the free one that comes with Macs, called VoiceOver. It did read out the value information in your original code, but it wasn’t really clear what to do with that information, so a label definitely makes it clearer. Not sure what other screen readers, such as Jaws, would do.

EDIT: actually, not true. I tried VoiceOver again, and it read out the value text and highlighted the text, with the option to “edit text”. So in a way, it’s a cleaner option. I will have to ask Stomme poes for an opinion on this, as she’s very up on these issues.

10

I appreciate you looking into it. I was just playing with the design, and I am torn between my original design and with the label, so if it will still work well with the voice over, I’d like the way it looks better without it.

I’d love to hear her ideas on it though! Thanks again :slight_smile:

11

Thanks for the heads-up, Ralph.

JAWS and NVDA will read out the values fine, and like VoiceOver they’ll offer you to edit-type-in-text. I’d call myself an Orca beginner: while when there are no labels and just values, I hear the values first and then “text” (Orca tells you what kind of input box it is when you focus on it) so I could start typing fine, but I didn’t realise the old value stuff was still in there. Maybe a more regular Orca user would know (since when there is a label and no value things are read out slightly differently). So in my Change Password form, I could have potentially entered something like

lk872hfk4Old Password
aw3s0m3p455w0rdNew Password
aw3s0mep455w0rdNew Password (again)

and then I suppose I’d get an error saying that wasn’t my old password, and my new passwords don’t match.
Besides, any input type=passwords can’t use values at all: every screen reader I’ve ever used reads out “star” or “asterisk”, so I guess you’d be asking people to guess that the “star star star star star star star star star star star” input must be asking for a password… or not use that input type (it has been argued they are not great for usability, tho without that input type, if you’re not using headphones everyone can hear your password lawlz).

Checkboxes and radio buttons shouldn’t rely on values… should have labels.

Now if I bothered to go back and read the inputs, sure, I’d notice right away there was text in there. But why should I have to? There’s a reason readers read back what you type to you.

As a non-JS user, I don’t care to have to remove redundant values for everything I type in… but that is better than having no labels, and then using Javascript to both create and remove the text, since then I get a bunch of input boxes with no indication what the hell they’re about (strangely this is popular on quite a few fancy web developer blogs for some reason) so if you’re adamant about no labels then I guess I’d rather have the values in the source code. Though I’m a code-nazi and I only allow forms with no labels in very special circumstances… and “the designer thought it would look hip” doesn’t count.

Be aware that any reset button resets the value of the inputs that’s in the HTML, not blank. Which in this case would be your values. If your back-ender cares.

Title is often an option if you’re ONLY thinking about screen readers, but without anything else that’s super-obviously a label for everyone else, I wouldn’t use it (no mouse, no title; not accessible).

12

Thanks for your input, Stomme. Always good to hear from you. Another reason I don’t like to set the value in the HTML is that I usually make the inputs “sticky”, so that if the user makes a mistake, the information that’s been typed is still there. (This applies to things like contact forms, of course.)

Yes, the “star star star star” thing is pretty funny to listen to, but I guess there’s no real alternative, given that you don’t want sensitive info read aloud.

13

Neither page refresh nor sessions, but say a user fills in a form then submits it, a new page is served up, either saying “Well done” (or whatever) or saying “you made a mistake”, listing the mistakes, presenting the form again with the data still in place, and perhaps the labels of the problem inputs highlighted in some way. I haven’t mastered this in accessibility terms, and haven’t gotten my head around warning users before they submit the form in the first place (Ajaxy sort of stuff), but that has problems for those with screen readers anyhow.

A form that re-appears with the values still in place after submission is often called “sticky”. It’s done by putting little bits of PHP inside the values (or in other places for different input types) that echo out the user inputs.

14

Neither page refresh nor sessions, but say a user fills in a form then submits it, a new page is served up, either saying “Well done” (or whatever) or saying “you made a mistake”, listing the mistakes, presenting the form again with the data still in place, and perhaps the labels of the problem inputs highlighted in some way.

Then you’re relying on browser caching (browsers may cache the values that were filled in) which CAN be off! (unless you’re talking about some special php thingiemagjiggy… I dunno php stuff) The form should send the info, the back end should store them temporarily, and then re-feed those values back to the “you suck, learn to fill out forms” page with the correct error messages. Also, this lets you control the values who should NOT be echoed back, such as passwords, credit card numbers etc. Those should be returned blank and users should be alerted to fill them in again (pain in the butt but more secure) along with whichever fields were wrong in the first place (I hate when they do that and I just fix the bad ones but then get told I “forgot” to fill in password/banknumber etc… I didn’t realise they’d been blanked).

I would not rely on having value=“” for that. (Though I do add in value=“” for my back-ender cause he really likes that for some reason… maybe something to do with how he’s set up the forms, I dunno).

15

Yes, sorry about that, I edited my post to clarify that over the top of you. I’m talking simple PHP here.

I hate when they do that and I just fix the bad ones but then get told I “forgot” to fill in password/banknumber etc… I didn’t realise they’d been blanked).

Yeah, that gets me often. It’s important to make fields like that really stand out so that it’s obvious they need to be filled in again. And they’ve got to stand out for screen readers too.

I would not rely on having value=“” for that. (Though I do add in value=“” for my back-ender cause he really likes that for some reason… maybe something to do with how he’s set up the forms, I dunno).

Yeah, the value attribute is the normal means for sticking info back in with sticky forms (at least with PHP, or the nooby limits that I’ve reached with it).

16

And they’ve got to stand out for screen readers too.

Safest might be just to put them in the error list.

17

Good point; and maybe title it “Things to address” or something similar, rather than “Errors”.

18

Goodness! I missed a lot while I was sleeping! lol

The actual point of the form is a search feature, where they can search the business name, and specifically search in a location too. It could be a huge problem if they forget what the two boxes are for once they already typed something in and deleted it for some purpose or other. Whether they use a screen reader or not.

Thanks for the extra perspective. Seems I was having tunnel vision in more ways than one. :slight_smile: Much appreciated!