This appears to be related to how headings are hidden/shown and populated on this page. For example, if I inspect the "Today" heading, I find the following HTML:
<h3 id="date">Today</h3>

If I then scroll down and inspect, December 13, 2017, the same HTML is dynamically updated to read:   
<h3 id="date">December 13, 2017</h3>

I noted that each of the date headings on this page do not have their own semantics and are dynamically populated as part of this element:  
<iron-list id="downloads-list" style="overflow: auto;">

I am unable to bisect because I can't have several days of downloads in a bisecting instance of Chrome. If there is a way to fake this to populate the UI, please let me know and I will gladly bisect. I suspect that it will repro on Chrome 55 given that other bugs I've recently found on this page go back that far. 

References for suspicion that this is not a regression due to it being in the UI for a long time: 

Both of these bugs share the same UI as this bug and both of these bugs can repro on 55. 
805284
805781

+ folks on the a11y team for review

leberly@: just generate a profile with a bunch of fake downloads (feel free to visit http://danbeam.org/hacks/randomdl.php to generate a lot, maybe in a loop) and then pass that path to the bisect script

$ bisect_builds.py <flags> -- --user-data-dir=/the/same/dir/every/time/chrome/starts

This page appears to use an infinite scroll which is not compatible with screen readers.
Screen reader users are able to read all information presently in the dom and only if focus moves where the scroll action happens will the dom be updated for these users.
After scrolling down through more than 10 downloads, pressing ctrl+home moves focus to the top of the page, but the scroll element is still scrolled to the last page of downloads.
Thus pressing tab until you reach the file list will not focus on the most recent download, but the top most in the last scrolled to items.

Consider replacing infinit scroll with a 'view more' button

+hcarmona

The infinite scrolling is implemented with the <iron-list> element, and it is used extensively throughout WebUI pages (history, downloads, settings). IIUC, it was made fairly accessible, especially for the cases within chrome://settings.

Not handling ctrl+home sounds like a bug that can be fixed, although the fix might belong in iron-list code itself, at https://github.com/PolymerElements/iron-list.

Read more about the problems with infinite scroll and screen readers here:
https://www.levelaccess.com/infinite-scrolling-impact-on-assistive-technologies-series-1/ Doing a websearch for 'infinite scroll screen reader' returns several articles with even more evidence that this type of control is problematic at best.

There is a difference between the chrome://history page and the list in chrome://downloads.

In history:
Tab to history list, use down arrow to navigate
Tab to action button(s) for that item.

In chrome://downloads:
Each download is accessed via tab key including the action buttons
Arrow keys don't work here.

Home and end as well as first letter navigation don't work on both pages.

This still reproduces with Chrome OS:
Google Chrome	69.0.3497.35 (Official Build) dev (64-bit)
Firmware Version	Google_Lulu.6301.136.57

You can tab through 3 downloads in the list, then the focus jumps up to the Omnibox, then when you keep tabbing it goes to the next three items in the list, etc. 

Re #18: As said earlier in this bug (see #10) this happens because by the time "tab" is pressed there are no other download items rendered in the DOM.

@leberly: Can you clarify what do you think the correct behavior is? Is your original expectation affected by what #12 says at all? Should  this work more like History?

 Issue 870070  has been merged into this issue.

I have a proposed change that will allow using the arrow keys to move between the download entries. Using tab move focus within the download entry until the last component within the download entry has focus. After that, tab will move focus out of the download entry list.

I'm try to figure out how this will work with screenreaders. I'm currently testing with VoiceOver on mac. When VoiceOver is on, it will take control of the focus and ignore the iron-list arrow key handler. It then traverses the items in the order they appear in the dom, which is not the order that they necessarily appear in the list. And when the last or first item in the dom is reached, the screenreader looks like it gets stuck when there are actually more items in the list.

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

commit 10fca8c98946635c38ac6da071b9e764c970a3ca
Author: Esmael El-Moslimany <aee@chromium.org>
Date: Fri Jan 11 04:03:31 2019

Download WebUI: use FocusRowBehavior on download entries to change focus with arrows

Bug: 805779
Change-Id: Iea802f0eb8f2b9e92a38636fc1ff500af20b96b7
Reviewed-on: https://chromium-review.googlesource.com/c/1404487
Reviewed-by: Demetrios Papadopoulos <dpapad@chromium.org>
Commit-Queue: Esmael El-Moslimany <aee@chromium.org>
Cr-Commit-Position: refs/heads/master@{#621900}
[modify] https://crrev.com/10fca8c98946635c38ac6da071b9e764c970a3ca/chrome/browser/resources/md_downloads/BUILD.gn
[modify] https://crrev.com/10fca8c98946635c38ac6da071b9e764c970a3ca/chrome/browser/resources/md_downloads/item.html
[modify] https://crrev.com/10fca8c98946635c38ac6da071b9e764c970a3ca/chrome/browser/resources/md_downloads/item.js
[modify] https://crrev.com/10fca8c98946635c38ac6da071b9e764c970a3ca/chrome/browser/resources/md_downloads/manager.html
[modify] https://crrev.com/10fca8c98946635c38ac6da071b9e764c970a3ca/chrome/browser/resources/md_downloads/manager.js

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

commit 916cb201f2505e465f52d4044d7ca914a0b2b514
Author: Esmael El-Moslimany <aee@chromium.org>
Date: Fri Jan 11 04:09:33 2019

Downloads WebUI: make raised card white bg in light-mode

Bug: 805779
Change-Id: I09c1128665780c6040a36dc4d6caddbc946d6141
Reviewed-on: https://chromium-review.googlesource.com/c/1406300
Commit-Queue: Esmael El-Moslimany <aee@chromium.org>
Reviewed-by: Dan Beam <dbeam@chromium.org>
Cr-Commit-Position: refs/heads/master@{#621901}
[modify] https://crrev.com/916cb201f2505e465f52d4044d7ca914a0b2b514/chrome/browser/resources/md_downloads/item.html

Screenreaders that depend on the DOM for focus and hijack the arrow keys do not work well with iron-list and FocusRowBehavior.