tfoot and tabindex
Home / Site Building & Testing / tfoot and tabindex
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?
* <!ELEMENT table (caption?, (col*|colgroup*), thead?, tfoot?, (tbody+|tr+))>
Share: 
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 / webmaster / University of Salford
co-lead: WaSP Accesibility Task Force
take it to the streets ... WaSP Street Team
personal: splintered | photographia | redux
co-author: Web Accessibility - Web Standards and Regulatory Compliance
Share:
| 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.
Share:
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).
Share:
| 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 / webmaster / University of Salford
co-lead: WaSP Accesibility Task Force
take it to the streets ... WaSP Street Team
personal: splintered | photographia | redux
co-author: Web Accessibility - Web Standards and Regulatory Compliance
Share:
<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 |
_________________
Mike Abbott
Accessible to everyone
Share:
| 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] |
Share:
| 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.
Share:
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
Share:
| 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).
Share:
Seeing an online example of the page could help us give advice more specific to this page's purpose._________________
My CV type thing and my Life of Ben (Blog). Nigel Peck's Accessify Forum Requirements.
Share:
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?_________________
Supermod @ CodingForums
Website: http://www.jasonkarldavis.com
Share:
| 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!
Share:
| owenblacker wrote: |
| Yeah, that's why I think tabindex is very poorly thought-out in the XHTML spec. |
_________________
Simon Pieters
Share:
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.
Share:
All times are GMT
You cannot post new topics in this forumYou cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum