It's already been said that other browsers have trouble with the construct.
I must have missed that. I know of no browsers that have trouble with data tables. Screen readers vary in their facility to handle data tables. I find little comfort in the revelation that that VoiceOver is not the only screen reader that does not allow two axis exploration of data tables.
Safari needs to pass the info on to VO as other apps can and do.
At least we agree that there is a defect and that Apple is responsible for fixing it. You have offered no explanation and no evidence that the defect is with Safari and not VoiceOver.
A data table is a structured data set. A form is an interactive mechanism. Thus, putting a form in a table is for visual purposes.
Your logic is not of a valid form. The conclusion does not follow from the premises. Roses are red. Violets are blues. Therefore violets do not smell as good as roses. Tables are often used in HTML for layout. Sometimes tables are used to layout forms elements. But the survey form I supplied clearly is dependent upon the structural relationships implied by the table. It is a data table. To assert that this example is just for visual purposes is not credible.
My only solution for your set of radio buttons is to either make certain they are labeled in such a way as to allow a VO user to find the labels easily with normal nav or to change them to dropdowns.
Off list, someone else suggested that I use combo boxes. That is changing the question. It is extremely narrow minded, and contrary to one of the fundamental principles of accessible design, to rework a preferred construct because of defects with the user agents. The array of radio buttons could be changed to a series of questions, each with five responses too. That is not accessible design. That is designing to compensate for a broken user agent.
As there are so few for each group, counting in this instance is not a huge issue unless you cary a heavy load or get lost easily or loose your place or your attention is drawn away momentarily.
Agreed, but I am trying to develop a general technique. The technique has as a prerequisite, a screen reader that can navigate data tables in a browser. I believe that adding a title attribute (which is useless for both WindowEyes and VoiceOver) to form elements in a data table is actually counter productive in some circumstances. I don't think it is a serious defect that VoiceOver ignores title, but it sure would be nice if could expose that information on demand. I regard it to be a serious defect that VoiceOver does not provide a mechanism to navigate down a column in an html data table. I think I would put this right up there with VoiceOver not jumping its focus to intra-document anchors. Or do you want to argue that this is a Safari problem too?
