We tried this very solution two years ago, but it failed user testing with people with disabilities. Although it looks nice, we had the choice between making an alternative accessible version, or to simplify the form layout and remove the tabular-type layout. We chose not to use the tabular type layout, but broke each “row” into a separate fieldset with visible labels – and thankfully, that worked out really well.

The structure of this particular form is tabular, so using a table for laying it out is semantically and structurally correct. Yes, the tabular structure is ignored by JAWS in forms mode, but that’s no reason to remove structurally correct markup. The nested fieldsets are a useful alternative, but then you lose the two dimensional cellular structure for a two level hierarchical structure. Compounding that with hiding labels, and your nested fieldset emulation loses information that some groups of disabled people need.

The main audience this solution creates barriers for are disabled people using screen magnifiers – for them it is important that every field is properly visually labelled (the same rationale for people with cognitive difficulties). Take for instance the form element in the bottom right hand corner (as a worse case scenario) – in a screen magnifier focused on this field, they’d be very fortunate if the “column heading” of “Played” (three lines higher up) is visible in the magnification area, but the “row header” Game points most certainly won’t be visible. (Incidentally, that’s why having the form label immediately above textfields, text areas and selects is the more accessible approach – it is far more likely for both elements to be visible at the same time in a screen magnifier region).

Now if it were marked up as a table, there could have been a fallback way of giving people using screen magnifiers an online highlight/announcement of the row and column headings (like a browser extension like Gez Lemon’s excellent Table Inspector: http://juicystudio.com/article/firefox-table-inspector.php ). Or if the labels were visible adjacent to their respective form fields…

Although the resulting barrier isn’t an impossible one, it is still a barrier that’s difficult for certain groups of disabled people to cope with. The main suggestion is to remove the table-emulation styles (of hiding labels offscreen), and use the fieldset and label structure to visually emphasise the relationships in the form elements, and not to position them offscreen – so back to http://24ways.org/examples/showing-good-form/article-example3.gif – that is the most accessible of the form layouts on this page (when its styled with only one text field per line). The CSS that follows creates accessibility barriers – by hiding information that’s necessary for screen magnifier users and people with cognitive disabilities.

As a few people have mentioned above – clearly this is semantically tabular data.

If a particular user-agent (with an absolute minority market share at that) doesn’t provide adequate support for rendering the semantically correct implementation for this situation, does it mean you should hack your way around it?

A great article!
It’s an interface I’ve often come across and I too have been pondering about what markup to use in this situation. Thanks for providing this solution :)

One thing though, how do screen readers behave when input fields are nested within their labels? It looks weird to me to nest those elements..

Seeing as Safari accounts for about 4-5% browser share I don’t think it’s acceptable to concede “It also doesn’t look quite right in Safari” for the sake of doing it the technically correct way. There are so many versions of the tableless form layout out there now, but none of them are robust enough for real world use.

I’m impressed with the final outcome considering the form code you had to start with.

My interest is more in why a table layout isn’t appropriate here. It seems like it isn’t simply because the ‘forms mode’ of JAWS makes the form unusable. Whereas, semantically speaking, it would seem like a table is actually the most appropriate for the content. Anyways, I don’t intend to completely derail this conversation into a mere semantics debate…

This is a classic CSS issue of creating forms. I like your implementation and am especially impressed by the way that you show the headings only once. However, I think that there is a semantic problem here. For accessibility, you solution is the best one and I would use it myself. However, I think that this form should be in a table. This is not using a table for layout, it is the intended use for a table. For instance, if you were to make this same form as a print document, you would put it in a table. I understand why you did it that way and if I had to make a form like this today I would do it pretty much the same way. However, in the future I would like to see screen readers understand table forms better – since they are sometime the semantically appropriate method.

This is clearly tabular data. Semantic html doesn’t not mean to avoid tables, it’s about using tables for what tables was meant to be used for.

If a table would be used to show the data why not use it to construct the form which supplies the data? Well – ok – JAWS doesn’t support it and maybe other screen readers doesn’t but if there’s anything that Internet Explorer has tought us that would be to follow standars – not software.

If JAWS does not support tabular forms – it’s their problem, not ours. No disrespect of blind people – the opposite actually. They deserve a Firefox-like software also that can read what it should be able to read.

Labels, fieldsets etc should be used but tables is also the correct way of constructing this – by constructing a table you know that every row has a relation which is defined in some manner and you know by each columnhead what data that column holds. To use tables in a form such as this is the correct way of using tables.

Agreed.

These days many coders seem to defer to accessibility tools as if they’re Gospel, and end up carving up their markup like a Christmas goose to adhere to them, making other, far more used rendering tools and users suffer because of it.

As many here have pointed out, although this is a form due to its need for user input, it is clearly a tabular dataset as well, so it seems to me that any incompatibility with screen readers is an issue that the screen reader developers need to deal with.

Browsers aren’t perfect, and neither are screen readers.

