Reflected XSS is possible if the parameter is part of the URL (usually in the query string) or part of the message body in a POST request.
Parameters in headers or cookies cannot usually be used in a reflected XSS attack because there is no way for an attacker to set these headers (custom headers cannot be sent cross-domain without the use of CORS).
They don't always require a click from the victim on the infected URL directly. Say if a website the user usually visits was compromised, the attacker may add
<form method="post" action="https://example.com/submit">
<input type="hidden" name="textarea1" value="<input onclick=alert(document.cookie)>" />
</form>
<script>
document.forms[0].submit();
</script>
to the HTML (watering hole attack).
Note that if a web page is vulnerable to a POST body reflected XSS attack, then this can also be mitigated via anti-CSRF protections instead of proper HTML output encoding (although in the spirit of defense in depth I would also recommend fixing the actual XSS vulnerability because there might be other attack vectors which could exploit this).