The CW dropdown seems to only be accessible to sighted mouse users. Suggesting, somehow, we add:
Screenshot

I'm not sure precisely the best pattern to use for this. Perhaps along the lines of aria-controls, aria-expanded, usage of role, and then adding all the keyboard / arrow keys support one would expect in a <select>, because that is basically what we are mimicking?
Maybe this should be in a different ticket, but I also noticed it's quite difficult to tell if the CW button is actually on or not. I made a mockup of what the button could look like when it's on.
clear:

unclear:

Happy to break this out into its own ticket to potentially get this done faster.
The "CW" button seems to work with the keyboard. It's based on a <button> element, so the browser provides the expected keyboard interaction based on the click handler.
It does have problems though:
aria-label attribute provides a completely different label for the button, making it difficult for screen reader users to recognise the "CW" button when it's referenced by other people/help files etc.Suggest using a basic disclosure pattern, inserting the revealed content into the DOM immediately after the button, and changing the label.
<button aria-label="Content Warning (CW)" aria-expanded="true" aria-controls="this">CW</button>
...
<div id="this">
// Where the revealed content goes
</div>
The aria-label is now a more accurate reflection of the visible label. Because the acronym "CW" is included in both the visible and non-visible labels, it means speech recognition users can accurately target the button using voice commands too.
The aria-expanded attribute indicates that content is either collapsed or expanded. It should be set to false initially, then set to true when the button is activated and the content revealed, and then set back to false when the content is collapsed again.
The aria-controls attribute establishes a relationship between the controller (the button), and the content being controlled (the form that appears). It's only supported by one screen reader (Jaws), but it enables screen reader users to move directly from the button to the revealed content using a shortcut provided by the screen reader.
Until such time as more screen readers support aria-controls though, it's necessary to insert the revealed content immediately after the button in the DOM. This ensures that as screen reader users tab away from the "CW" button, they immediately encounter the new content.
I made a PR (#2303) to move the content warning input field below the toot box following issue #2209. Following this issue I made further changes:
I didn't want to go ahead and change the title without further discussion. Right now the title/label has "Hide text behind warning." Since these changes should make it clear to screen-readers what the button is controlling, I'm not sure it's important to change the label at this time.
This does not resolve @wavebeem's comment that it's hard to see when the CW button is active. I agree that would be a worthy UI change to make.
This PR does not resolve OP's issue. @jpdevries's issue was actually with keyboard accessibility for the _privacy_ dropdown, not the CW input. The buttons are tab accessible, but hitting enter does not activate the tab-selected button. These should also be arrow accessible. I believe that would require manually adding key listeners for up, down, and enter. Tab or arrow selecting a privacy dropdown option would also ideally give it the "active" class. I agree that would be an excellent change.
Fixed in #7318, I think
Most helpful comment
Maybe this should be in a different ticket, but I also noticed it's quite difficult to tell if the CW button is actually on or not. I made a mockup of what the button could look like when it's on.
clear:

unclear:

Happy to break this out into its own ticket to potentially get this done faster.