E-mail List Archives
Thread: Correct mark-up for a form in a table
Number of posts in this thread: 4 (In chronological order)
From: Rich Pedley
Date: Wed, Sep 05 2007 5:00AM
Subject: Correct mark-up for a form in a table
No previous message | Next message →
I was recently asked to develop a accessible shopping cart for
Wordpress. Currently I'm designing things for a specific use, but I am
hoping that I can further develop it for general release.
Part of the scripts involves being able to change shipping amounts for
various zones, within various classes. Not easy to explain, so I've
created an online example:
http://www.quirm.net/shipping.html
Now obviously I haven't used any <label>'s as yet. But if I add them
it would seriously mess up the layout. I realise they can be
positioned off screen with CSS, but is there an alternative?
Can JAWS navigate the form using the id and headers within the table?
I don't know if JAWS when in form mode allows this or not.
Any help would be appreciated.
Rich Pedley
From: Kathleen Wahlbin
Date: Wed, Sep 05 2007 5:20AM
Subject: Re: Correct mark-up for a form in a table
← Previous message | Next message →
Use the title attribute for the label.
From: Steve Green
Date: Wed, Sep 05 2007 8:30AM
Subject: Re: Correct mark-up for a form in a table
← Previous message | Next message →
Hi Rich,
I have encountered similar matrices of form controls during user testing
with JAWS. The user was extremely proficient (he's a JAWS trainer) but he
was absolutely baffled. He understood how the form worked once I explained
it but he still found it impossible to use and was unable to complete the
task. Without sighted assistance he would have given up within a few
seconds.
In forms mode JAWS only reads the text in links, legends and labels. To
navigate a table like this you would have to start in virtual cursor mode
and use the keyboard shortcuts to read the row and column headings. In each
textbox you would have to go into forms mode to change the data. Then go
back into virtual cursor mode to navigate ot the next field. In theory the
user could remember where they are (and avoid some of this mode switching)
but in practice that tends not to happen when the contents of the table
cells are so similar.
This is one of those cases where the behaviour of the form is obvious to a
sighted user, but a screen reader user has no idea what is going on. If they
are to have any chance, you would need to provide an explanation, but our
experience suggests that even that is unlikely to be successful.
Steve Green
Director
Test Partners Ltd / First Accessibility
www.testpartners.co.uk
www.accessibility.co.uk
From: Rich Pedley
Date: Wed, Sep 05 2007 12:30PM
Subject: Re: Correct mark-up for a form in a table
← Previous message | No next message
On 05/09/2007 15:22, Steve Green wrote:
re: http://www.quirm.net/shipping.html
> I have encountered similar matrices of form controls during user
> testing with JAWS. The user was extremely proficient (he's a JAWS
> trainer) but he was absolutely baffled. He understood how the form
> worked once I explained it but he still found it impossible to use
> and was unable to complete the task. Without sighted assistance he
> would have given up within a few seconds.
Sadly it makes sense. But also gives rise to another table related
question. Does that mean, in my example, that adding the attributes
ids and headers are actually irrelevant? Sounds like they wouldn't be
of use, hence my question.
> In forms mode JAWS only reads the text in links, legends and
> labels. To navigate a table like this you would have to start in
> virtual cursor mode and use the keyboard shortcuts to read the row
> and column headings. In each textbox you would have to go into
> forms mode to change the data. Then go back into virtual cursor
> mode to navigate ot the next field. In theory the user could
> remember where they are (and avoid some of this mode switching) but
> in practice that tends not to happen when the contents of the table
> cells are so similar.
I'll have to add the labels then, and position off screen.
> This is one of those cases where the behaviour of the form is
> obvious to a sighted user, but a screen reader user has no idea
> what is going on. If they are to have any chance, you would need to
> provide an explanation, but our experience suggests that even that
> is unlikely to be successful.
much as I thought it might be. I think trying to explain the table
would become too complicated, and adding in the labels is definitely
the correct way forward.
Thanks for the reply.
Rich