Tables with form fields: am I crazy?
Home / Site Building & Testing / Tables with form fields: am I crazy?
I'm working on an online registration service. Customers submit their details and have a chance to review before submitting. This is marked up as a table.
They can come back to log in to review their details. Some (not all) of the fields will be editible. I'd like to use the same table, making the editible fields editible, and this is where I think I might be going down the wrong path - mixing tables with form elements.
This is part of my sort of idea:
| Code: |
| <tr>
<th scope="row">Property type</th> <td>House</td> <td></td> </tr> <tr> <th scope="row">Title</th> <td>Mr</td> <td></td> </tr> <tr> <th scope="row"> <label for="edittitle"> Edit Title</label> </th> <td> <input type="text" id="edittitle" /> </td> <td><input type="submit" value="Save changes" /></td> </tr> |
Is this accessible or is it back to the drawing board?
Share: 
Yeah, it would probably confuse things slightly by giving conflicting approaches._________________
};-) http://www.xhtmlcoder.com/
WVYFC chose the Yorkshire Air Ambulance as the main charity to fund raise for in 2006
Share:
Once, I would have considered that a reasonable approach. That was before I heard of "forms mode":
| Quote: |
| "JAWS has special support for form reading and input, which it calls 'Forms Mode.' Users can toggle 'Forms Mode' on and off at any time, but more typically, JAWS automatically turns it on when the user enters the first form element. Once in 'Forms Mode,' JAWS only reads the information that is included in a form element or label it does not read extraneous text or information around the form elements." — Forms: How JAWS Reads Forms |
So long as all of your form fields are provided at the end of the table and everything thereafter is either a form input or a label element, there shouldn't be much problem. Otherwise, you run the risk that users might miss information provided after the editable fields.
A better approach might be to separate the edit form from your table. You could have it after the table or on a separate page, and provide a link to go straight to the correct field in the form after each editable value.
PS: Forms mode has recently become the bane of my life when it comes to accessibility concerns, so if you find yourself irritated by how it works, I sympathise entirely.
Share:
| Quote: |
| A better approach might be to separate the edit form from your table. You could have it after the table or on a separate page, and provide a link to go straight to the correct field in the form after each editable value. |
Yes I'm probably going to have two pages like you suggest. Mixing tables and forms is proving too problematic. Thanks for your feedback.
Share:
If the "forms mode" typically implemented by leading screen readers makes sensible markup (such as tabular forms) hard to use, that's the screen readers' problem. Not yours.
They could respect table relationships when in forms mode if they wanted to. <th scope> could work much like <label for> and the way <legend> text is associated with the controls in that <fieldset>.
HTML5/Web Forms 2 proposes a <datagrid> element to help with these cases.
_________________
My CV type thing and my Life of Ben (Blog). Nigel Peck's Accessify Forum Requirements.
Share:
| Cerbera wrote: |
| If the "forms mode" typically implemented by leading screen readers makes sensible markup (such as tabular forms) hard to use, that's the screen readers' problem. Not yours. |
Well, No ben, it is your problem, if you want to make forms within tables accessible to screen reader users.
It is a current limitation of the major screen readers that they cannot interrogate tables when in forms mode. If one is aware of this, one can take this into account when designing table based forms to overcome this issue for blind users who rely on these screen readers to access the web and desktop applications.
There are 2 ways to do this: Use a hidden explictly asociated label element for each input or use the title attribute to label each input.
here are examples and code.
_________________
Steve Faulkner
Technical Director
TPG Europe
The Paciello Group | Web Accessibility Tools Consortium
Share:
That's a fantastic presentation, Steve. You running it again any time soon? Would like to come and see it._________________
www.brucelawson.co.uk
Web Evanglist, Opera, WaSP Accesibility Task Force
Study the Web Standards Curriculum
International Lothario (retired)
Share:
hi bruce, thanks!. Hans and I will be doing an updated version for a workshop at CSUN in March, unfortunately it's in Los Angeles 
But would be great to see you there!
_________________
Steve Faulkner
Technical Director
TPG Europe
The Paciello Group | Web Accessibility Tools Consortium
Share:
Seconding Bruce's comment. Steve, please let us know on the forum if you know there is likely to be a UK airing of the presentation. Thanks._________________
Jon Gibbins :// blogs at dotjay.co.uk, works with Analog.
Share:
hi Dotjay, thanks, will look at putting on a workshop locally as there appears to be some interest 
_________________
Steve Faulkner
Technical Director
TPG Europe
The Paciello Group | Web Accessibility Tools Consortium
Share:
| stevefaulkner wrote: | ||
|
- Using title on <input>:
- Inconveniences sighted mouse users with an unnecessary tooltip.
- Will be unavailable to any sighted non-pointer user.
- Adds quite a lot of markup, making it slightly more expensive to author and slightly less efficient to download.
- Inconveniences sighted mouse users with an unnecessary tooltip.
- Hidden <label>:
- Complicated markup in tandem with CSS makes it more expensive to set up and harder to maintain.
- Will be unavailable to sighted users of voice activation software.
- Complicated markup in tandem with CSS makes it more expensive to set up and harder to maintain.
Stephen Lang suggested wrapping the row header in a visible <label> and linking it to the relevant <input> using for+id. In simple tables where there is only one control per row and the header text makes for a sensible control label, that would work for everyone?
In other tables, such as the one in your slide, the real solution is for devices to support web content. Correctly structured data tables with sensibly located form inputs should be usable in assistive devices. The semantics are there but the device is not using them.
(EDIT) List items are now numbered for easier responses. I should have done that when I wrote it.
_________________
My CV type thing and my Life of Ben (Blog). Nigel Peck's Accessify Forum Requirements.
Last edited by Ben Millard on 07 Feb 2008 06:51 pm; edited 1 time in total
Share:
| Quote: |
| If a website provides good markup but a device doesn't support it, the problem is in that device. The problem is not in the website. |
Using title on <input>:
- Inconveniences sighted mouse users with an unnecessary tooltip. (tooltips are ubiquitous, so saying they may annoy sighted users is a weak argument against their use and they also benefit "sighted" screen magnifier users)
- Will be unavailable to any sighted non-pointer user. (so what?, the title attribute is being used to provide the extra contextual information that is already available to "sighted non-pointer user(s)" via the table headers, but not available to screen reader users in forms mode.)
- Adds quite a lot of markup, making it slightly more expensive to author and slightly less efficient to download. (I am willing to go that extra mile to provide table based forms that can be used by screen reader users. btw if it adds "quite a lot of mark up" would it not be "quite a bit more expensive" not "slightly")
- Complicated markup in tandem with CSS makes it more expensive to set up and harder to maintain. (you are not going to enjoy WAI-ARIA then...)
- Will be unavailable to sighted users of voice activation software. (another non argument as you are advocating not providing the text labels in the first place)
| Quote: |
| the real solution is for devices to support web content. |
But in this case they don't fully support it and until they do, if we want to provide practical access to controls in data tables for screen reader users a method is required.
_________________
Steve Faulkner
Technical Director
TPG Europe
The Paciello Group | Web Accessibility Tools Consortium
Share:
1a: Steve, tooltips are not ubiquitous. Mobile phones, portable games consoles and Terminal browsers generally don't support them. Also, causing annoyance for a significant portion of users seems like a strong argument against hackish techniques, to me!
In tables with <th> for headers and regular layout, screen magnifiers could run the table header association algorithm and output the result for each cell into its title property. Then it's available in any sensible table, not just tabular forms with title everywhere.
1b: If a voice activation product doesn't support tabular forms, there's no convenient way for its user to put focus in a tabular form control. The user can't see tooltips or off-screen <label> elements, so hackish techniques are not helping those users.
Voice activation software could do much the same thing, enabling their customers to reach tabular form controls by using the header text as if it were <label> text.
1c: The more effective plan is for ATs to "go the extra mile" and support sensible markup. Then content becomes accessible even when it's made by authors who haven't the foggiest what a screen reader is.
You're probably right about hackish techniques being more costly than I said. Another reason to avoid them.
2a: Indeed!
2b: The labels are the table headers. Exactly the same as in a data table.
| stevefaulkner wrote: |
| What you term as a design choice would be better termed as a design constraint. While all the semantics are there, they are not currently available to AT users due to the limitiations of the AT to allow simultaneous interactive access to some controls (text,text area, select) and to the functionality needed to interogate header/cell relationships.
(Source: Accessibility Tips.) |
_________________
My CV type thing and my Life of Ben (Blog). Nigel Peck's Accessify Forum Requirements.
Share:
Hi ben,
if the measure of providing solutions that work was about arguing about what AT does not do, until you are blue in the face, then you would win every time. Unfortunately this is not the case.
_________________
Steve Faulkner
Technical Director
TPG Europe
The Paciello Group | Web Accessibility Tools Consortium
Share:
The original message suggested this:
| Code: |
| <tr>
<th scope="row">Property type</th> <td>House</td> <td></td> </tr> <tr> <th scope="row">Title</th> <td>Mr</td> <td></td> </tr> <tr> <th scope="row"> <label for="edittitle"> Edit Title</label> </th> <td> <input type="text" id="edittitle" /> </td> <td><input type="submit" value="Save changes" /></td> </tr> |
| Code: |
| <table>
<tr> <th>Property type</th> <td>House</td> </tr> <tr> <th><label for="title">Title</label></th> <td><input id="title" id="name" value="Mr"></td> </tr> </table> <input type="submit" value="Save changes"> |
- Each table header is marked up with <th>, so it's a complete data table.
- Each label used <label for> and is associated with the corresponding <input name id>, so it's a complete form.
- Having a single row for each editable detail avoids repetition, which helps all users.
- type="text" is the default for <input>. You can omit it to make the markup simpler.
- A single button after the table helps everyone by reducing the number of form controls. It also removes an empty cell from the end of each non-editable row.
A bonafide tabular form removes the <label> elements, for attributes or id attributes. It relies on <th> being applied to the corresponding <td>, including the <input> it contains. There's no voodoo. It's simple.
| Code: |
| <table>
<tr> <th>Property type</th> <td>House</td> </tr> <tr> <th>Title</th> <td><input id="name" value="Mr"></td> </tr> </table> <input type="submit" value="Save changes"> |
_________________
My CV type thing and my Life of Ben (Blog). Nigel Peck's Accessify Forum Requirements.
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