We tried this very solution two years ago, but it failed user testing with people with disabilities. Although it looks nice, we had the choice between making an alternative accessible version, or to simplify the form layout and remove the tabular-type layout. We chose not to use the tabular type layout, but broke each “row” into a separate fieldset with visible labels – and thankfully, that worked out really well.
The structure of this particular form is tabular, so using a table for laying it out is semantically and structurally correct. Yes, the tabular structure is ignored by JAWS in forms mode, but that’s no reason to remove structurally correct markup. The nested fieldsets are a useful alternative, but then you lose the two dimensional cellular structure for a two level hierarchical structure. Compounding that with hiding labels, and your nested fieldset emulation loses information that some groups of disabled people need.
The main audience this solution creates barriers for are disabled people using screen magnifiers – for them it is important that every field is properly visually labelled (the same rationale for people with cognitive difficulties). Take for instance the form element in the bottom right hand corner (as a worse case scenario) – in a screen magnifier focused on this field, they’d be very fortunate if the “column heading” of “Played” (three lines higher up) is visible in the magnification area, but the “row header” Game points most certainly won’t be visible. (Incidentally, that’s why having the form label immediately above textfields, text areas and selects is the more accessible approach – it is far more likely for both elements to be visible at the same time in a screen magnifier region).
Now if it were marked up as a table, there could have been a fallback way of giving people using screen magnifiers an online highlight/announcement of the row and column headings (like a browser extension like Gez Lemon’s excellent Table Inspector: http://juicystudio.com/article/firefox-table-inspector.php ). Or if the labels were visible adjacent to their respective form fields…
Although the resulting barrier isn’t an impossible one, it is still a barrier that’s difficult for certain groups of disabled people to cope with. The main suggestion is to remove the table-emulation styles (of hiding labels offscreen), and use the fieldset and label structure to visually emphasise the relationships in the form elements, and not to position them offscreen – so back to http://24ways.org/examples/showing-good-form/article-example3.gif – that is the most accessible of the form layouts on this page (when its styled with only one text field per line). The CSS that follows creates accessibility barriers – by hiding information that’s necessary for screen magnifier users and people with cognitive disabilities.
We tried this very solution two years ago, but it failed user testing with people with disabilities. Although it looks nice, we had the choice between making an alternative accessible version, or to simplify the form layout and remove the tabular-type layout. We chose not to use the tabular type layout, but broke each “row” into a separate fieldset with visible labels – and thankfully, that worked out really well.
The structure of this particular form is tabular, so using a table for laying it out is semantically and structurally correct. Yes, the tabular structure is ignored by JAWS in forms mode, but that’s no reason to remove structurally correct markup. The nested fieldsets are a useful alternative, but then you lose the two dimensional cellular structure for a two level hierarchical structure. Compounding that with hiding labels, and your nested fieldset emulation loses information that some groups of disabled people need.
The main audience this solution creates barriers for are disabled people using screen magnifiers – for them it is important that every field is properly visually labelled (the same rationale for people with cognitive difficulties). Take for instance the form element in the bottom right hand corner (as a worse case scenario) – in a screen magnifier focused on this field, they’d be very fortunate if the “column heading” of “Played” (three lines higher up) is visible in the magnification area, but the “row header” Game points most certainly won’t be visible. (Incidentally, that’s why having the form label immediately above textfields, text areas and selects is the more accessible approach – it is far more likely for both elements to be visible at the same time in a screen magnifier region).
Now if it were marked up as a table, there could have been a fallback way of giving people using screen magnifiers an online highlight/announcement of the row and column headings (like a browser extension like Gez Lemon’s excellent Table Inspector: http://juicystudio.com/article/firefox-table-inspector.php ). Or if the labels were visible adjacent to their respective form fields…
Although the resulting barrier isn’t an impossible one, it is still a barrier that’s difficult for certain groups of disabled people to cope with. The main suggestion is to remove the table-emulation styles (of hiding labels offscreen), and use the fieldset and label structure to visually emphasise the relationships in the form elements, and not to position them offscreen – so back to http://24ways.org/examples/showing-good-form/article-example3.gif – that is the most accessible of the form layouts on this page (when its styled with only one text field per line). The CSS that follows creates accessibility barriers – by hiding information that’s necessary for screen magnifier users and people with cognitive disabilities.