Teh Formz, they are Teh Bloats! (label styling)

Not so, in my experience. Look again at my form demo in IE6. Clicking the label does move the focus to the associated input.

Now, as soon as I can get to it, I'll look at your form.

cheers,

gary

My bad, took another look-- that was when people were substituting the label-wrapping-input for the "for" attribute-- if the for is put back in IE6 is ok too.

You could tell them to get Firevox, for free. Don't we all wish we could dictate the client software?

Now for the question; does Jaws not make the connection to a nested input even with an explicit for/id combo? E.g.,

<label for="fname">
  <input type="text" name="fname" id="fname">
</label>

cheers,

gary

Yes it does, but we can't ever use a legitimate and extremely useful method of dealing with labels/inputs in wrapping the label around the input cos of one silly bit of software that can't handle things in that fashion, good this coding game isn't it?

JAWS has no problem with nested inputs... it's Window-Eyes who has the issue, and yeah, it's a bug, not a feature. I'm not sure why it still exists... I've seen both very old article sites and still new ones complaining about it. : (

JAWS is quite nice, though it's damn hard to learn (for me).

I actually don't mind the wrapping divs as much as the double labels. Every complicated form with nice styling I've found (even on a list of forms from Smashing magazine, who apparently posts stuff regardless of how good teh code actually is) has something wrapping, whether it's divs, p's, labels with the left-floated spans... always something to stop the inputs from riding up, or Jabba-da-script.

The doubled labels are not only teh ugliez but also screw with both popular screen readers in TWO different ways (and I consider BOTH to be bugz as the specs say an input may have multiple labels). And I'm doing it for styling, which is as bad as adding a for styling (I can accept using it in my forms, but I sure know that is NOT content, and is there purely for styling purposes).

"it's Window-Eyes who has the issue, and yeah, it's a bug, not a feature"

How would it have ever been a feature :? and at the vast cost of the software they damn well ought to produce a patch, it's simply ridiculous to think that we have to discard valid markup due to bad software.

Like text-shadow?

:last-child?

stuff...

I can has a list of things I'd use but don't because one or two popular browsers don't support : (

There is so much I'd like to use that I cannot-- now, some of you live in enlightened countries where for example IE use is low. I live in teh backwaters (Holland) where everyone uses Windows XP or nowadays Vista and everyone surfs with IE and builds sites for IE because that's what the Internet IS, it's Internet Exploder on Windows, the only OS that exists! My country is so teh Borat. : ( It's even behind the rest of Europe in regards to FF usage : (

OK. I recall you talking about some screen reader shortcomings, and mixed the bugs. :Oops:

Is it a deal breaker to ignore this bug, as being outside reasonable expectations of functionality? Kinda like trying to code a picture gallery for Lynx.

The purpose of nesting the control within the label is to tie the two structurally. If you need the structure, you must add otherwise unneeded markup to appease the one bug-besot application.

edit: Rats! You guys are posting too fast for me.

cheers,

gary

Not quite the same thing, that's styling, less relevant; markup, another kettle of fish.

If Holland is so backwards enlighten them poes start a campaign, although I find it hard to believe Holland is really that backward in these matters

And dammit, I could make a better choice if I had any stats on the blind in general in my country. I have zero and I still have colleagues elbowing me saying "look, the blind can insure their cars and motorcycles now! tee hee!" and I feel kinda stupid doing it.

I know in the Us JAWS and Window-Eyes are like 50-50 in usage. I have no clue about Holland. This country hardly has wheelchair ramps even, and until the gov't started mandating accessible sites for them, nobody made anything accessible except a few standardistas.

In any case, it wouldn't bother me so much if I didn't keep running into it on teh articles like Roger's. Now those comments may be coming from countries with higher Window-Eyes use, I dunno. I have a copy of JAWS but have never used Window-Eyes (and prolly won't test in something like FireVox simply because I'm testing the real screen readers and FirVox has no obligations to imitate anyone else's bugs or how to handle forms and tables and links the same way as a particular piece of commercial software).

Maybe it this is such a sticking point I'll wait on my forms until I can get s'more info on Window-Eyes.

*edit, Hugo:

It just lags behind more progressive countries as far as browser usage. The gov't recently set rules at least for their own web sites, which we cheered. And there is a group now, called Fronteers, which is basically front-end people trying to bring standards and accessibility to the Dutch web. I'm planning on going to the next monthly meeting but I dunno if I want to plunk down 100 euro before seeing what all they do with it : )

By our own company stats, we've got over 90% IE users. FF comes in second, and everyone else is below 1%.

Firevox is a screen reader in its own right. It uses existing/downloadable libraries from MSFT or from your Linux distro's repository. Linux, I don't know about MSFT, has an existing screen reader (which is about $1000 less expensive than Jaws) that Firevox uses and adapts for the browser.

See Fire Vox features.

cheers,

gary

U mean it's more than just a browser reader? That's pretty amazing.

I added a link to my previous post. You'll notice it runs on Windows, Linux and OS Ⅹ. Firevox itself is for Firefox, but the libraries read from all text in all windows on your desktop—at least in Debian Gnu/Linux. I thought it was pretty cool, but I can't listen that fast.

cheers,

gary

