Content
View differences
Updated by Behrokh Satarnejad about 1 year ago
### Acceptance criteria Notes
* For screen readers, screenreaders, we will only target manual date input using the Start date, Finish date and Duration input fields, not the Flatpickr-based mini-calendar.
* When This is because manually going through and tabbing over every day in a even a single calendar month is cumbersome and inefficient. (Flatpickr is not accessible presumably for this reason)
* Because the new Primer input fields use Rails helpers, they accept dates in a number of different formats (yyyy/mm/dd, dd-mm-yyyy, dd.mm.yyyy...). This greatly simplifies date input and reduces errors during manual input.
* **Warning:** This functionality is lost due to a recent refactoring. We need to fix this.
* There are a number of challenges:
* Providing important banner information when there is a change of mode: the banner is generally above everything, but a control below (switch from manual to automatic, or vice-versa) can change banner text. This updated information needs to be accessible to a screen-reader.
* _When changing switch from manual to automatic, or vice-versa, the banner info should be read out by screen reader
reader_
* When you enter a date or a duration, this updates other fields; this has to be read by the screen reader too, out too so the user doesn't lose that context.
* Today links labels under the Start/Finish dates:
* We should We'll keep "Today" in the non-screen reader view but add an ARIA label that explains context, e.g. "Select today as context eg. "Set start date." date to today" or "Select today as "Set finish date". date to today".
#### Out of scope
* Mobile behavior: behaviour: ###61051
* The native date picker is accessible. acessible. Users on mobile devices will use the device-specific aids and not type out the date as they would on desktop.
* In-line error when users pick non-working days: ###61434
* For screen readers,
* Because the new Primer input fields use Rails helpers, they accept dates in a number of different formats (yyyy/mm/dd, dd-mm-yyyy, dd.mm.yyyy...). This greatly simplifies date input and reduces errors during manual input.
* **Warning:** This functionality is lost due to a recent refactoring. We need to fix this.
* There are a number of challenges:
* Providing important banner information when there is a change of mode: the banner is generally above everything, but a control below (switch from manual to automatic, or vice-versa) can change banner text. This updated information needs to be accessible to a screen-reader.
* _When
* We should
#### Out of scope
* Mobile behavior:
* The native date picker is accessible.
* In-line error when users pick non-working days: ###61434