“These days many coders seem to defer to accessibility tools as if they’re Gospel, and end up carving up their markup like a Christmas goose to adhere to them, making other, far more used rendering tools and users suffer because of it.”

I have to agree with this. If we keep giving screen readers a free pass, then this situation won’t get any better — what if we’d made excuses for Internet Explorer 5.0?

It is especially critical for non-visual user agents (screen readers, spiders, etc.) to respect semantics, since that’s the only way they can infer meaning. We need to hold their feet to the fire — JAWS, Window-Eyes, Home Page Reader — just like we did with IE. In the meantime, we can provide alternate interfaces where required for accessibility.

What everyone else said: this is tabular data, so it belongs in a table. It’s a mistake to design your markup for specific user agents. It was a mistake when we were using tables for layout because it was otherwise difficult to get them to look pretty in IE, and it’s just as much a mistake when we’re not using tables for tabular data because it’s difficult to get them to sound pretty in JAWS.

I really appreciate this discussion, as both sides have very valid points.

Semantically, I think a table describes the data best. However, as emphasized through initiatives like microformats, data should be designed for humans first. I haven’t done much testing with screen readers, so I’ll take James’ word for it that a screen reader would have difficulty with a form/table hybrid. I’m all in favor of semantic markup, but if it will cause difficulty in a user agent, whether it’s a browser, a screen reader or anything else, the markup should be compromised to make the information easier to digest. It’s unfortunate that certain user agents incorrectly interpret semantics, but to claim that “any incompatibility with screen readers is an issue that the screen reader developers need to deal with” is creating a scapegoat and avoids providing a solution.

That is indeed very much a table, so no convoluted markup and CSS required. The tabular data may be editable, but it’s still tabular data, therefore it goes in a table, poor screenreader support or no. Insisting on throwing tables out in instances like this (when it absolutely is a table) just gives CSS a bad name.

“I’m all in favor of semantic markup, but if it will cause difficulty in a user agent, whether it’s a browser, a screen reader or anything else, the markup should be compromised to make the information easier to digest.”

This is a little too absolute for my taste. As with everything else in web design, it’s a trade-off: is the time spent on the workaround worthwhile? All else being equal, I’d pick the solution that satisfies the WCAG and minimizes the time spent on the problem. In this case it’s an alternative interface.

“It’s unfortunate that certain user agents incorrectly interpret semantics, but to claim that ‘any incompatibility with screen readers is an issue that the screen reader developers need to deal with’ is creating a scapegoat and avoids providing a solution.”

I’m not making them a scapegoat; it’s their product. They need to be held accountable; that’s why we have standards in the first place. And there is an interim solution: provide an alternative interface until the semantics are correctly interpreted by screen readers. It’s in the long-term interest of accessibility if designers and developers demand proper standards support from all user agents. There’s no reason why we can’t fight on two fronts at once.

I have believed for years that screen readers, especially JAWS, are of absolutely unacceptable quality when it comes to their design and understanding of markup.

I’m in agreement with those above that think this data is tabular. It’s not just tabular data, it’s a tabular form.

Tabular forms exist in the UI world as standard widgets – any spreadsheet uses them, javax.swing, some colour pickers. Why can the designers of JAWS not comprehend these issues?

Why does JAWS not tell the user there is a table in this form, and give the user some indication of what’s in the table. Or perhaps it could look at tags… Instead of ignoring tables completely!

I an very much of the opinion that we should use tables and force the screen reader developers to push forward. Unfortunately, the recent onslaught of lawsuits against ‘inaccessible’ websites doesn’t do much to help the situation!

Nonetheless, if you’re going to cave in against the screen readers, this is about the best way I’ve seen. Clicking on some of the labels does some slightly strange things in Opera, though..

I am going to use this technique on a form that shows dates with select boxes and the correct label on top.

For those into the discussion of whether or not this is a table or not, yes in the case of listing numbers it is a table but if you use like I am going to it’s not a table.

I have a demo here and it is not finished and it is in swedish. :P

A lot of good arguments.
Very logical use of fieldsets and labels.
Nice to see someone taking accessibility seriously. Something too often forgotten.

I’ve had problems with wrapping the ‘labels’ around ‘inputs’ before. It broke for me in IE Windows.

@Keith Humm:

“Tabular forms exist in the UI world as standard widgets – any spreadsheet uses them, javax.swing, some colour pickers. Why can the designers of JAWS not comprehend these issues?”

Maybe because they have not yet been presented with tabular data in which header information and content have effectively been matched one to the other.

You mention spreadsheets (which would be the logical basis for understanding double-entry tables): in Excel for instance you still have headers displayed as bold, and there’s no more information than that available. It’s still strongly based on visual experience and I’m not sure anywhere in any of the UIs you mention the information is structured enough for any tool to infer that ‘this is a two-entry spreadsheet widget’.

Add to that the fact that up until recently tables were so abused for HTML layout and that should give us a hint as to why assistive technology developers haven’t looked any further into these issues. They already have so much to tackle, I’m afraid.

This article is very inspirational, I had never thought of formatting forms that way.