Tables with form fields: am I crazy?
Home / Site Building & Testing / Tables with form fields: am I crazy?
As i said previously ben, ther are two ways to do it, one using label ('explicitly' implied) or the other using title attribute. Your label example is fine in a simple example you have provided. now go out in the real world and work on web applications that contain complex form/data tables that cannot be reformulated, see how far you get. As for your "retrofitting" comment another red herring dropped in to prove a point, not provide sound advice._________________
Steve Faulkner
Technical Director
TPG Europe
The Paciello Group | Web Accessibility Tools Consortium
Share: 
| stevefaulkner wrote: | ||
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. |
Ive been doing alot of testing recently on tables with forms and this is the best method i have found.
Labels are irritating if you want to style your layout in certain ways, like having all your edit boxes align and have allt he labels align to something else. But i found that by default most screen readers primarily read the label, and optionally the title and alt attributes. So excluding a label and using only the title is a gamble.
In testing i founf Dolphins HAL superior to Freedom Scientific's JAWS for navigation and forms. Though i was testing with JAWS 8 (latest being 9.5 or 10 i think) and the latest HAL, so bare that in mind.
I lay out my title with a desription along the following format.
| Quote: |
|
title="Input Text: Field Name. Description & instructions. Specific info." e.g. title="Input Numeric: Date of birth. Please enter your date of birth here. Date should be in day/month/year format, as dd/mm/yy. or title="Input Numeric: Order Ammount. Please enter the number of items you are requesting." |
In addition i use hidden labels as described and visible labels or text labels. The hidden labels usually have the same format as the title.
Tested with JAWS, HAL and windows Narrator and its acceptable with all three. The tite seems lengthy but its easily skipped.
Share:
From Enhancements in JAWS Version 8.0.422, the "HTML and the Internet" section:
| Quote: |
|
| Barking_Mad wrote: | ||||
I lay out my title with a desription along the following format. [...]
|
- The fact it's an input is given by it using the <input> element.
- Dates aren't numbers, which means the first title is wrong.
- The second title is redundant since "Amount" obviously requires a number.
- The second label could be labelled "Number of Items" to make the requirement of a number clearer to everyone.
- The label is given by the <label> element (or by the table headers in tabular forms).
- "Please enter foo" is obvious since it's an <input> with "foo" as the label!
- The label is where any format requirements must be so everyone can see what they are.
| Barking_Mad wrote: |
| In addition i use hidden labels as described and visible labels or text labels. The hidden labels usually have the same format as the title. |
This exemplifies another problem: hackish techniques teach people to add more attributes and cause more repetition.
_________________
My CV type thing and my Life of Ben (Blog). Nigel Peck's Accessify Forum Requirements.
Share:
| Quote: |
| Unable to navigate tables with the standard table reading commands while in Forms mode.
|
This quote from freedom scientific merely states the issue, does not say that it has been fixed.
But upon testing with JAWS 8, yes indeed, some table reading commands
for example "ALT+CTRL+RIGHT ARROW, JAWS reads the column header and the data in the cell and announces the column number" when in forms mode, though this is not stated explicitly within JAWS 8/9 help.
So JAWS 8.0 + has solved this issue to an extent. If the user uses particular table reading commands (when in forms mode) they can access the row/column header.
thank you for unearthing information about this fix. can't say freedom scientific aren't trying!
Does this negate the advice to use the title attribute, unfortunately not, as this feature only applies to version 8+ of JAWS, so users of other AT such as window eyes or older versions of JAWS, or users who don't know about the capability (in JAWS 8+) or users who navigate to the table in forms mode (will not be informed they are in a table) and will not know that they can interogate the header info. The common method used to check the label for a control is to use INS+DWN ARROW when the control has focus, unfortunately this still does not work in JAWS 8+ when in forms mode.
The use of title or label in this context is still the most reliable way to provide labels for form controls.
Perhaps in some years time, when all the major AT has provided this facility in a number of versions, and bugs have been fixed (see below) will it be appropriate to put the title technique to bed.
You seem to think that describing the use of the title attribute as "hackish" somehow undermines its use, but have not provided any evidence on how it is "hackish"
The use use of the title attribute on controls is a suggested technique in WCAG 2.0:
H65: Using the title attribute to identify form controls when the label element cannot be used
Of course you can disagree with this advice, if so bring it up with the WAI WG I am sure that they will be interested in your concerns, and if you can offer solid reasons why it should not be promoted, they may well modify or remove it.
In testing the enhanced table interrogation feature in JAWS 8.0 an unfortunate issue was revealed
When navigating to the first text input in the very simple table (below) the header text "date header" is incorrectly associated with it. This is due to JAWS heuristics which in the abscence of a explicitly associated text label will announce text to the left of a control as the text label. So leaving an explicitly associated label even for JAWS 8+ is a non starter if you want it to be accessible to users of AT.
example code:
| Code: |
| <table>
<tr> <th>name header</th> <th>date header</th> </tr> <tr> <td><input type="text"></td> <td><input type="text"></td> </tr> </table> |
_________________
Steve Faulkner
Technical Director
TPG Europe
The Paciello Group | Web Accessibility Tools Consortium
Share:
| stevefaulkner wrote: |
| Perhaps in some years time, when all the major AT has provided this facility in a number of versions, and bugs have been fixed (see below) will it be appropriate to put the title technique to bed. |
There was a bug with the title technique. So by your reasoning, as I understand it, we can't use that technique: it only works fully for JAWS 8+ users and it's only been 2 years since that version was released.
| stevefaulkner wrote: |
| In testing the enhanced table interrogation feature in JAWS 8.0 an unfortunate issue [...] announce text to the left of a control as the text label. |
- If there is a <th>, scope or headers:
- Apply the table header association algorithm.
- If there is a form control:
- Get the control labels from the headers for that cell.
- If there is a <label>:
- Add to the control labels using the <label> association algorithm.
- Get the control labels from the headers for that cell.
- Apply the table header association algorithm.
- Otherwise:
- If there is a form control:
- If there is a <label>:
- Get the control labels using the <label> association algorithm.
- Otherwise:
- Get the control labels using the absent <label> heuristics.
- If there is a <label>:
- If there is a form control:
- End.
I am trying to make more of the web accessible using the simplest and most intuitive markup possible. Consider the repetition in Barking_Mad's use of the title technique compared to support for tabular forms.
(EDIT) Fixed some typos and reduced rambling.
_________________
My CV type thing and my Life of Ben (Blog). Nigel Peck's Accessify Forum Requirements.
Last edited by Ben Millard on 14 Apr 2008 07:00 pm; edited 1 time in total
Share:
ben, in the end you can use whatever method you choose to mark up your controls within data tables, the reality is, for the forseeable future most AT users will have problems accessing the the control names if you don't use either the title or label element._________________
Steve Faulkner
Technical Director
TPG Europe
The Paciello Group | Web Accessibility Tools Consortium
Share:
Hey Steve,
If we don't include explicit labeling, isn't that going against Section 508 and WCAG 2.0?
Couldn't you wrap the label tags around the input?
_________________
Rosemary Musachio
E&IT Accessibility Analyst
TecAccess
www.tecaccess.net
Without challenges, you are not living
Share:
Er ... why use a table at all?
Share:
Read the whole topic and the previous 2 queries will be answered._________________
My CV type thing and my Life of Ben (Blog). Nigel Peck's Accessify Forum Requirements.
Share:
| RMusachio wrote: |
| Hey Steve,
If we don't include explicit labeling, isn't that going against Section 508 and WCAG 2.0? Couldn't you wrap the label tags around the input? |
Here's a quote from the JimThatcher.com website regarding wrapping label tags around the input.
| Quote: |
| The label element can be used in two ways.
The first way to use the label is as a container of both the labeling text and the form control as in the following example. <label>First Name: <input type="text" name="fn" size="20" /> </label> That example has both the first (proximity) and third (label) techniques applied to it; the prompt "First Name" is close to its text entry field, and the prompt is programmatically identified to be "First Name" with the label element. Unfortunately screen readers have difficulty with this use of the label element as a container and one screen reader doesn't recognize it at all. So do not use the label as a container. Instead use the label element with the for attribute whose value is the id of the input element. The example above now looks like this. <label for="fn">First Name:</label> <input type="text" name="fn" id="fn" size="20" /> |
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