Forum OpenACS Development: forms as columns of template::list

Hello,

I need to setup a table where one of the columns contains a form, a text input.

If I want to use "template::list", the only alternative to do this is the "display_template" property of elements. This way, I build the form HTML in the tcl file and the I include this piece of HTML with the "display_template" property. And it works.

However, when applying the design guidelines proposed by the Accesibility Tutorial in Valencia, I found that building HTML in tcl files is not recommended at all, and the use of "display_template" is explicitly discouraged.

My question: Is there any other way to include a form as part of a table created with "template::list"? And if not, does it make sense to modify the template and include this functionality?

Best,
Luis

Well, I have to present several parameters of a (maybe)large number of users. I think a table with template::list fits for this situation.

The special requirement appears because some of these parameters may be writable, so I put a form there.

If your recommendation is to avoid forms in a table, I will explore other alternatives. Do you have any suggestion?

Anyway, I'm not pretty sure about what kind of accesibility problem appears when you include forms in a table. Just for understanding, could you tell me more about it?

Direct action is MUCH easier in general. Imagine a spreadsheet.

The idea is to reduce the number of steps for a user.

I think in this case an edit button that either

1) opens the form in a new page
or
2) openacs an inline ajax form if the user's browser supports that.

We don't have good guidelines on how to add that type of interaction in an accessible way, so it's hard to say if we could accept that type of implementation in OpenACS or .LRN but you could certainly implement it for a local internal application as long as it met your specific requirements.

Using display template is the best way to accomplish your goal. You don't need a form for every row, but just a form element in each row. I am not sure about the validation requirement for forms and tables though. You will have to look it up.

Emma, I agree, this is not a good solution. Maybe it looks better if we don't take into account the accesibility. But if we do...

I will reconsider the user interface.

Thank you for your comments.

Hi Ryan,

I'm afraid that marking up the data with DIV won't solve the accessibility problem. Actually, it would introduce another one. Tabular data has to be marked up using the TABLE element and the corresponding TH/TD and their attributes to associate header cells with data cells.

This is documented in WCAG 1.0 (checkpoint 5.1 and 5.2 - priority 1) and in WCAG 2.0 (technique H51 for success criterion 1.3.1 - level A).

Valid markup is not a guarantee of accessibility by itself, although it's part of it. Using appropriate markup is even more important. HTML is primarily used to structure the content semantically (not to format it), so each type of data has to be marked up according to its nature.

In this case, the problem is not the template. The default template for template::list produces valid and appropriate markup for tabular data. Using a table to format a form is acceptable from the accessibility perspective (as long as a few rules are followed), but not recommended. The problem here would be to mix the two types of content: the data and the form to modify it.