fix(ui5-date-picker): input type is now conveyed #2628
Conversation
The component input type is recognized by the screen reader, with the help of 'aria-roledescription' attribute. Fixes SAP#2604
unazko
requested review from
ghristanov,
elenastoyanovaa,
filiptanasijevic90 and
ilhan007
and removed request for
filiptanasijevic90
| @@ -43,6 +40,9 @@ CAROUSEL_DOT_TEXT=Item {0} of {1} displayed | |||
| #XACT: DatePicker 'Open Picker' icon title | |||
| DATEPICKER_OPEN_ICON_TITLE=Open Picker | |||
|
|
|||
| #XACT: Aria information for the Date Picker | |||
| DATEPICKER_DATE_TYPE=Date Type | |||
There was a problem hiding this comment.
Why "Date Type", in UI5 the corresponding text is "Date Input"?
There was a problem hiding this comment.
It is "Date Type" by specification. "Date Input" is legacy in the other project.
There was a problem hiding this comment.
The text "Date Type" doesn't make any sense. What does it mean? What types of dates are there? Or is it "Type a date"? which is also strange. Please check with the specification owner what this means and what the logic is
There was a problem hiding this comment.
Hi Vladi,
I'd agree that "Date Type" string should be changed, but that's based on different concerns - I'll explain.
The main usage of aria-roledescription is for developers to provide better localization(!) of an element's role (implicit or not). This means that despite its name, aria-roledescription doesn't actually supplement the original role with additional description, but rather replaces it in the final announcement. Such naming proves to be quite deceiving. Making things worse, previous JAWS 2019 builds had supplementary announcements, but fortunately JAWS 2019, JAWS 2021 and NVDA (all latest) are working as intended now.
As standard ARIA roles are often not fully suited for our OpenUI5 controls, which could be confusing for blind people when using our framework, we used to provide a "custom role" (often the control's name) in aria-describedby. With the introduction of aria-roledescription in ARIA 1.1, we decided to take advantage of that new attribute by moving any existing "custom roles" to it (and adding missing ones in the process).
Now, for most controls this transition went without a hitch. DatePicker however has a tiny detail - it deviates from its specification (which was correctly pointed out). It's original description was meant to be "Date Type", which would've been fine at the time (as aria-describedby is announced in addition to an element's role), but it'd lose is combobox context once moved to aria-roledescription. The reason why it never emerged as an issue after our transition is that we never changed it from "Date Input". Since we learnt the hard way that changing a single word (even with a synonym) often result in months of false-positive bug reports, as testers were used to expecting a certain speech output, a decision was made to migrate them as they are.
So I see three possible choices for now:
- Date Type: Explained above, not valid.
- Date Input: A tad better, but flawed too, as DatePicker is more than a regular date input. In addition to this, if a user decides to type a date in its
<input>, there's probability DP's formatter will change it when focus moves. Having a input with different value than the entered one could be quite confusing. It would hold the same date though. - Date Picker: FIORITECHP1-12301's proposal and final recommendation. Such value seems superior to the other options and would be our go-to choice, with other datetime controls following such naming convention.
Still, being the framework owners, we'd always comply with your preferences. Whether this is a proposal you agree with or you wish to try out a different approach - please let us know and we'll implement accordingly.
Regards.
There was a problem hiding this comment.
As discussed with the other accessibility experts - the text will be "Date Input"
There was a problem hiding this comment.
Thanks Gerogi for the detailed explanation. I'll change the text to "Date Input" as a final decision for consistency with the other project.
|
@unazko Could you resolve the merge conflicts to continue? |
…into date-picker-input-acc
packages/main/src/Input.js
Outdated
| @@ -1067,6 +1067,7 @@ class Input extends UI5Element { | |||
|
|
|||
| return { | |||
| "input": { | |||
| "ariaRoledescription": this._inputAccInfo && this._inputAccInfo.ariaRoledescription || undefined, | |||
There was a problem hiding this comment.
There is an eslint rule enforcing () despite priority for this line.
If you want, you can create a git pre push hook with the following content to avoid pushing eslint problems:
#!/bin/sh
#
# To enable this hook, run this command from the root folder of the project
# $ git config core.hooksPath .githooks
# git runs hooks in the root dir
yarn lint
| @@ -43,6 +40,9 @@ CAROUSEL_DOT_TEXT=Item {0} of {1} displayed | |||
| #XACT: DatePicker 'Open Picker' icon title | |||
| DATEPICKER_OPEN_ICON_TITLE=Open Picker | |||
|
|
|||
| #XACT: Aria information for the Date Picker | |||
| DATEPICKER_DATE_TYPE=Date Type | |||
There was a problem hiding this comment.
The text "Date Type" doesn't make any sense. What does it mean? What types of dates are there? Or is it "Type a date"? which is also strange. Please check with the specification owner what this means and what the logic is
The component input type is recognised by the screen reader, with the help of 'aria-roledescription' attribute. Fixes SAP#2604
The component input type is recognised by the screen reader, with the help of 'aria-roledescription' attribute. Fixes SAP#2604
The component input type is recognized by the screen reader,
with the help of 'aria-roledescription' attribute.
Fixes #2604