0

The context is that we want to track user behavior of application for it's different features.

For this we have created a custom angular directive say myFunctionality and wrapped portions of HTML into this directive like this, so that now we can track all click events within this, and categorize them by functionality-name to track the usage of a particular feature -

<myFunctionality functionality-name="Login">
 <!--HTML of this functionality-->
</myFunctionality>

<myFunctionality functionality-name="RegisterUser">
 <!--HTML of this functionality-->
</myFunctionality>

Within this directive, we have attached event handler to capture click event and log accordingly.

.directive('myFeature', [function() {
    return {
        restrict: 'E',
        link: function(scope, element, attrs) {

            //more code

            element.on('click.myFeature', '*:not(select, :radio, :checkbox)', function(event) {
                logEventDetails(event);
            });

            //more code

        }])

This is working, beautifully, except that when I read my page using NVDA screen reader. NVDA reads the heading elements as clickable. For example for this heading -

<h1> Test Heading </h1>

NVDA reads:

Test Heading heading clickable level 1

I have also tried using something like this, (with variety of versions) but it did not worked-

$(':header').off('click.myFeature');

TL;DR

Consider the following sample HTML. Here click is associated with div and not with h1. But screen reader works such that it reads heading element also as clickable.

<html>
<body>
    <div onclick="alert('Hello from Div!')">
        <h1>Test Heading</h1>
    </div>
</body>
</html>

How can prevent NVDA from reading non-clickable events as clickable?

Yogi
  • 9,174
  • 2
  • 46
  • 61

1 Answers1

1
<div onclick="alert('Hello from Div!')">
    <h1>Test Heading</h1>
</div>

How can prevent NVDA from reading non-clickable events as clickable?

Your heading is clickable, because it's inside a clickable element.

Just put it outside any clickable element.

Adam
  • 17,838
  • 32
  • 54
  • Thanks for you reply, yeah, I think this is how it works, and we have little control over it. I was anticipating it to be read as non-clickable, when click is there in parent element :(. For application design, we are not able to change the positioning of controls. – Yogi Feb 10 '17 at 03:51
  • I've encountered the same issue on a project that uses Adobe Dynamic Tag Management (DTM), which dynamically tags various elements with `onlick` for analytics, and can also attest that if you put `tabindex="-1"` on a _semantic tag_, you will also hear NVDA announce "clickable". You can [read a discussion about this on the NVDA issues](https://github.com/nvaccess/nvda/issues/5481#issuecomment-241574110), which one of the main developers explains the behavior. I also have an opened issue with NVDA at https://github.com/nvaccess/nvda/issues/6639 – Michel Hébert Feb 25 '17 at 20:44