-
Notifications
You must be signed in to change notification settings - Fork 80
feat(input-date-picker): allow toggling date picker by clicking the input or entering the down/escape key #6805
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
feat(input-date-picker): allow toggling date picker by clicking the input or entering the down/escape key #6805
Conversation
…nput or entering the down key
+@geospatialem in case additional screen reader testing is needed. |
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.
The id
might need to be unique when more than one date-picker
is present in an app?
There's also a bunch of random numbers read back in both NVDA and JAWS, not sure where they are being read from?
JAWS transcript when pressing the ⬇️ key to show the date-picker
component, and changing the date from 3/7/2023 to 3/8/2023 :
Calcite Input Date Picker
Input Date Picker Label �edit combo�
3/7/2023
To set the value use the Arrow keys or type the value.
1
26
25
27
19
5
10
8
9
16
17
14
12
4
3
22
24
13
15
2
1
28
26
29
Choose date
March 2023
Previous month �Button�
To activate press Enter.
Year �Edit�
2023
Type in text.
Calcite Input Date Picker
Next month
�Button�
To activate press Enter.
table
Column 3, Row 3
�Grid�
Tuesday, March 7, 2023 �Button�
Tu
column 2 row 2
To activate press Enter.
Wednesday, March 8, 2023 �Button�
We
To activate press Enter.
Calcite Input Date Picker
aria-modal="true" | ||
class={{ | ||
[CSS.menu]: true, | ||
[CSS.menuActive]: this.open | ||
}} | ||
id="date-picker-dialog" |
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 if multiple dialogs are present on the page it's causing some confusion with screen readers.
Can this id
be more unique generating a guid from the guid utils, associated with the name, similar to combobox
?
NVDA picks up collapse, but JAWS isn't providing context. 😢
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.
Yeah these should probably be unique since we don't know how screen readers will deal with shadowRoot.
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.
And here I was, thinking shadow DOM would make this easier. 🥲
Serious talk, thanks for pointing this out. I'll fix this right away. Can we add this to our a11y guidelines?
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.
Code looks good to me 👍
Just have questions on the role setting.
@@ -1164,6 +1169,7 @@ export class Input | |||
value={this.value} | |||
// eslint-disable-next-line react/jsx-sort-props | |||
ref={this.setChildElRef} | |||
{...this.globalAttributes} |
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.
@jcfranco can you elaborate on this one?
If a user sets a role on the host element, the same role will be set internally on this shadowRoot element?
Won't the nested roles conflict with each other? I'm not 100% on how screen readers read shadowRoot but it seems like a parent and a shadow child having the same role might be problematic?
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.
Also, if a user sets lang on the host it will be set on this element. That's not a problem but just seems redundant/not necessary.
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 overriding the internal input's role is necessary to be able to implement the combobox patterns from the ARIA Authoring Practices Guide:
Role Attribute Element Usage combobox input Identifies the input element as a combobox.
Role Attribute Element Usage combobox input[type="text"] Identifies the input element as a combobox.
Otherwise, the host will have one role and the actual input will have another one which might interfere with the screen reader interpretation. In my testing, VO reads and offers different options before and after making this change (compared to the example from https://www.w3.org/WAI/ARIA/apg/patterns/combobox/examples/combobox-datepicker). I'll defer to @geospatialem on this one.
Also, if a user sets lang on the host it will be set on this element. That's not a problem but just seems redundant/not necessary.
The util is configured to only watch role
in this component (see https://github.com/Esri/calcite-components/pull/6805/files#diff-fe3d603d6390f87fdcdd3f40e34778ccdb07ff9edc52e440ad13c9571cfceadaR475 above).
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.
Agreed on the combobox role here. We did some testing with the light and shadow DOM to be sure, and both should be interpreted separately.
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.
👍
…6844) **Related Issue:** N/A ## Summary Wires up `accessible` test helper for input-date-picker suite. **Note**: this rolls back overriding `role` on `calcite-input`'s internal input (see #6805). This ended up causing invalid markup as some roles require matching aria roles, which refs cannot be resolved between shadow/light DOM: ``` ● calcite-input-date-picker › is accessible expect(received).toHaveNoViolations(expected) Expected the HTML found at $('calcite-input-date-picker,calcite-input,input[aria-label=""]') to have no violations: <input aria-label="" class="" inputmode="text" placeholder="MM/DD/YYYY" type="text" role="combobox"> Received: "Required ARIA attributes must be provided (aria-required-attr)" Fix any of the following: Required ARIA attributes not present: aria-expanded, aria-controls ``` @geospatialem helped test and verified that both JAWS & NVDA provide relevant options regardless of this change. VoiceOver is the only one that will lack context when interpreting the component: #### passing `role="combobox"` through to the internal input <img width="675" alt="Screenshot 2023-04-24 at 11 59 24 AM" src="https://user-images.githubusercontent.com/197440/234107372-93d70d4e-b094-4933-af6d-d1f518fe43e5.png"> #### not passing `role="combobox"` through to the internal input <img width="640" alt="Screenshot 2023-04-24 at 11 57 43 AM" src="https://user-images.githubusercontent.com/197440/234107358-9ee7c082-6997-49bf-a524-a1a24efcca06.png"> cc @Elijbet
Related Issue: #6773
Summary
This enhances the input-date-picker to allow it to be toggled via mouse and keyboard vs initial focus.
This also updates input to allow overriding role to accommodate other a11y structures.