submitted for your approval, the attached, also perusable at:
http://www.hicom.net/~oedipus/wai/references/qtform.html

the reformatted form validates against the W3C HTML Validator 
and the CSS Validator

i think that the overall flow of the form is improved by a 
slight shifting of explanatory materials, and, of course, 
benefits enormously from the addition of LABELs, ACCESSKEYs, 
and the like...

not too much of a departure from what you originally outlined, 
daniel, but i find the attached much easier to use in an 
environment that supports 

i commented as i went along, and the following change/issue log 
was copied and pasted from the inline comments that are still 
extant in the attached document source

1. added LANG attribute to HTML declaration

2. added the following to the STYLE rules defined for the document:

  BODY
  .skip { margin-left:2.5%; margin-right:2.5%; font-weight:bold; font-size:90%; }
  .invisible { display : none; }
  .explanation { margin-left:5%; margin-right:5%; }

  fieldset { padding : .25%; }
  .input-grouping { margin-left : 2.5%; margin-right : 2.5%; }

  dt.list-header { font-weight:bold;font-size:110%; }

3. added an additional META tags (description, as follows:

<meta name="description" content="Use this form to order Web Accessibility 
QuickTip cards. Quantities of up to 500 cards are available from the World 
Wide Web Consortium's Web Accessibility Initiative at no charge.">

4. added MAP containing 2 links: one which allows you to skip directly to 
the form (bypass front matter) and one that leads to the list of ACCESSKEYs
defined for the form

5. while i have chosen to replace the asterisk, which is used as token 
denoting a required field, with an explicit text string indicating that 
the field is required, i could retain the token (which would be rendered) 
and span the explicit text with a display:none style rule as i did to add 
extended semantic information to the LABELs i associated with the Quantity 
radio buttons, namely that the numbers mean number of cards -- for example:

<input type="radio" name="quantity" checked="checked" value="10" id="f10a" accesskey="q"> 
<label for="f10a">10 <span class="invisible">cards</span></label>

6. added TITLEs to all HRs

7. added LABELs and ACCESSKEYs to form controls

8. mnved P from outside first FIELDSET to inside the FIELDSET and used 
stylesheets to control format

9. Question: since it isn't legal to append an ACCESSKEY to a FIELDSET, 
should i have appended the ACCESSKEY to the LEGEND rather than the first 
input field contained in the FIELDSET?  philosophically, i'd prefer 
appending the ACCESSKEY to the FIELDSET (ok, LEGEND), since the FIELDSET 
contains linked/related input fields which are grouped under the LEGEND 
'Address'; however, i think it more practical to appending the ACCESSKEY 
to the first input field, as (a) that's where the FIELDSET actually 
starts and (b) those UAs which support ACCESSKEY do so more 
uniformly/consistently when the ACCESSKEY is associated with an 
interactive element, rather than an anchor/non-interactive element

10. Implementation Bummer: no screen reader that i am aware of properly 
processes FIELDSETs, that is, provide the user with the option to 
configure the screen reader so that, when it is in a FIELDSET, it reads 
the FIELDSET's LEGEND before reading the label associated with a form 
control, so as to provide context for the form elements contained in 
the FIELDSET (as well as cognizance of the existence of FIELDSETs as 
logical groupings

11. had to append the ACCESSKEY to the LABEL i defined for the 2 form 
fields that are SELECT OPTION fields, as the Geraldizer (a.k.a. the W3C
Validator) barked at me when i attempted to append it to the SELECT 
element, as well, i suppose it should, as the SELECT element isn't listed 
in the HTML4 spec as one of the elements for which ACCESSKEY is a valid 
attribute, but i wonder why...

12. again, upon encountering the second FIELDSET, i have the same 
philosophical quandry: should the ACCESSKEY for this FIELDSET be 
appended to the FIELDSET element or to the first interactive element in 
the FIELDSET?  for consistency's sake, i i have appended the ACCESSKEY to 
the radio button marked as the default

13. UA Implementation Bug Warning: since IE5/IE 5.5 use ALT+D as an 
accellerator that allows one to jump to the 'Address' bar, some IE5 users 
may end up in the 'Address' bar when they attempt to trigger the ACCESSKEY 
defined for 'Deadline'; although 3 out 5 tests led to the input field for 
which 'd' was defined as an ACCESSKEY and only twice was the input routed 
to the 'Adress' bar; i'm inclined to leave the ACCESSKEY defined for the 
'Deadline' field as 'd', as the conflict is the result of a UA 
implementation bug

14. removed 2 BRs and enclosed the Submit mechanism and explanatory text 
in a P container

15. Question: by moving the explanation of what happens when the 'Submit' 
button is activated, am i justified in replacing the verbiage (or at least 
preceding it) with a 'Reset' button

16. Question: should the list of ACCESSKEYs defined for the form be listed 
in the physical/structural/logical order in which they are encoded, or 
should they be listed alphabetically?  i have chosen the latter, as is my 
personal wont

17. ENDMATTER: added HREFLANG attribute to INRIA and Keio links, and provided 
an expansion for INRIA, and, by appending the LANG attribute to the ACRONYM 
element, i was also able to demarcate the text as french; also provided 
expansions for W3C and MIT, and replaced extended ASCII?/ANSI character for 
copyright with corresponding character entity