JAWS reads pre-compiled content

[NickHeiner]

Do you want to request a feature or report a bug?
Bug.

What is the current behavior?
JAWS reads the pre-compiled HTML content instead of the compiled HTML content. For instance, if I have the following HTML:

<li ng-repeat="item in items">{{item.name}}</li>

If a new element that looks like {name: 'Barcelona'} is added to items, then JAWS will read "left bracket left bracket item dot name right bracket right bracket".

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via https://plnkr.co or similar.

1. Use JAWS 16 / IE 11 / Windows 7 / Angular 1.5.8.
2. Go to the plunkr or my demo or plunkr using snapshot version of Angular. (They should be equivalent, but I provided them all in case you prefer a plunkr, or in case the plunkr messes with JAWS in some way.)
3. Click the "Add item" button.
4. Listen to what JAWS reads for the newly added element.

What is the expected behavior?
I expect to hear "Widget 1" instead of "left bracket left bracket item dot name right bracket right bracket".

What is the motivation / use case for changing the behavior?
This is the screen-reader equivalent of a raw {{item.name}} string being visible to the end-user.

Which versions of Angular, and which browser / OS are affected by this issue? Did this work in previous versions of Angular? Please also test with the latest stable and snapshot (https://code.angularjs.org/snapshot/) versions.

• JAWS 16
• IE 11
• Windows 7
• Angular 1.5.8 or snapshot as of the time this issue was filed

Other information (e.g. stacktraces, related issues, suggestions how to fix)
Related, but more specific: #11466

I thought that it may work to put aria-hidden="true" on elements until they were compiled. I tried this on my demo page. You can try it for yourself by clicking the "Add initially hidden item" button. On VoiceOver, this does what I would expect, which is read the content after aria-hidden is removed. On JAWS, the content is never read. So this will not work.

Fundamentally, it seems that the problem is that content is being put into the DOM that is not compiled yet, and JAWS is picking it up. We need some way to either defer actually inserting content into the DOM until it's compiled, or tell JAWS that the content is not yet ready to be read.

I'm happy to submit a PR for this, but it seemed sufficiently complicated that it was worth opening an issue to start a discussion first.

Thanks! I'm happy to provide any follow-up information as needed.

[Narretz]

I thought that it may work to put aria-hidden="true" on elements until they were compiled. I tried this on my demo page. You can try it for yourself by clicking the "Add initially hidden item" button. On VoiceOver, this does what I would expect, which is read the content after aria-hidden is removed. On JAWS, the content is never read. So this will not work.

Then this sounds like a JAWS bug, no? Or the aria spec is not clear enough in this case.

@marcysutton Do you know if there's anything we can do about this?

[marcysutton]

I can repro that issue on the Angular Material autocomplete, which uses a similar ng-repeat to announce screen reader messages. I had to edit it to announce anything, as the live demo uses role="status" and aria-live="assertive" -- JAWS and IE 11 have trouble with this combination, but removing role="status" from the Material autocomplete made the above problem start happening.

This definitely seems like a JAWS bug–it's already known to have issues with ARIA live regions, as you can see from my note above. Unfortunately there isn't much you can do aside from compiling content in the virtual DOM before inserting it into a live region. Perhaps you could try rendering content in the live region that doesn't rely on ng-repeat so it doesn't take so long to compile? I'm very curious to hear if someone finds a workaround for this, but I don't know of anything else off the top of my head.

Also this isn't related to the ngAria component–it occurs without that module. @Narretz

[gkalpak]

Fwiw, we don't have a virtual DOM in ng1 😄
While compiling something before inserting it into the DOM might work for other directives, it is not an option for ngRepeat, since it would break directives that require parent directive higher up in the DOM hierarchy.

I am afraid there is not much we can do on the Angular side 😞

[marcysutton]

Yep, I knew ng1 didn't have that option. It works correctly in NVDA in both Firefox and IE11. I don't think there's a bug tracker for JAWS, so I'd consider this one a can't/won't fix.

Correction: there is an email address for Freedom Scientific, so I reported the bug there. It is also reproducible in the public beta for JAWS 18

[NickHeiner]

For anyone else who is looking for a workaround for this, I also tried using ng-bind instead:

<li ng-repeat="item in bindItems" ng-bind="item.name"></li>

This results in JAWS reading nothing. 😦

[gkalpak]

Since this seems to be a JAWS issue and there isn't anything we can do about it in Angular (afaict), I am going to close this.

Thx @NickHeiner, for reporting this, so people facing the same issue can find it here.
Thx @marcysutton for looking into it and reporting it to Freedom Scientific.

If anyone finds a workaround or has an update on the situation or can suggest a fix for Angular, please post below.

[joe-watkins]

@NickHeiner Very interesting,..I was able to get JAWS to read the ng-bind style in your demo using: Win 8.1 - IE11 - JAWS 17.0.2619

Here's a screencast: http://www.screencast.com/t/29s1x3pwg

[NickHeiner]

@joe-watkins I think one of my co-workers reported it working on JAWS 17. Maybe it's a bug in JAWS 17 and a regression in JAWS 18?