Add suport for objects with custom context menus on websites which use java script

[Adriani90]

Steps to reproduce:

1. Open a web app like SAP BI Portal or any other app which has objects with custom context menus according to this treat https://www.sitepoint.com/building-custom-right-click-context-menu-javascript/

2. Try to expand the context menu with the Keyboard

Expected behavior:

NVDA should provide an user friendly way to expand the custom context menu of relevant objects, if available. An aproach could be to provide speech feedback for such objects. The current aproach should be simplified (lock object Navigation mode, add quick Navigation keys and add optional Setting to restrict object nav for active window) like described in issue #7759.

Actual behavior:

The custom context menu can be expanded by pressing right mouse click but not by pressing context menu key on the key board. Additionally, the user cannot find objects with custom context menu since this object type is not covered in speech feedback. The current aproach is too complicated since I have to find the object by using object navigation and routing the mouse to that object.

System configuration:

NVDA version: All

NVDA Installed or portable: Both

Other information:

Windows version: Win 8.1, Windows 10

Name and version of other software in use when reproducing the issue: Different Browsers, Java

Other questions:

Does the issue still occur after restarting your PC? yes

Have you tried any other versions of NVDA?

[Adriani90]

In my case, I have big issues with this in SAP and in web based Trainings which have Java script elements.

[LeonarddeR]

I belief this is not the responsibility of NVDA or other screen readers, but of either the browser or the application developer, probably the latter.

When I open Google Docs and the focus is in the document area, I can perfectly use the applications key to popup the context menu. So, this indicates that an application author is perfectly able to override the functionality of the browser's context menu.

The thing you seem to request is the possibility to simulate a right mouse click for an object, but this is already possible by means of routing the mouse.

Therefore, I'm leaning towards closing this, but I will give other's the room to comment first.

[PratikP1]

The good thing about JavaScript implementations is that it's highly customizable. The bad thing about JavaScript implementations is that it's highly customizable. In trying to implement the requested feature, the best NVDA could do is guess. However this would most probably slow down the system. NVDA can only work with what's there. It cannot create features that have not been enabled by developers. Developers need to map mouse commands with keyboard equivalents. Due to the different ways that JavaScript could be deployed on each site, I do not believe that this can be technically achieved other than to bind a specific keystroke to combine mouse movement to current object and right-click. Not all movements of the mouse to objects seem to succeed, making this possibility unreliable.

[Adriani90]

Ok I can imagine that it could slow down the System. I am thinking about editing this issue because one part of it could be solved by NVDA, namely to recognize and report which objects have custom context menus. When I am on a Website how can I find such objects? Then I think if a reliable function for Routing the mouse would help. As far as I could manage, when I navigate by object Navigation in Laptop layout I can route the mouse quite reliably by pressing NVDA+shift+m. But Object Navigation is not very intuitive to use yet. Maybe we could Combine this with issue #7759

[LeonarddeR]

@Adriani90 commented on 18 dec. 2017 15:26 CET:

One part of it could be solved by NVDA, namely to recognize and report which objects have custom context menus.

Adapted from this Stack Overflow thread:

data:text/html, <button style="height: 100px; background-color: red;" oncontextmenu="window.alert('test');return false;">Right click here</button>

Adding support for this sounds quite reasonable, but according to your initial message, we can quite easily conclude that the application you used doesn't implement context menus this way.

[Adriani90]

Is it possible to remove the tag "Needs external fix"? I think if we link it with #7759 (i.e. lock object Navigation, restrict for active window and add quick Navigation keys), this issue could be solved or at least the work around with object navigation would be more user friendly.

[LeonarddeR]

The description of your request still points in the direction of needs an external fix. Every workaround provided by NVDA might lower the relevance of the issue, but the major responsibility here still lies by de particular application developers.

[Adriani90]

I have edited the issue accordingly.

[PratikP1]

I'm in agreement with @leonardder here. the variability involved in achieving this can only be accomplished by the web application developer. This is part and parcel of web accessibility. While I'm not arguing that efficiencies should not be achieved when reading the web with screen readers, there should always be distinctions between what is achievable and what will, at best, be extremely difficult. Reliability is an issue with screen reader functions.

