feat(mat-form-field): Option to allow MatHint to persist alongside MatError

Feature Description

On every Angular Material project I’ve worked on, our accessibility team has flagged that the mat-hint disappears when mat-error appears. To be accessible, it is required that the mat-hint continues to persist somehow. Currently, the mat-hint element is fully removed from the DOM: https://github.com/angular/components/blob/master/src/material/form-field/form-field.html#L83

This has been brought up on SO several times:

• https://stackoverflow.com/questions/60185384/keep-the-displaying-of-both-error-and-hint-if-error
• https://stackoverflow.com/questions/47166694/angular-material-input-with-hint-text-and-error-text-at-the-same-time

To compensate, on each project we:

1. Write a wrapper component around MatLabel, MatHint, and MatError, as well as MatInput, MatSelect, MatCheckbox, etc, duplicating all of their inputs, or
2. Write a wrapper component around MatLabel, MatHint, and MatError, using content projection for the form controls, which breaks the synchronization between all the elements.

Either way, we spend a lot of time on ugly hacks with which we are always ultimately unsatisfied.

I propose we hide mat-hint with CSS (e.g. display: none) instead of fully removing it from the DOM. This will allow users to easily continue to persist mat-hint as they see fit, simply by overriding the CSS.

(Alternatively, or in addition, we could add e.g. @Input('persistHint') to mat-form-field, but this would require more of a reworking of mat-form-field’s logic, and would also require making some design decisions about how mat-hint should look when displayed alongside errors, for which the Material guidelines don’t give instruction AFAIK.)

[crisbeto]

Sorry for the delay, I missed the meeting last week but we did discuss it this week and we decided to implement the proposal from this issue not as an opt-in feature, but as the default behavior.

[RobertAKARobin]

I agree there are some implementation details to work out. But this always comes up in accessibility testing, and so think it would be prudent to address.