Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NVDA doesn't read selected content in microsoft access #2281

Closed
nvaccessAuto opened this issue Apr 27, 2012 · 15 comments
Closed

NVDA doesn't read selected content in microsoft access #2281

nvaccessAuto opened this issue Apr 27, 2012 · 15 comments
Labels
Abandoned requested reports or updates are missing since more than 1 year, author or users are not available. app/microsoft-office blocked/needs-code-review enhancement

Comments

@nvaccessAuto
Copy link

Reported by ashleycox on 2012-04-27 10:35
When a database table is open in Microsoft access, and shift+right/left/up/down arrows or control+space are used to select columns, NVDA simply announces "grid" and doesn't announce the selected content. Ideally NVDA would read this selection data much like it does in excel.

@nvaccessAuto
Copy link
Author

Comment 1 by jteh on 2012-04-27 11:08
Marking as enhancement, since we don't claim to support Access.

@nvaccessAuto
Copy link
Author

Comment 2 by briang1 on 2012-04-27 11:28
I seem to recall raising some tickets for Access ages ago, and the main problem was tha edit areas were not very easy to read. Indeed some very odd results seem to occur, and this ticket may well be an extension.
I can use my current database just about in Access but the major problem is still the edit fields not being read wnen you use cursors or delete.
Maybe some limited support for databases already created might be possible?

@nvaccessAuto
Copy link
Author

Comment 3 by jhomme (in reply to comment 2) on 2012-04-27 12:09
Replying to briang1:

Hi,
Which version of Access? Thanks.

I seem to recall raising some tickets for Access ages ago, and the main problem was tha edit areas were not very easy to read. Indeed some very odd results seem to occur, and this ticket may well be an extension.

I can use my current database just about in Access but the major problem is still the edit fields not being read wnen you use cursors or delete.

Maybe some limited support for databases already created might be possible?

@nvaccessAuto
Copy link
Author

Comment 4 by briang1 on 2012-04-27 16:25
Runtime of Access 2010 or indeed 2002 does the same also. I don't think that code has changed much across the years in fact.

@nvaccessAuto
Copy link
Author

Comment 5 by nvdakor on 2013-11-12 21:23
Hi,
A more general notes on this problem and a further feature set for Microsoft Access app module can be found in ticket #3643. at the moment, I'm working on this support and related features in table grid.

@nvaccessAuto
Copy link
Author

Comment 6 by nvdakor on 2013-11-13 06:40
Hi,
From what I can gather, NvDA seems to put focus (or seems it does) on the table grid pane when control+SPACE or shift+arrows are pressed. As a first step to solving this, I'm trying to come up with a way to put the focus to the start field (1, 1) and announcing the number of rows selected. If this works and if I can get arrows to work in the custom NVDAObject for OGrid class, then we can test to see if this fixes the issue.

@nvaccessAuto
Copy link
Author

Comment 7 by nvdakor on 2013-11-13 09:48
Hi,
Preliminary tests indicate that control+space works - told the app module to send the gesture and announce that all rows were selected. However, this does not solve the user experience problem:

  • If the user is located at the row other than the top, focus moves to the first row as expected.
  • If one is on row 1, focus moves to the grid table object.
    One way to solve the second issue is to do:
  • Move the search object to focus.simpleFirstChild.simpleFirstChild.
  • Next, move to the first row, then probe this row (via a for loop) looking for a column with selected state, and if so, set focus there.
    A really great shortcut is to memorize the first row/first column cell when the app module loads, set the search object to this cell (when control+space is pressed) and probe its siblings to see if the obj itself or a possible next sibling with selected state is found. Once found, the focus would be set there. This pseudo-focus object would be consulted to find out the selection range.
    As for shift+arrow keys: in navigation mode (moving between cells), if one presses these, focus moves to the grid object. In this case, we need to keep the cur focus object handy, then ask inputCore.InputGesture what the gesture was and act according to the following rules:
  • If left or right arrow was pressed: if we're focused on the first or last column, move the focus to the next cousin - that is, select the next or previous row (right arrow and left arrow, respectively) row, then move it to the first or last column. Otherwise set the focus object to the simpleNext/simplePrevious object.
  • If up or down arrow is pressed: move to the next column cousin - that is, remember the column position, then move to the next/previous row then jump to the correct column child.
    This will require at least four utility functions, namely selectColumnDown, selectColumnUp, selectNextFirstColumn and selectPreviousLastColumn, with each method returning an obj so the focus object can be set to the returned object.
    As for announcing selection ranges: we could do a linear selected state probing where one can move down the rows and see which columns have selected flag, then return the first and last selected row/column combinations. This helps with formatting the announcement message, which may include the data of the starting and ending selection columns.
    Just my observations and ideas (by the way, NVDA crashes Access 2013, a separate ticket). Comments are appreciated.

@nvaccessAuto
Copy link
Author

Comment 8 by nvdakor on 2013-11-13 09:53
Hi,
Come to think of it, a really handy solution is to treat Access database tables just like Excel spreadsheets and apply similar principles, thereby lessening the burden on app module developers (and if that would be the case, I'd be happy to submit the current state of the app module to you so you can work on it further).

@nvaccessAuto
Copy link
Author

Comment 9 by nvdakor on 2013-11-14 03:50
Hi,
Preliminary fix (at least to announce next selected cell):

@nvaccessAuto
Copy link
Author

Comment 10 by jteh (in reply to comment 9) on 2013-11-14 05:01
Replying to nvdakor:

P.S. I think we should move the code to NvDAObjects/window or NvDAObjects/IAccessible modules instead of app modules...

It should only be moved there if it will be used in more than one application. We figured it might be possible for Excel and Word controls to appear in other applications, but I suspect (but am not certain) that this isn't the case for Access.

@nvaccessAuto
Copy link
Author

Comment 11 by nvdakor on 2013-11-14 10:30
Hi,
A fix for this ticket (as part of the Access app module) is now available for code review:

@bhavyashah
Copy link

On the basis of #2281 (comment), could the NeedsCodeReview label please be added to this ticket? @josephsl @ehollig

@Adriani90
Copy link
Collaborator

@josephsl I know this is a quite old one, but do you still have the code for fixes available? Could you raise a PR for this? Or is it nor relevant anymore?

@Brian1Gaff
Copy link

Brian1Gaff commented Aug 8, 2019 via email

@Adriani90 Adriani90 added the Abandoned requested reports or updates are missing since more than 1 year, author or users are not available. label May 2, 2020
@Adriani90
Copy link
Collaborator

No meaningful updates during the last 7 years, closing as abandoned.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Abandoned requested reports or updates are missing since more than 1 year, author or users are not available. app/microsoft-office blocked/needs-code-review enhancement
Projects
None yet
Development

No branches or pull requests

5 participants