This behavior is also shown in crbug.com/794059 which is an internal bug. 

Identified two issues by comparing Chrome's dialogs with the Windows' Run dialog via the Inspect tool. The first is important; the second not.
1. Dialog controls don't have SYSTEM_ROLE_WINDOW.
2. Dialog title doesn't have SYSTEM_ROLE_TITLEBAR.
Resolution:
1. It's my opinion that we should not change the role for dialog controls. VFO will make a change in their software to work with controls that don't have the window role.
2. I am preparing a patch for the titlebar role.

Jaws has implemented the required change and I uploaded a patch for titlebar role.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/50804eb171abd97672468d273683f160cb78c7e2

commit 50804eb171abd97672468d273683f160cb78c7e2
Author: Nektarios Paisios <nektar@chromium.org>
Date: Wed Feb 14 14:59:14 2018

Added an accessibility  role of titlebar to labels that are used as window titles

Makes our implementation more similar to native dialogs on Windows, like the Run dialog.

R=dmazzoni@chromium.org, sadrul@chromium.org

Bug:  779297 
Change-Id: Idde84c1664f4cc7af43b6470825ff4cdc3ddd475
Tested: Using Inspect tool from the Windows SDK
Reviewed-on: https://chromium-review.googlesource.com/902842
Reviewed-by: Trent Apted <tapted@chromium.org>
Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
Reviewed-by: Nektarios Paisios <nektar@chromium.org>
Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org>
Commit-Queue: Nektarios Paisios <nektar@chromium.org>
Cr-Commit-Position: refs/heads/master@{#536715}
[modify] https://crrev.com/50804eb171abd97672468d273683f160cb78c7e2/ui/accessibility/platform/ax_platform_node_mac.mm
[modify] https://crrev.com/50804eb171abd97672468d273683f160cb78c7e2/ui/accessibility/platform/ax_platform_node_win.cc
[modify] https://crrev.com/50804eb171abd97672468d273683f160cb78c7e2/ui/views/controls/label.cc
[modify] https://crrev.com/50804eb171abd97672468d273683f160cb78c7e2/ui/views/widget/native_widget_mac_accessibility_unittest.mm

Please wait until next month's Jaws update before verifying this as a fix is required on Jaws' side.

The NextAction date has arrived: 2018-03-14

Both NVDA 2018.1 and JAWS 2018 do not read the full text of the dialog
NVDA and JAWS say with insert+b: Use your MIDI devices
NVDA automatically announces: Use your MIDI devices
JAWS automatically announces: permission.site has a permission request.
Full text of the dialog: permission.site wants to Use your MIDI devices

In browse mode both screen readers read the title followed by site name followed by wants to followed by close button
then the permission on the next line
permission.site wants to connectpermission.site wants to connectClose
 Table with 0 rows and 0 columns
Turn on Bluetooth to allow pairingTurn on Bluetooth to allow pairing to allow pairingLearn moreConnectConnectCancelCancel

There are a few different issues each one being sufficiently small and not important enough to warrant the pri1 label.
1. The version of Jaws that we should be testing with came out yesterday March 15. In the release notes it mentions something about fixing dialog announcements.
2. The text of the dialog in Browse Mode is misleading. It turns out there is both a dialog name and a title. The dialog name says "Site ... has a permissions request" whilst the title bar says "Site ... wants to".
NVDA actually works fine because it reads the dialog name or title.
3. When the dialog opens, none of the buttons are not focused, hence the first button is not announced. We can't change this without changing the intent of the author of the dialog which I assume was that the user should choose without anything being pre-selected.
Surely, we could improve this experience but it shouldn't be pri1 in my opinion because there is nothing blocking and the user can easily figure out what is going on by pressing Insert+B.

Google Chrome 66.0.3359.27 (Official Build) dev (64-bit) (cohort: PGO)
Windows 10 Enterprise Version 1607
JAWS 2018.1803.38 64-bit English (released March 15th)
NVDA 2018.1 

Fixed by external vendor. 

I have verified that this is working as intended with these steps:

# Launch JAWS
# Go to https://permission.site
# Prompt for any permission (I used location).
# Check that content is read upon loading dialog. 
# Used Insert + b to re-read contents

Repeat with NVDA 2018.1

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/dd19640f93eb1a82a0f2cba3d6231f307e0faef4

commit dd19640f93eb1a82a0f2cba3d6231f307e0faef4
Author: Nektarios Paisios <nektar@chromium.org>
Date: Thu Mar 29 18:46:34 2018

Views: Modified all bubbles to have an alert dialog role and deleted accessible name

This small patch fixes a few related bugs.
1. Assigned an alert dialog role for all bubbles.
An alert dialog role makes the contents of a dialog be announced by a screen reader when the dialog appears.
Bubbles are non-modal and thus should be announced as soon as they appear because otherwise the user will not know if they are there.
However, some Windows screen readers do not yet properly support the alert dialog role.
For Windows only, we can switch to the system alert role temporarily until screen reader vendors provide a fix.
2. ARIA Spec compliant?
The ARIA Spec dictates that an alert dialog role should only be used for modal dialogs.
However, there is no other spec-compliant way to announce the contents of a dialog.
3. Deleted accessible name from any dialogs.
The ARIA Spec also dictates that alert dialogs should have an accessible name.
However, this patch modifies Views. In Views all dialogs have a title bar.
Having both an accessible name and a title bar makes Windows screen readers announce the title twice.
4. Applied to all bubbles by default.
Since most bubbles are non-modal and need to be announced as soon as they appear, alert dialog should become the default role.
Subclasses can override if needed and switch back to a dialog role.
Having a role of dialog doesn't announce anything on Windows when the dialog is non-modal.

R=dtseng@chromium.org, aleventhal@chromium.org

Bug:  775705 ,  779297 ,  474622 
Change-Id: I062110757cd4c400b31aa3cb89c622002699408e
Tested: Jaws and NVDA with permission, password save and zoom bubbles.
Reviewed-on: https://chromium-review.googlesource.com/967465
Commit-Queue: Nektarios Paisios <nektar@chromium.org>
Reviewed-by: Ben Wells <benwells@chromium.org>
Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
Reviewed-by: Michael Wasserman <msw@chromium.org>
Cr-Commit-Position: refs/heads/master@{#546891}
[modify] https://crrev.com/dd19640f93eb1a82a0f2cba3d6231f307e0faef4/chrome/app/generated_resources.grd
[modify] https://crrev.com/dd19640f93eb1a82a0f2cba3d6231f307e0faef4/chrome/browser/ui/views/conflicting_module_view_win.cc
[modify] https://crrev.com/dd19640f93eb1a82a0f2cba3d6231f307e0faef4/chrome/browser/ui/views/conflicting_module_view_win.h
[modify] https://crrev.com/dd19640f93eb1a82a0f2cba3d6231f307e0faef4/chrome/browser/ui/views/extensions/extension_message_bubble_view_browsertest.cc
[modify] https://crrev.com/dd19640f93eb1a82a0f2cba3d6231f307e0faef4/chrome/browser/ui/views/permission_bubble/permission_prompt_impl.cc
[modify] https://crrev.com/dd19640f93eb1a82a0f2cba3d6231f307e0faef4/content/browser/accessibility/dump_accessibility_tree_browsertest.cc
[modify] https://crrev.com/dd19640f93eb1a82a0f2cba3d6231f307e0faef4/ui/accessibility/platform/ax_platform_node_win.cc
[modify] https://crrev.com/dd19640f93eb1a82a0f2cba3d6231f307e0faef4/ui/views/bubble/bubble_dialog_delegate.cc
[modify] https://crrev.com/dd19640f93eb1a82a0f2cba3d6231f307e0faef4/ui/views/bubble/bubble_dialog_delegate.h
[modify] https://crrev.com/dd19640f93eb1a82a0f2cba3d6231f307e0faef4/ui/views/bubble/tray_bubble_view.cc
[modify] https://crrev.com/dd19640f93eb1a82a0f2cba3d6231f307e0faef4/ui/views/bubble/tray_bubble_view.h

Above patch fixes the inconsistency between the title announced by JawsKey+T or NVDAKey+T and the title bar that can be read when using Jaws' virtual cursor or NVDA's Browse Mode.