Skip to content

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

Merged

Conversation

jcfranco
Copy link
Member

@jcfranco jcfranco commented Apr 18, 2023

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.

@jcfranco jcfranco requested a review from a team as a code owner April 18, 2023 07:46
@github-actions github-actions bot added the enhancement Issues tied to a new feature or request. label Apr 18, 2023
@jcfranco jcfranco marked this pull request as draft April 18, 2023 09:39
@jcfranco jcfranco added the pr ready for visual snapshots Adding this label will run visual snapshot testing. label Apr 19, 2023
@jcfranco jcfranco added pr ready for visual snapshots Adding this label will run visual snapshot testing. and removed pr ready for visual snapshots Adding this label will run visual snapshot testing. labels Apr 19, 2023
@jcfranco jcfranco marked this pull request as ready for review April 20, 2023 00:53
@jcfranco
Copy link
Member Author

+@geospatialem in case additional screen reader testing is needed.

@jcfranco jcfranco added pr ready for visual snapshots Adding this label will run visual snapshot testing. and removed pr ready for visual snapshots Adding this label will run visual snapshot testing. labels Apr 20, 2023
@geospatialem geospatialem self-requested a review April 20, 2023 15:30
Copy link
Member

@geospatialem geospatialem left a 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"
Copy link
Member

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. 😢

Copy link
Member

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.

Copy link
Member Author

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?

Copy link
Member

@driskull driskull left a 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}
Copy link
Member

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?

Copy link
Member

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.

Copy link
Member Author

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).

Copy link
Member

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.

@jcfranco jcfranco added pr ready for visual snapshots Adding this label will run visual snapshot testing. and removed pr ready for visual snapshots Adding this label will run visual snapshot testing. labels Apr 21, 2023
Copy link
Member

@driskull driskull left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@jcfranco jcfranco deleted the jcfranco/6773-improve-input-date-picker-toggling-options branch April 21, 2023 22:43
jcfranco added a commit that referenced this pull request Apr 24, 2023
…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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Issues tied to a new feature or request. pr ready for visual snapshots Adding this label will run visual snapshot testing.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants