This is the case on Mac too.

A user reported similar behavior on Windows:

"He streams .m3u and .pls files and wants Chrome to open them directly, rather than download them. So when we pressed enter on a listen link, Chrome and JAWS said absolutely nothing.  But visually, I checked with my assistant, there was the file name, with an arrow to click and a menu to bring up to say always open this file type, which was then accessible once she clicked it, and I could check the box. But the point is, Chrome and JAWS didn’t alert us to that option, it merely said nothing.  It was as if the listen link had been totally ignored by Chrome, audibly that is. Can anyone tell me a quick way to get to those menu options without mouse clicking?"

Response from a tester here:

As a workaround, you can press f6 a few times to reach the file alert. The first button you come to will be to open the file, while the second unlabeled button will activate the context menu where you can access more file options. 

Thanks for the work around.

 

Yes, it works, but is not ideal in terms of accessibility.  It also isn’t documented anywhere that I know of.

 

In fact, if you don’t turn on the Ask To Save a file, then you don’t even know whether a file has started a regular download.  I do wish we could have download percentages announced also, rather than just looking at the folder to see if the file was completed.

 

Thanks.

 

All the best

Steve

 

From: lebe… via monorail [mailto:monorail+v2.1340155778@chromium.org] 
Sent: 22 November 2017 03:32
To: steve@comproom.co.uk
Subject:  Issue 787139  in chromium: A11Y: File downloads are not announced to screen reader users

The question is, would percentages be annoying if they are being announced while you're trying to read something else?

Not really, it’s how other screen readers read IE downloads.  They read the percentage, but it interrupts if you press a key.  If it had a standard progress bar, JAWS would read it.  Not only that, you could turn off the reading of progress bars if you didn’t like it.

 

All the best

 

Steve

 

From: alevent… via monorail [mailto:monorail+v2.482523598@chromium.org] 
Sent: 22 November 2017 17:11
To: steve@comproom.co.uk
Subject:  Issue 787139  in chromium: A11Y: File downloads are not announced to screen reader users

 


Comment #4 on  issue 787139  by aleventhal@chromium.org <mailto:aleventhal@chromium.org> : A11Y: File downloads are not announced to screen reader users
https://bugs.chromium.org/p/chromium/issues/detail?id=787139#c4

The question is, would percentages be annoying if they are being announced while you're trying to read something else?

 Issue 776948  has been merged into this issue.

Hello,

I merged 776948 into this bug because there is more activity here. I transferred the labels/hotlist. Here is the original text from that bug from Oct 20th:

Google Chrome 64.0.3245.0 (Official Build) canary (64-bit) (cohort: 64-Bit)
Windows 10 Enterprise Version 1607 Build 14393.1770
NVDA 2017.3
JAWS 2018.1710.36 private beta 

What steps will reproduce the problem?
(1)Download anything in Chrome 

What is the expected result? Download bar is announced as appearing

What happens instead?
Nothing. However, I can navigate to it using F6.
 

Note from @nektar developer on Nov 27th regarding the experience on Mac, perhaps we can use this when considering the Windows experience while fixing this bug.

Mac behavior: 
1. A toolbar group containing all pending downloads.

2. If you interact with the toolbar you can visit each individual download item. You hear its name, and I think its progress.

3. If you interact with a download item you hear the progress bar clicking 
continuously. You can Pause the download and choose whether to open it automatically once download is complete.

I'm about to upload two CLs for Mac which:

1. Announce "download started" when a download starts.
2. Ask VoiceOver to play a chime when a download changes state (finishes, fails, etc.).

This roughly mirrors what Safari does. It doesn't cover progress (but you can see progress by visiting an individual download in the shelf), and it doesn't cover dangerous downloads. I'm looking for input on how those should be handled, but also curious if these initial changes could use improvement.

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

commit fa8e0afdb9209c2ff0df9d1afc515b81a5de6ea3
Author: Sidney San Martín <sdy@chromium.org>
Date: Thu Jan 04 22:11:17 2018

Have VoiceOver play a sound when a download changes state.

Safari plays a sound when a download fails. This does it for both
success and failure.

Bug:  787139 
Change-Id: If3df9aaed218f8b66fcf124ae8f2529eba87c6f5
Reviewed-on: https://chromium-review.googlesource.com/850743
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: Sidney San Martín <sdy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#527113}
[modify] https://crrev.com/fa8e0afdb9209c2ff0df9d1afc515b81a5de6ea3/chrome/browser/ui/cocoa/download/download_item_controller.mm
[modify] https://crrev.com/fa8e0afdb9209c2ff0df9d1afc515b81a5de6ea3/ui/base/cocoa/a11y_util.h
[modify] https://crrev.com/fa8e0afdb9209c2ff0df9d1afc515b81a5de6ea3/ui/base/cocoa/a11y_util.mm

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

commit c3e6c504c3c88a50338040928b35ca1ec44c6404
Author: Sidney San Martín <sdy@chromium.org>
Date: Thu Jan 04 22:18:15 2018

Have VoiceOver announce new downloads.

Bug:  787139 
Change-Id: I141466b5e8d7b68a91f3a844e07053b6c3720153
Reviewed-on: https://chromium-review.googlesource.com/851193
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: Sidney San Martín <sdy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#527114}
[modify] https://crrev.com/c3e6c504c3c88a50338040928b35ca1ec44c6404/chrome/app/generated_resources.grd
[modify] https://crrev.com/c3e6c504c3c88a50338040928b35ca1ec44c6404/chrome/browser/ui/cocoa/download/download_shelf_controller.mm

Attaching a file so I can see the issue right here.

Deleted: aliens.jpg 38.4 KB

	aliens.jpg 38.4 KB View Download

Did you mean to set the status to ""?

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

commit 0f23553f0e4aca75bb9617b2813ae18b1ba111fa
Author: Aaron Leventhal <aleventhal@chromium.org>
Date: Thu Mar 08 01:16:43 2018

Friendly screen reader download status updates

When a download starts or finishes, notify screen reader users
with a friendly message that contains useful information such
as the size and name of the file to be downloaded.

In addition, for long downloads, provide screen reader update
notifications every 30 seconds, and include the time or % remaining.

Bug:  787139 
Change-Id: I903dd626fddad16504079c69d4e1f3edd88d8052
Reviewed-on: https://chromium-review.googlesource.com/947769
Commit-Queue: Aaron Leventhal <aleventhal@chromium.org>
Reviewed-by: Peter Kasting <pkasting@chromium.org>
Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#541674}
[modify] https://crrev.com/0f23553f0e4aca75bb9617b2813ae18b1ba111fa/chrome/app/generated_resources.grd
[modify] https://crrev.com/0f23553f0e4aca75bb9617b2813ae18b1ba111fa/chrome/browser/ui/views/download/download_item_view.cc
[modify] https://crrev.com/0f23553f0e4aca75bb9617b2813ae18b1ba111fa/chrome/browser/ui/views/download/download_item_view.h
[modify] https://crrev.com/0f23553f0e4aca75bb9617b2813ae18b1ba111fa/chrome/browser/ui/views/download/download_shelf_view.cc
[modify] https://crrev.com/0f23553f0e4aca75bb9617b2813ae18b1ba111fa/chrome/browser/ui/views/download/download_shelf_view.h
[modify] https://crrev.com/0f23553f0e4aca75bb9617b2813ae18b1ba111fa/ui/views/accessibility/view_accessibility.cc