csd 3: accessible forms

a little more awake post-lunch. Andrew from Indiana U is a library guy!

had a quick chat with the woman from the W3C. (cool tiny laptop.) she encouraged me to complain to MS about the FP/Word thing.


hey, he’s using S5 too!

why accessibility…if I were him, I’d just refer back to the keynote, since she covered all that stuff. damn, why do these presenters always spend so much time on the introductory stuff?

table-based layout for forms: can be problematic linearizing. a code example would be useful here. css layout is better; why? because closer. place text/labels to the left of controls. (I thought that radios & checkboxes should have labels to the right?)

not as hard as you think (css layout) — but no resources for how to make it less hard. that’s the overall problem with css advocacy in general, and I’m as guilty of that as anyone. it is hard once you get into it.

(if I were doing this presentation, I’d do 2-5 examples, making inaccessible forms accessible. oh, wait, it looks like that’s what he’s getting ready to do.)

3 examples of the same form layout: one with inaccessible tables, one with accessible tables, and the third with spans.

labels, increasing clickability, Fitt’s law. another example.

and then he shows a form with the radio buttons: yeah, the labels are on the right here. and then another example using the label tag. interesting: he changes the pointer for hovering on the labels. which browsers does that work on?

alternate text on image buttons (not that I ever do that).

on error messages, don’t just use color (same deal with required fields, I would assume) — but color can be useful, too. change field color on focus. (our directory does that.) interesting in that usable/accessible forms can include enhancements: the general concept of progressive enhancement.

more tags! fieldset, legend, optgroup. “most modern support” — I think they all do, it’s just a question of whether you can restyle them. nested fieldsets. question about optgroup and screenreaders: he doesn’t know, no regular access to screenreader. complains about pricing of Jaws.

the keynote speaker talked about what they can do, apparently there’s an email forum thread on the topic.

make sure forms function w/out JavaScript. as with color, some good things you can do and some things are just evil.

he like the cursor being focused via js; I *hate* that, because I use the backspace so much for navigation.

question: do these techniques validate? yes, and they’re what you’re supposed to be doing.

question: dropdown example to not use, what would you do instead? wouldn’t do it anyway, but if he did, would use a real form, cgi & button. more general question about dropdowns (list of states), ’cause it’s not navigation, it’s not necessarily evil, this is an issue with scripting, not the actual tag. (on the other hand, it’s not that hard to validate a 2-item text box.)

quick discussion of tab order. only need to set if your “natural” tab order doesn’t make sense. (I think it’s easier just to make sure your tab order is logical naturally.)

and then accesskeys. oy, they are just a nightmare, is what I remember. (we used to use them and I’ve given up on them.) and he brings that up: the conflicts between the builtin programmatic keys and accesskeys. “in theory, communism works” essentially.

favorite form pages? see links on the page that goes with his presentation.

question from keynote speaker: can you tell what is required and what is optional? he rambles, but basically mentions all the HTML stuff as more important, other stuff is just nifty.