[Adriani90]

@PratikP1, In my view, this is well achievable, NVDA has already the functions for supporting this way of interacting with such objects. But the functions have to be improved. It is the wrong way to say a mainstream Software developer should entirely concentrate on one part of functions just because Screen Reader developers find it too difficult to invest a bit more time to improve existing functions. As I experience in every day use cases, Browsers and their elements are being continuously improved. This should be also the case for Screen Readers. And as we have already discussed in #7759, accessibility is not only the responsibility of app developers, but also Screen Reader developers in Terms of improving usability and user experience with different applications.

As far as your Point is concerned, Screen Reader developers should work together with Mainstream developers to achieve better alignments. Is it now my Task as an user to go to every app developer of each affected app and tell him how to improve this?

And on the other Hand, should we really wait for every app developer to do it if we can find a workaround until they do it?

In my case for example, very important Tasks at work are not easily doable. And I think this is also the case of many other users, especially when it Comes to a bit more complex Tasks. I am in learning process for Python and other things. But for me, such challenges are very important. I hope NVDA developers think like this as well.

[feerrenrut]

I think we can all agree that ideally accessibility is considered and tested for during the development of any application (web, desktop or otherwise). When this isn't done well, the implications for those who are required to use these systems at work or educational institution can be awful. If there is someway we can improve these situations for those using NVDA, I think it's worth considering.

Can we go back to the start of this to make sure we understand the problem that is being encountered. @Adriani90 Can you confirm that this request is to:

1. Provide a simpler way to route the mouse to the current object and right click? Where the current process is (with desktop layout) NVDA+numpad / then numpad *
2. Make it easier to find out where a custom context menu is used.

For the first point, I am going to assume that the number of keypresses isn't the problem. Rather, the accuracy of this approach is the problem? For the second point, assuming there was some way that we could detect and report custom context menus, how would this be done. My first inclination is that when moving cursor to an element (or child of one) with a custom context menu, then "custom context menu available" is reported. Also worth considering here is that the problem of knowing when there is a custom context menu also occurs visually. This isn't a reason not to try to make the process easier, but it's worth knowing that more generally custom context menus can be unintuitive.

As mentioned there is some significant doubt that finding the custom context menus can actually be achieved, at the very least more research needs to be done.

[Adriani90]

@feerrenrut, yes I confirm, it is correct.

Von meinem iPhone gesendet

Am 22.12.2017 um 05:41 schrieb Reef Turner notifications@github.com:

I think we can all agree that ideally accessibility is considered and tested for during the development of any application (web, desktop or otherwise). When this isn't done well, the implications for those who are required to use these systems at work or educational institution can be awful. If there is someway we can improve these situations for those using NVDA, I think it's worth considering.

Can we go back to the start of this to make sure we understand the problem that is being encountered. @Adriani90 Can you confirm that this request is to:

Provide a simpler way to route the mouse to the current object and right click? Where the current process is (with desktop layout) NVDA+numpad / then numpad * Make it easier to find out where a custom context menu is used. For the first point, I am going to assume that the number of keypresses isn't the problem. Rather, the accuracy of this approach is the problem? For the second point, assuming there was some way that we could detect and report custom context menus, how would this be done. My first inclination is that when moving cursor to an element (or child of one) with a custom context menu, then "custom context menu available" is reported. Also worth considering here is that the problem of knowing when there is a custom context menu also occurs visually. This isn't a reason not to try to make the process easier, but it's worth knowing that more generally custom context menus can be unintuitive.

As mentioned there is some significant doubt that finding the custom context menus can actually be achieved, at the very least more research needs to be done.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[Adriani90]

I have edited the issue, I think the label can be changed since it does not only depend on external fix.

[Adriani90]

Here is an addon which simulates the right click on an object: http://www.nvda.it/rightclickmenu

This is a first stept in providing an easier approach to handle such objects. Now NVDA must allow following:

1. lock object navigation, like in objpad addon written by @josephsl and
2. Report objects which have custom context menus.

I think this last step will be the hardest one because I think there is no real standard on how such objects have to be tagged.

Comments are appreciated. Thanks.