And I maintain that the forms section of the standard was written with windows and IE in mind.
I agree that that piece is more subjective than other standards, and that Jaws and IE would have been the most common experience that the authors had to draw upon. I do no agree that there is anything in the standards that is unfairly binding to Windows and IE.
Accessible means I can use it with a heavy browser at least.
I have no idea what you mean by heavy. Your previous use of the term accessible has been amorphous.
How would you use forms like this on the phone?
I would expect an auditory phone browser to have a mechanism for navigating data tables.
I know they'd have to be heavily reworked before being sent over the wire.
Well constructed web sites, say WCAG double A compliant, would not have to be worked up much.
It is *safari* and not Voice Over which is at issue here
How can you make that assertion with such conviction? Safari is pretty closely scrutinized by the web standards folks. I have followed some of those conversations and I do not recall handling of data tables nor forms to have been an issue.
though for unlike msaa and bolted on apps, It is a good deal the responsibility of the app to provide the information to the screen reader and
At the very least, it is convenient that the screen reader developer cannot just point a finger at the developer of the operating system without pointing the finger at himself!
Safari does not expose the information to Voice Over
How do you know this? Please provide an authoritative reference.
even if it were prepared to use it. If this were the case, we would be able to use the table commands available in Voice Over with safari.
Again, pure speculation. Wishful thinking maybe.
A form is not a data table it is a layout table
You are wrong. A conservative definition of data table is a table that uses column or row headers to apply to multiple cells. You could be more liberal and allow that it could be be one header cell on just one data cell. A more general test is this: Does the order cells are read change the meaning? If so, it is not just a layout table. Either of these last two definitions clearly applies to form elements in tables. In any case, the original thing I asked for help with is an array of radio buttons in a data table. It is a data table because the intent is for the labels in the top most row and the left most column to both apply to a particular data cell. Correct structural markup has been included to reflect this relationship. The form satisfies the requirements of 508/WCAG, but is really not useable by someone who relies on VoiceOver.
if it is a table at all.
Right, forms do not have to use tables. But I would guess that the majority of them do.
The wild has lots of bad stuff in it.
Agreed. But one cannot just expect to avoid data tables altogether.
I agree that information should not be coded in liniar fashion
Really? Okay, so you agree that data tables can be acceptable.
but there should be ways to code which allow it not to be liniarized and still functional in a liniar way.
Right. That is what I did. I coded it as a correctly marked up data table.
O wonder how .31 would play here?
The functional performance criteria are not applicable because we have the more discrete standards for web content. In any case, the content *can* be used in a none-visual mode, but the assistive technology needs to be sufficiently robust.
Why not come up with a way to code a form which meets the standards and is as accessible as possible to all?
I regret that I am at a loss as to how to prepare data tables in html so that they are compatible with VoiceOver.
