-
Notifications
You must be signed in to change notification settings - Fork 6.8k
fix(datepicker): add role to date range input #19717
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Adds a `group` role to the date range input since it groups two inputs.
d9167dd
to
99784ff
Compare
Bumping to a P2 since it now includes some changes that should improve accessibility even more. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! thanks for making the changes! One small comment
@@ -187,8 +185,6 @@ const _MatDateRangeInputBase: | |||
'(change)': '_onChange()', | |||
'(keydown)': '_onKeydown($event)', | |||
'[attr.id]': '_rangeInput.id', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we need also remove that from here and add the id to the actual range input. In the current state it will announce (for ChromeVox) the label, and then mention edit text group w/ label again.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that associating a label with a non-input element is invalid. Also the idea here was to allow for clicking on the label
to move focus automatically to the start input.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you're right that the label for
would not work for a role="group"
. Might be a general issue in our form-field as we always set the label for
while we support custom controls that don't necessarily use a labelable
element.
The focus for the start input should still work through the form-field onContainerClick
, so that might not be an issue here. I think we should be good with the latest changes, but we might need to revisit this when we think more about how we want to handle the <label for>
attribute in form fields.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@crisbeto we do the same already for the select where label
points to a custom control. That is a noop for screenreaders, but definitely not 100% valid markup. Also the select might not be the best candidate for accessibility comparisons. I'll leave that up to you. I don't feel too strongly about it, but would definitely prefer label not being announced twice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. My previous comment is optional and I'll leave that up to you
Adds a `group` role to the date range input since it groups two inputs.
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Adds a
group
role to the date range input since it groups two inputs.