Yes, dealing with large complex tables can be the most time consuming and frustrating PDF accessibility chore. First question - are these data tables or layout tables? Many forms are organized visually using layout tables, but do not really present data organized in rows and columns. Tagging this content as a table would run afoul of Matterhorn Protocol failure condition 15-004, "Content is tagged as a table for information that is not organized in rows and columns". Instead, working in the Tags pane, drag all the content elements out of the table structure and re-tag/arrange as needed. The PDF/UA Reference Suite has an example form (document 10) that you can refer to - although its layout tables are relatively small. A simple, strait-forward structure should be easier to remediate than a large table, and also easier for an assistive technology user to read.
On the other hand, if these are legitimate data tables... I find the Reading Order pane to be worse than useless. The Tags pane defines the reading order for assistive technology. One trick that I find helpful is to break up a large, complex table into manageable chunks, remediate the sub-tables then recombine. You might also consider evaluating NetCentric CommonLook - I do not use it but it has a good reputation for working with tables. I do not believe it is available for Mac though.
Thank you aCStudent - I was thinking I wouldn't even get any responses to this because I just don't think enough people are using the Accessibility Tools, but where I'm at we'll be using them a lot. I thought a lot about the issue last night and two things occurred to me:
1) Perhaps the table editor never was accessible to me because of the interactive form fields were all throughout the page/table. (I'll try to get a screen shot of the doc to show, but basically in most all of the data cells there was a radio btn or ckbx.)
But I was told at work that we are not ready at this stage to have all the data gathered to get dumped into a DB electronically yet, and a validly 'accessible' alternate version of the form did exist elsewhere for our users, so not to spend more time than needed on this. (This one was intended to just become interactive, with clear/save/print buttons, allowing the average sighted user to tab through in a logical order with some auto-tabbing fields, etc.—which it now does—and it IS recognized as a tagged document with form field tooltips serving, I believe, as alt tags would for an image.) But I thought that if I continue to try this at home, I'd be curious if clearing the form of all structure, it might then allow me to see/use the table editor, create it by hand, THEN perhaps create interactive form fields/btns/boxes into the established data cells?? Want to try it . . .
2) When I thought about being completely unable to use the table editor, I started to think less visually and realized I was hanging on to that concept as a sighted person because all the form fields physically being organized into the rows/columns of a large table. If the radio buttons and check boxes were all clearly labeled and tooltipped per above reference, what the heck would it matter to a non-sighted person whether the radio button options were in a row, column or scattered all over the page (as long as they were grouped). The tab order was correct, so I'm assuming if the reading order followed that, that's all that mattered . . . not the fact that proper <TABLE><TR><TH> terms were there. Does that make sense?
here's an empty/less-detailed version of the form to give you an idea of what I was trying to work with. The table would've posed some issues with headers as you run down the columns as well—which I could take care of if radio buttons were all converted to checkboxes and given different output values in order to allow for only one checkbox per group . . . thinking out loud . . . I'm open to any other ideas.