Hey, there.
Well, i would avoid direct references between dependant classes (f.e. widgets and playercontroller). Instead of them i use Interfaces or Event Dispatcher.
“…never access…” of course there is always some dependencies between classes so the answer is: “not directly” OR “it depends on…”.
Im currently working on a tutorial for UMG to show how i do things. But i can provide you with a simple structure picture i made.
But im blubbering around.
Consider this:
This is the structure i work with. But as you can see there are also circular dependencies in there. In order to avoid them, i implemented a third instance which breaks this direct circular dependency.
I consider the PlayerController itself to be the one who handles Input. For me a Character/Pawn/Widget are only bunches of data which reacts to something the PlayerController says or if they are affected by something (OnClickButton in a widget, damagetaking in a character) send a message that the Controller has to do something. F.e. if the character takes damage its health is reduced, and you have a health bar widget which represents your Health, this needs to be updated. Go and tell PlayerController that, so he can update the widget.
My intention was: Do a widget really needs to know about character? No, it only wants to have values to update its content. The playercontroller has references to both widget and character, so he can act like a router, getting the HealthRatio from the Character and send a call event within the Widget to update it.
The HUD do nothing in my case just drawing. If press a key to open a menu, means the input to “open” is handled by PlayerController, he knows the widget and sets the visibility.
I hope this helps you a little bit 
Maybe i will upload the first video today on Youtube.
best regards