duplicate to issue 102033

*** This issue has been marked as a duplicate of 102033 ***

closing

This issue has not been resolved and is not a duplicate.

Then you should perhaps explain why it is not duplicate. "Rows in ListBoxes not
accessible" and therefore not read by voiceover (issue 102033) and your
description "All tables are reported to be blank by voiceover" sure sounds
duplicate to me.

As a side remark: setting the target milestone to a released version does not
make sense.

First of all, issue 102033 says nothing about the help system in open office 3.1.  I clearly said in my 
initial description that I am having problems navigating the help-system with VoiceOver.

Secondly, I did not say I am having problems reading tables in general.  I am specifically referring to 
the ones found in the help system.  In particular, the one containing keyboard short cuts on the Writer 
help page.

Thirdly, issue 102033 mentioned lists.  I saw nothing about tables.
Fourthly, I know nothing about the milestone field nor do I understand what it means.  This page is not 
very speach friendly.   I think that my information is correct enough that you could be a little more 
helpful.

Thanks.
.

Sorry, but just that you call lists tables does not make a real difference IMHO.
The only "table" I see in the writer help is that on the left side in the index
tab page. That is a ComboBox and indeed its entries do not get read by voiceover
- just as described in issue 102033.

Here's what I did:
- open writer
- open help
- enter "shortcut" and hit enter to go the help about writer shortcuts
-> the index ComboBox does not get read by voice over

If that is the problem you meant, then it is duplicate. If that is not your
problem, then please describe what your problem actually is.

Again, I am not talking about combo boxes or lists although I hope that gets fixed soon.  I am talking 
about tables.  That is a different structure.  Insert menu, table.

1.  I open Writer.
2.  I open help from the help menu.
3.  I move VO to the horizontal and interact with VO-down.  For some reason, Vo is stuck and can't go 
anywhere so I hit tab which I believe moves keyboard focus to the navigation pain.
4.  I stop interacting with VO-up.  Now I'm able to read the toolbar and other buttons.
5.  I move VO to the scroll area and interact with VO-down.
6.  I scroll down with the VO cursor to keyboard.  I know that keyboard focus is fallowing because I hear 
the little clicks.
7.  I just hit enter and go to the keyboard help page.
8.  I read the page with VO and come to the table containing the keys and their affects.  Table appears 
empty to VO.
9.  I open print and use Preview to view the information because I can't read it in the actual page.

I want to say again that I am able to read and edit tables I insert my self in a document.  This seems to 
only be happening in the help pages.

I also want to reiterate that issue 102033 did not mention tables nor did it mention the help system.

I'm reassigning to pl.  Not sure if I'm suposed to do that or not but I'm doing in just in case.
Thanks.
 

That detailed escription helped a lot, thanks. I simply did not understand what
you really were talking about. And of course you are right, this is a
significant accessibility problem and different form the listbox/combobox problem.

Let me rephrase just to make sure I understand you now: the problem with the
help is that the actual help text is not accessible, because there is no way to
move the focus to it other than clicking into it with the mouse. Whether you
move the focus with voiceover or pressing tab, it never quite reaches the help
window.

BTW: there is and additional toolbar in there that you can set the focus to with
F6. When you hide the pane on the left that shows the index and press F6 again,
focus enters the actual help text. This is of course not acceptable; also even
when you travel in there with the focus not everything gets read. 

add accessibility keyword

I am able to read most of the help text with the VO cursor although getting there is a problem.  I am not 
able to read help text when it is in a table.
Thanks.

pl->mav: as discussed, please solve the focus navigation problem (which is cross
platform, setting platform to "All"). I don't know if the rest of the
accessibilty problems of the help docuement is also you task; it may be
necessary to split off some more issues for them to the writer team.

Changed issue title to reflect the VO issue, platform MAC

For the focus "problem": Works for me: There are 3 areas: Navigation, tool bar
and content area. Each area can be reached via F6.
You simply don't see it when the focus is in the content area because there is
no cursor. Pressing Tab for getting to the next hyper link, as well as
key/up/down for scrolling, works fine for me.

mt->pl: As discussed, I don't think it's a Writer (-Web) issue, otherwise it
would already have been reported by the Orca team. 
Do you have a chance to look at the MAC specific part (UAA/NSAccessibility bridge)?

mt: the "focur problem" specificaly was, that nothing gets read until you press
F6 often enough to move the focus to the content. This seems less than optimal.

However if we don't want to improve that I'll have another look at the writer
tables.

This is starting to look bad. Tables are not really accessible at all on MacOSX;
the only reason that cell contents get read in writer is that the focus moves
into the cell directly. Switch the document to read only (like in the online
help) and the only thing getting read is "empty table".

The reason for this is that the accessible table implementation on the mac does
not support the row and column attributes; and the reason for that is as far as
I can see is calc which has always 65536 rows and 1024 columns in a table.

Alas, the Mac accessibility attributes for columns and rows are an array of
child objects for each row/column. This immediately brings us into a memory
issue in calc, especially since listeners will be added to each of these.

The better alternative would be to make our tables into a "grid view" on the mac
side; alas that was only invented in MacOSX 10.5, which is later than our
baseline of 10.4.

I think this will need more implementation.

Experimenting with the "grid" did not help much; the grid also needs to return
all its children in one big array; plus VoiceOver will read "Grid" instead of
"Table" of course. So I'm back to "Table" and reporting children now only up to
a maxmimum number of accessible children. This is not really desirable, but I
don't see another way here.

For unkown reasons, VO never asks the cells of a table for attributes; it will
just ask for the table's rows but not anything else. I don't know why.

You can travel the table's cells with Option->Arrow keys, so at least one has a
method to get the individual cell contents read, but that's not really a
solution. Sorry, at the moment I don't know how to fix this.

Reset assignee on issues not touched by assignee in more than 2000 days.