Best way to present sub-options

[mbroglio]

I have a site I am trying to develop and am having trouble determining the best presentation for this situation.
There are a number of items I want to show, each with several, and the same, options:

Option 1 Option 2 Option 3
Item 1 x x x
Item 2 x x x
Item 3 x x x
Item 4 x x x

This layout would work fine, expect that for each item there are additional options available. I don't have enough width to show them all as above.
One solution is to put a labelled row in each item's row, but the presentation is not ideal:

Option 1 Option 2 Option 3
Item 1 x x x
Option A Option B Option C
x x x

Item 2 x x x
Option A Option B Option C
x x x

Item 3 x x x
Option A Option B Option C
x x x

Item 4 x x x
Option A Option B Option C
x x x

Nor is repeating the original option labels:
Option 1 Option 2 Option 3
Item 1 x x x
Option A Option B Option C
x x x

Item 2 Option 1 Option 2 Option 3
x x x
Option A Option B Option C
x x x

Item 3 Option 1 Option 2 Option 3
x x x
Option A Option B Option C
x x x

Item 4 Option 1 Option 2 Option 3
x x x
Option A Option B Option C
x x x

Any advice or examples would be greatly appreciated.
Thanks

[ralph.m]

Hi mbroglio. Welcome to SitePoint.

To be honest, I'm not really clear on what kind of info you are trying to present here, or what all those options represent. Could you perhaps post some example content, and maybe an image or two to make it clearer what you are trying to do?

[mbroglio]

Hi ralph,
Hopefully this will help clear things up a bit. The second row for each item is the set of sub-options I was referring to (width, dimen., position, etc).
How we have it now is with the headers for each set of main options (type, type, material, etc) listed with each item.
Sorry for the covered data, but I am not sure how much I can reveal at this point.
example.GIF

Thanks

[Stevie D]

This looks like it might work best as a complex table, with a liberal helping of <th>, scope and axis/headers.

The rows will be pretty straightforward - the left-hand cell will be something along the lines of:

<th rowspan="2" scope="rowgroup">

, which I hope is pretty self-explanatory.

For the column headings, I would create a dummy row in the <thead>. You can then use the axis attribute on the <th> header cells to match up with the headers attribute on the <td> cells below.

So within the <thead>, you might have:

<th axis="materials">

and then in the table body below, every cell that was in that position in the row-group would be given by

<td headers="materials">

(You can reference two or more axes by having a space-separated list in the headers="...">

Note ... this is (I think) the most semantically appropriate way of realising the structure you are asking for. However, as far as I am aware there are no mainstream browsers that actually use the axis/headers attributes in any way at all. I don't know if any assistive technology puts them to good use or not.

[Stomme poes]

Luckily browsers don't have to know jack about these attributes, so long as they pass them on to AT.

However, this is clearly a form. You get to use something called fieldsets, for example the dimension options you have on the far right look indeed to be a group of form controls who are of the same type. They get a fieldset, and this helps you figure out how you'd group things. This is one of those examples where a table *should* be inside a form. The issue here is, as far as screen readers go, the primary type of element here will be FORM, not TABLE. Headers and axis attributes and table stuff will not necessarily translate to a screen reader, so I think the best way forward is to think of this as a form that happens to have inputs with both a label and a group name (legend). Figure out what a good FORM would be first, then use a table to reflect that structure.
Will this form ever be presented to the user again, without form controls but instead with the options they have chosen? If so, then at that time you will use the same table structure as you had in the form, but now it would make sense to use stuff like headers and axis attributes, etc since it would only be a table.

You did mention some items don't have all the options other items might have. I think you might need to work from, what are the greatest possible number of options an item *could* have and work backwards. Items with fewer options will either have empty cells there or simply fewer rows, cols or th's.

I still don't have a good enough idea of what the different options are to suggest a good form (for example, I see two things called type... obviously they must be two different sorts of "type"), but I think this will mean the labels will have to be more descriptive instead of relying on column headers only. Especially since, it doesn't look like an item's first "type" box (a textarea?) has anything to do with the Width dimension, does it? So a column isn't appropriate here at all anyway.

Keep thinking on this. Ask yourself, what are these things? This will help you come up with appropriate legends (and legends should be short, sweet and to the point).

[Stomme poes]

Just free-thinkin here...

<h#>ITEM 1</h#> (some header, level depends on your page structure)
<form action="" method="post" id="formItemz">
  <fieldset>
  <legend>Types and material?</legend>
    <label for="type1">Type (some type) </label>
      <textarea id="type2" name="type2" rows="whatever" cols="whatever"></textarea>
    <label for="type2" aria-describedby="applyType">Type 2 </label><a href="someJS?" id="applyType">Apply to all</a>
      <select id="type2" name="type2">
         <options...>
      </select>
    <label for="material" aria-describedby="applyMat">Material </label><a href="someJS?" id="applyMat">Apply to all</a>
      <select id="material" name="material">
        <options...>
      </select>
    <fieldset class="checkboxes">(this is a subfieldset! Inside the main fieldset!)
    <legend>I'm guessing these last 4 are related?</legend>
      <maybe wrapping div?>
        <input type="checkbox" id="?" name="?" value="whatever"> 
          <label for="?"> Duplicate... describe</label>
      </maybe wrapping div>
      <maybe wrapping div>
        <input type="checkbox" id="?" name="?" value="whatever">
          <label for="?"> File</label>
       </maybe wrapping div>
       <maybe wrapping div>
         <input type="checkbox" id="?" name="?" value="whatever">
           <label for="?"> Duplicate again...</label>
       <maybe wrapping div> 
      </fieldset>
  </fieldset>
  
  <fieldset>
    <legend>Dimensions</legend>
     ...etc, dimensions...
  </fieldset>
</form>

You can see now that if you wanted this form to also be tabled layout, how a td would hold each label-input pair, and you'd add additional information as th's at least for the row headers. Again I am not familiar enough with the data to know if it makes sense to have column headers, since there doesn't seem to be column-like similarities.

Make a simple-as-possible intuitive form and users will just be happy. User testing whatever you come up with will show you where you forgot to make something obvious, because they'll all screw that part(s) up :)