Yeah the reason I was staying away from browser-based screen readers was that they were web-only while real screen readers were super complicated simply because they read Everything! You can set real JAWS to start as soon as the Desktop loads (but I doesn't has teh real JAWS). Teh googles were going to make a web-based web-reading screen reader for folks who were using various public computers, but it's not done yet.
Second reason was, if FireVox does everything a screen reader would/could, but, for instance, reads things set to display: none, or reads implicit labels, that doesn't mean I can ignore what the standard commercial guys do.

Dammit, no. I tested much too fast : ( JAWS will read NORMAL implicit labels, but not with radios and checkboxes! GRRRR...

Unfortunately the thumb drive for JAWS is stuck on version 7 and the real JAWS is up to 9. Everything I can find on wcag is for WE5.x and they're up to I think 7 now. Then again, I dunno how fast people upgrade. If you buy the WE package thingie you get three major upgrades for free (cool).

So I will look further. I've already run across something about using title att's for the inputs which I might have to do for all those places I have a p, which as I said, will get read if you're just surfing along but not in Forms mode (form controls only).
Also ran across another interesting thing-- WE (at least the older ones) don't read the asterisk we use to set stuff to "required" unless the user changes a setting (unlikely according to wcag). Sheesh. But you can write "required" in the input's title, so I'm prolly going to start doing that whenever I make a form with mandatory fields (I haven't yet-- all my forms so far have all forms as mandatory).

Man, I'm surprised there aren't blind users selling their services as web testers due to their proficiency with the software... all the testers that I find on teh interwebs are sighted developers. And we suck at using screen readers (maybe if I seclude myself for 3 months in a closet and practice... but I can't even touch-type!). Plus, my JAWS reads Engrish. There's a Finnish and a Spanish but no Dutch. Sounds pretty weird but that's ok cause I can still tell what it's reading.

And yeah, you can slow JAWS down or speed it up so I'd be wery surprised if you couldn't also do that with FV-- the "normal" speed is damn fast, though. I can't listen fast enough. Mah earz, they are teh SLOWz!

Yeah, I know you can slow it down. I haven't because 1) I haven't had/made the time to work with it and get it configured 'properly', and 2) I have keyboard shortcut conflicts that again, I haven't had/made the time to work with it and get it configured 'properly'.

Does that apply to nested radio/check boxes that are explicitly linked?

Could you possibly translate your sample form for us uneducated mono-linguists? I'd like to get a sense of the labels, especially the double labels.

cheers,

gary

Oh, I could prolly just make that form Engrish... but this is an insurance form (or, a loose piece of one) with questions like "do you give us the right to automatically electronically deduct your premium?" or "do you have the right to claim (this other tarief you can get if you have at least 10 damage-free cardriving years)?" And they get kinda long... lemme change it though.

Okay, I've rewritten my forms a bit and made three of them.

http://stommepoes.nl/Forms/nonwrappinglabels.html is the default. I've changed most of the label text to English and also the help text of the last question. The labels do not wrap the inputs.

http://stommepoes.nl/Forms/wrappinglabels.html is labels wrapping inputs but still explicitly linking to the inputs with the "for" attribute.

http://stommepoes.nl/Forms/wrappinglabelsimplicit.html is labels wrapping input without explicit linking to inputs.

I changed the names of the Yes and No checkboxes because it turns out they were going too fast for me to catch and JAWS pronounces "Ja" like a a little sound, not Ja. It knew the page was in Dutch but I don't have that option with the thumb drive.

In all three pages, in just plain old Say-All mode, all the labels were spoken and actually so were the values at least in the select dropdowns though it was very hard to hear.

In nonwrappinglabels and wrappinglabels (explicit) the checkbox area was read out as so (and I'm getting a different result than normal because I have the question as the legend because I'm wrapping the checks and radios in a fieldset to stop the labels from floating left... normally, people use a P. A

or any non-form control will be read in SayAll, but not in Forms Mode (which is what you're in if you want to actually Fill Out the Form!). I think I'll avoid P's in my forms then, except for visual form invullers.

*space*

This is actually for all three pages, though it likes to say the last checkbox label and then directly to the next legend/question without pause in wrappinglabelsimplicit.

But with radios it's bad.

First two pages are fine:

(not sure about the one of one thing)
*down arrow*

Always states the checkboxes as checked thereafter, always rereads the legend but that's normal, it'll always reread the legend except when it leaves the nested fieldset (it starts out speaking the whole legend of the main form until it gets to a nested fieldset.

The wrappinglabelsimplicit.html has trouble at the radio buttons.

*down arrow*

No matter what, I can toggle between Yes and No and always get told Yes. I might try a more-than-two list and see if it's always the first label who's listed (all my other forms I was testing on, the finished bloataceous forms, are always always explicitly linked).

While the bulk of the form doesn't look tooooo bad in modern browsers without div wrappers etc, it's total *beep*e in IE6 : (

JAWS read the legends for everyone inside that nested fieldset, and then speaks no legends until it end the form or gets to the next nested fieldset. The re-reading of the legend is annoying and people can turn this off, which is bad if I'm using the legend as a "header" label text. Also, some of the questions are longer than the width of the form, notice, and this is bad because many browsers including I remember FF1.5 would just let the legend go offscreen or get cut off if the form is overflow: hidden. Other browsers wrap the legend. So, I'm limited in what I can use it for.