Discuss: Prettier Accessible Forms
by Nick Rigby
- Editorial Comments
22 Re: Prettier Accessible Forms
Just scanned the article, and jumped over recent comments:
- Using lists for input elements is at least “questionable”. And in this case, you could achieve almost the same with “label” elements.
- Emphasizing asterisks is not really appropriate. Additional text would be more helpful, I fear.
- Use other filters/workarounds/hacks for your CSS (WTH is going on in the “form.cmxform legend” rule, accidentally put a “strong” element in there?), and ignore Mac IE.
posted at 01:09 pm on June 20, 2006 by Jens Meiert
23
Jens, I’m afraid that your scan missed the article’s actual points. In any case:
WTH is going on in the “form.cmxform legend� rule, accidentally put a “strong� element in there?
Our fault, not Nick’s. It’s fixed now.
posted at 01:20 pm on June 20, 2006 by Erin Kissane
24 Untitled
I think this is a nice flexible approach to working with forms, but I don’t think it’s the most portable, nor do I think it’s the most efficient. I agree with the sentiment of many of the other comments about using javascript to add style.
I’ve written about forms myself lately and while I don’t claim to have all the answers (and I’m certainly not as succinct), I’m using an accessible and XHTML strict method to achieve a similar result
I do like the idea of the ordered list for the purpose of screen readers, however. That’s something I’m very eager to experiment with.
Thank you for the article, I found parts of it thought provoking, even if I don’t agree with every point that it makes.
posted at 01:30 pm on June 20, 2006 by John Pennypacker
25 Re: Untitled
Rene: I’d hazard to guess that this is caused by the use of addEventListener (which does not run only on Mozilla, as the author points out). The reason it only worked in Mozilla for the author is because the DOMContentLoaded event was originally a Mozilla specific event, but is now in Opera 9 (which is now out of beta). The DOMContentLoaded event was only added recently, so it is not in all of the beta copies of Opera 9.
posted at 02:26 pm on June 20, 2006 by Brian LePore
26
There is a problem with Opera 9 outputting “null” before the labels, which is a result of the JavaScript running.
It’s no problem that the JavaScript runs for Opera, and it can easily be fixed by changing this line in the [removed]
this[removed] = null;
to:
this[removed] = “”;
I will hopefully get this changed updated in the article and example files.
Thanks for pointing it out.
posted at 03:18 pm on June 20, 2006 by Nick Rigby
27 forms and tables
I have an issue with the lead-in to this article… The client-side development/design team at the agency where I work has decided, as a group, that since forms output tabular data, it is permissible to use tables to display forms.
Is using bulleted lists to display forms really more semantically correct?
posted at 03:34 pm on June 20, 2006 by Andrew Ortolano
28 Definition Lists?
I’ve been using definition lists for essentially the same thing using the argument that semantically, it just makes sense.
<fieldset>
<legend>Delivery Details</legend>
<dl>
<dt><label for=“name”>Name[em]*[/em]</label></dt>
<dd><input id=“name” /></dd>
…
<dt>Is this address also your invoice address?[em]*[/em]</dt>
<dd>
<label><input type=“radio” name=“invoice-address” /> Yes</label>
<label><input type=“radio” ame=“invoice-address” /> No</label>
</dd>
</dl>
</fieldset>
That way, you wouldn’t end up with a wrapped fieldset at the end. This is, of course, assuming that you agree that the input labels define their input fields. If you don’t, why not?
posted at 03:38 pm on June 20, 2006 by Jonathan Hohle
29 Using tables
The client-side development/design team at the agency where I work has decided, as a group, that since forms output tabular data, it is permissible to use tables to display forms.
Not at all. You might as well say that since your computer sits on a table, it’s OK to use tables for anything that you run on your computer…
Forms don’t output tabular data – what they return is far more aligned to a <dl> definintion list. The fact that it can be exported into a table if that’s how you choose to run it is neither here nor there.
Having said that, I don’t have a problem with using tables to get the form to appear as intended – as long as it linearises properly to give the same output as you or I might see on the screen. No, it’s not ideal – but at the same time, it isn’t the worst sin in the world of web design.
posted at 04:02 pm on June 20, 2006 by Stephen Down
30 It is a table
I was very impressed with the technique, at least until I got to the part where you include a fairly large library of javascript in order to hide the fact that you require a non-semantic element for Mozilla based browsers.
But it seems like you are really going out of your way to avoid the use of tables, and ending up with something that is almost as much markup (it would be about the same number of tags, if you weren’t hiding the divs with JS), and much more JS. But when you get down to it, it is in fact tabular data. You have multiple rows, and two columns. The first column, like many tables, is used to identify the data in the remaining columns. The columns and rows form a grid that allow you to associate the items in the columns with the items in the rows.
The fact that it has the minimum number of columns to qualify as a table does not make it any less of a table, you have just used different mark-up, along with tricky CSS and JS to recreate a table. One could easily imagine more columns, such as a column of check marks to indicate required fields, or a column of hints for each row of what is allowable data for each row.
posted at 04:17 pm on June 20, 2006 by Brad Kemper
Discussion Closed
New comments are not being accepted, but you are welcome to explore what people said before we closed the door.
Got something to say?
Discuss this article. We reserve the right to delete flames, trolls, and wood nymphs.
Create a new account or sign in below if you’d like to leave a comment.
Subscribe to this article's comments: RSS (what’s this?)



21 Mandatory fields
Because it generally doesn’t look as good to have “(mandatory)” written out in full next to every field – a coloured asterisk is unobtrusive yet clearly visible. If the asterisk is applied to the label, and is explained at the start of the form, there should be no accessibility or usability issues.
In general, I prefer to avoid the use of mandatory/optional fields, and only ask for the information that I really do need!
posted at 12:57 pm on June 20, 2006 by Stephen Down