Comment 1 by jteh on 2013-08-23 10:30
This is certainly a valid request, but have you considered using configuration profiles to achieve your use case? I ask this because you specifically mentioned not wanting table coordinates on the web.

Comment 2 by leonarddr on 2013-08-23 10:38
I considered using configuration profiles indeed. That would be an Excel configuration profile with reading on, in that case. However, honestly i've always found it strange that reading cell coordinates for web tables and spreadsheets are pooled in one option instead of a web/document option and a spreadsheet one. Web/document tables and spreadsheet tables are quite different use cases. Their behavior in NVDA is different as well, the first reading before and the second reading after the content. But those are my personal opinions and prefferences, of course. It's not that i really can't deal with the current behavior, i just wanted to share them.

Comment 3 by jteh on 2013-08-23 10:49
The problem with having separate options for web and other tables is that it makes the web a special case. For some, it's a special case, but for others, something else is a special case; e.g. perhaps they think spreadsheets should read coordinates but not word processor documents. So, does that mean we need separate options for the web, spreadsheets, word processor documents, PDF, lists, focusable tables, etc.? That's a lot of options. Personally, I think it's strange that some other screen readers don't read coordinates on the web. Profile triggers are a better fit for all of this.

In any case, this is getting off topic. This request is valid, even if it can be solved a better way for your particular use case. If we do implement this, I think it should probably be implemented with a command that reports other potentially useful information on demand (similar to report formatting), as I think it'd be sad to waste a key to report just one tiny detail.

Comment 4 by leonarddr on 2013-08-23 10:59
I agree on this last matter. Additional useful things announced with this report hotkey could be table row/column headers, for example.

Comment 5 by leonarddr on 2013-08-23 11:00
Changes:
Changed title from "Table hotkey for reading cell coordinates" to "Hotkey for reporting useful table cell info like coordinates"

Comment 6 by grego (in reply to comment description) on 2014-01-31 20:05
Replying to leonarddr:

• Reading cell coordinates after the content instead of before., like the Excel behavior

I agree especially with this suggestion, and many users of NVDA I talked with are confirming, that they are turning table coordinates announcing off, because of annoyance of hearing coordinates before content, which slows down browsing.
Very nice, that in Spreadsheets it was repaired, and now content is read before coordinates, so why keeping this inconsistency in virtual buffers?
In most cases, coordinates are predictable (when I'm in row 1 col 1 and go down, I'll be most probably in row 2 col 1), but content is not predictable, so it seems logical to have content read before coordinates.
It seems a small change, but would make the table reading much easier.

A few thoughts:

• Do we all agree that table cell coordinates should be reported after the content (as is the case in Excel) always or should we have an option to toggle this behaviour? I vote for the former since such a minor behaviour change need not be accompanied by a toggle, that too when the default behaviour provides no significant benefit over the proposed change.
• We now have the Input Gestures dialog in NVDA>Preferences, which contains unbound gestures for all document formatting settings, including reporting of table cell coordinates (which is unassigned by default). Thus, the first pointer of the suggestions provided in the ticket body has been fixed.
• @LeonarddeR If there is nothing else that this ticket encompasses that I am missing, I would like to kindly request morphing this issue to only cover the first point of this comment.