Log in   Register a New Account

Accessify Forum - Discuss Website Accessibility

New to the forum?

Only an email address is required.

Register Here

Already registered? Log In

tfoot and tabindex

  • Reply to topic
  • Post new topic
Reply with quote I have an HTML data table, with radio buttons in the tfoot. Because the tfoot is between the thead and tbody (as the XHTML spec says it should be*), the tab sequence is “wrong” — the radios gain focus between the thead and the tbody, in HTML order.

I don’t generally like putting tabindex attributes in stuff, cos the browser default behaviour gets totally stuffed (you always start at 1, effectively, so all the stuff earlier in the page, like skipnav links and so on) get missed out). But I can’t think of any other way to sort out the radios’ order in the page’s tab sequence?

tabindex attributes seem to me to be the only (and, thus, best) way to “solve” the issue… Thoughts, anyone? Smile

* <!ELEMENT table (caption?, (col*|colgroup*), thead?, tfoot?, (tbody+|tr+))>
Reply with quote do the controls have to be part of the table at all? could they be put in a fieldset immediately after the table instead?

Patrick H. Lauke / splintered
Reply with quote
redux wrote:
do the controls have to be part of the table at all? could they be put in a fieldset immediately after the table instead?

Yeah, the controls relate to the tabular data.

Essentially, the table is a “product”-comparison table, with the radios at the bottom being part of the “apply for this ‘product’” functionality. But yes, they do want to be radios (rather than links or buttons); that's something I can’t change on my own behalf.
Reply with quote The other possibility, of course, is to break the XHTML validity by moving the <tfoot/> to after the <tbody/>, which would provide the expected behaviour, but sacrificing code validity as a result (that's a trade-off my boss would have to sign off, of course).
Reply with quote
owenblacker wrote:
Yeah, the controls relate to the tabular data.


but that relationship wouldn't be any less obvious (within the limited nature of HTML) if it was just outside, but adjacent, to the table itself, imho


Quote:
But yes, they do want to be radios (rather than links or buttons)


they can be radio buttons, all i'm saying is that it'd make sense to wrap them up in a fieldset

Patrick H. Lauke / splintered
Reply with quote <tfoot> is designed to provide a comment
Selida wrote:
By explicitly grouping footer rows with TFOOT, authors give browsers the ability to include the footer rows on each page of a printed, multi-page table, as well as the ability to present a long table with a scrolling body and static footer rows. However, few browsers currently support TFOOT, and the requirement that it be placed before the TBODY may make it unsuitable for non-supporting browsers. If the presentation of footer rows prior to body rows is not acceptable, authors should avoid using TFOOT until browser support is greater
so IMHO adding the button row to the <tbody> would allow this to function. Remember <tfoot> is optional not obligatory and not poorly supported by browsers.

Mike Abbott
Accessible to everyone
Reply with quote
redux wrote:
but that relationship wouldn't be any less obvious (within the limited nature of HTML) if it was just outside, but adjacent, to the table itself, imho

But then they’d lose their relationship to the columns:

Code:

+-------------------+---------+---------+
| Header            | header  | header  |
+-------------------+---------+---------+
| Header            | data    | data    |
+-------------------+---------+---------+
| Header            | data    | data    |
+-------------------+---------+---------+
| Apply now         | (radio) | (radio) |
+-------------------+---------+---------+

                                 [Submit]
Reply with quote
Mikea wrote:
<tfoot> is designed to provide a comment

Not necessarily; it's designed to provide footers. These buttons are indeed footers to the columns in question. There might be a lot of data in the table, necessitating (for example) the tbody to be set to scroll. The buttons would still want to be available.

Mikea wrote:
IMHO adding the button row to the <tbody> would allow this to function. Remember <tfoot> is optional not obligatory and not poorly supported by browsers.

I disagree. Semantically, I think the buttons do indeed want to be in a <tfoot/> element, though it'd be difficult to explain why without going into a lot more (rather dull) detail about the context.

Suffice to say that my boss and I are both semantic HTML and validation nazis and we'd be more prepared to sacrifice the code validity (moving the tfoot to after the tbody) than we would the code semantics.
Reply with quote If you are to implement this with tabindex then essentially you have to provide tabindex="1" on all links in the table except for tfoot, and all links prior to the table. If you have multiple tables then it will be even more complex.

Simon Pieters
Reply with quote
zcorpan wrote:
If you are to implement this with tabindex then essentially you have to provide tabindex="1" on all links in the table except for tfoot, and all links prior to the table. If you have multiple tables then it will be even more complex.

Yeah, that's why I think tabindex is very poorly thought-out in the XHTML spec.

It is rarely possible to provide tabindex definitions for everything before the (usually very small) area where one wishes to change the default, without hand-crafting the HTML of every page in your site. I certainly don't have the ability to do so in this situation, without post-processing every page we serve (which is a ridiculous idea, even if the performance impact wouldn't be intolerable).
Reply with quote Seeing an online example of the page could help us give advice more specific to this page's purpose.
Reply with quote You are allowed multiple tbody's per table - perhaps it isn't too much of a fudge in semantics to put your checkboxes in a following tbody?
Reply with quote
Cerbera wrote:
Seeing an online example of the page could help us give advice more specific to this page's purpose.

Yeah, the page isn't online yet — it’s a site rebuild. Sorry, I know I’m not making it easy for you guys to offer advice.

Jason Davis wrote:
You are allowed multiple tbody's per table - perhaps it isn't too much of a fudge in semantics to put your checkboxes in a following tbody?

Now that's not a bad idea at all; I might give that a try and see what people around here think. Thanks for the suggestion!
Reply with quote
owenblacker wrote:
Yeah, that's why I think tabindex is very poorly thought-out in the XHTML spec.
It's possible to fix that. I've proposed a way to scope tabindex on the WHATWG list.

Simon Pieters
Reply with quote You really shouldn't mix table and forms markup; a screenreader in forms mode, for example, may ignore any markup that isn't forms markup, or in table reading mode it may ignore everything that isn't a table.

The risk then is that for these users, parts of the layout will be difficult or impossible to access - the user finds a table, switches to table mode, and suddenly the form is no longer in their spoken output. In order to make sense of and use the layout, they would have to switch continually between tables and forms mode.


Now I know this is difficult, but what I suggest is you find a way of making the entire layout be a form. You can create relationships between data values using the forms markup available - fieldset, legend, label - and then use CSS to arrange them in a grid.

Well maybe! It depends on the complexity of the data. I admit I've been trying to make layouts like this recently, and it's difficult to get it stable and flexible enough. I wouldn't blame you if it's too complicated, and easier just to stick with what you've got.

But either way ... definitely don't mix forms and tables together. If an ideal solution is not possible, at the very least have your form outside the table, and use text to describe the relationships.

Display posts from previous:   

Page 1 of 2

Goto page 1, 2  Next

All times are GMT

  • Reply to topic
  • Post new topic