The problem
There is currently a way to pass in text to a label slot, however it is not a requirement to do so. Without this text, the form input may not have a valid accessible name (accName) and cause failures of WCAG success criteria.
The solution
Require valid content to be passed into the label slot when using these specific Pharos form input components. We already have the ability to pass in a hideLabel attribute that will visually hide a label but is still used in the calculation of the accName for users of assistive tech. This new solution would ensure that consumers who use Pharos form fields don't accidentally produce inaccessible experiences.
Alternatives considered
A known possible example of a form field that doesn't require a label is within a table (and then can rely on the programmatic association of column and/or row headers.
Additional information
This would be a breaking change and we could try to roll out in stages with warnings as was done during the rollout of the a11y- naming convention.
The problem
There is currently a way to pass in text to a
labelslot, however it is not a requirement to do so. Without this text, the form input may not have a valid accessible name (accName) and cause failures of WCAG success criteria.The solution
Require valid content to be passed into the label slot when using these specific Pharos form input components. We already have the ability to pass in a
hideLabelattribute that will visually hide a label but is still used in the calculation of the accName for users of assistive tech. This new solution would ensure that consumers who use Pharos form fields don't accidentally produce inaccessible experiences.Alternatives considered
A known possible example of a form field that doesn't require a label is within a table (and then can rely on the programmatic association of column and/or row headers.
Additional information
This would be a breaking change and we could try to roll out in stages with warnings as was done during the rollout of the
a11y-naming convention.