Accessibility: Screenreader semantics and keyboard navigation could use some TLC

[zersiax]

Describe the bug
The various components of the IDE (v2 beta) are ... pretty usable with a screenreader. By that I mean that most elements can be located and interacted with, but not in a user-friendly way.
A lot of elements report as "clickable" elements, which generally indicates a div element has been enhanced with JS to add extra functionality. That element's role (button, link, etc) is missing, which makes screenreader users have to guess if something can and should be clicked or not. They will also not show up when tabbing around the window, which is a pretty common navigation pattern for desktop applications.
More insidious are, for example, the entries in the board manager, that give no indication for a screenreader that clicking the title reveals an install button. This makes it seem like installing boards is not doable with a screenreader.

To Reproduce
Steps to reproduce the behavior:

1. Start a screenreader, I recommend the free, open-source screenreader NVDA. '...'
2. Open the editor and try to tab around. Then, hit insert+space to drop into what's known as "browse mode" and arrow through the window.
3. The save, upload, verify etc. items will report as being clickable, rather than being a button, link or similar.

Expected behavior
These kinds of bugs in a UI slow screenreader users down significantly, and depending on the amount of keyboard shortcuts, it can make keyboard-only users unable to use the IDE at all.
Expected behavior is that the correct semantics are used, so the editor can be efficiently navigated with assistive tech.

Screenshots

N/a
Desktop (please complete the following information):

• OS: [Windows]
• Version: [e.g. 2.0. beta 5]

[per1234]

entries in the board manager, that give no indication for a screenreader that clicking the title reveals an install button

The "INSTALL" button is now always present on all entries in the Boards Manager and Library Manager views: #1568