Timepicker FF/NVDA screenreader issue

[agenova-cengage]

Is your feature request related to a problem? Please describe. Screenreader is not reading subsequent values when adjusting the timepicker value(hour/minute) fields. Screencast: NVDA(2020.3)+FF: http://somup.com/cYl6QR2tKm Note: Issue is NOT reproducible with JAWS+Chrome combination.

Describe the solution you'd like NVDA on FF should readout subsequent values when adjusting the timepicker value(hour/minute) fields.

Describe alternatives you've considered N/A

[rcgillet]

The issue seems to be that there is a placeholder on the input. The input is of type number which does not appear to be supported: https://www.deque.com/blog/accessible-forms-the-problem-with-placeholders/.

We are going to need some discussion on what we want to do here. Is there an option where we can show something that looks like a placeholder? Should we get rid of the placeholder altogether? etc.

[gaussant]

Try putting aria-live="assertive" on the <input> that changes the time value... <input type="text" disabled="" value="05:02 AM" aria-invalid="false" style="background:#FFFFFF;border-color:#8f8f8f;cursor:default;width:144px" class="css-n7k5b0" id="3f9b0c18-6859-4a3a-b477-abdabd422a07" aria-live="assertive">

[joasmi723]

The suggestion from @gaussant didn't solve the issue in FF/NVDA. Still looking for a solution.

[tasnook]

Hi All,

I have confirmed that removing the placeholder attribute resolves the issue (NVDA/FF) without the need to add aria-live. NVDA/Chrome and NVDA/Edge work as is with the placeholder text.

Three Possible Remediations:

1. Add an onfocus event listener that calls the removeAttribute method to remove the placeholder attribute entirely upon user interaction. You'd have to decide whether or not to replaced it onBlur if the user does not make a selection. This solution is experimental and will need to be validated with NVDA testing.
2. You could take an approach somewhat similar to the popular floating text labels that swap CSS classes after user interaction. In this case, the element should always have aria-hidden="true" and the class during/after user interaction should apply { display: none; }
3. A third option would be to fall back to the native time input, <input type="time"...>. I am not sure of the style limitations to this. It does have wide browser and mobile support, but would need some added support for Safari. For reference input type="time" - HTML: HyperText Markup Language | MDN.

Separate note on keyboard instructions / interaction:

Current source code: <button aria-label="AM selected. To change to PM press the p or enter button." [...]>AM</button>

The aria-label suggests users can use the Enter key and this is currently a supported interaction. However, this is counter to how the native <input type="time"..> element (and other form controls) operate with the keyboard. I would recommend instructing users to use letter navigation, or up and down arrows (already supported. And remove the Enter key functionality.

Separate note on maxlength attribute:

The maxlength attribute is not supported on type="number" and not necessary because of the min and max attributes

=== Taylor Anne Snook (she/her/hers) Senior Digital Accessibility Consultant Perkins Access

[silvalaura]

We haven't update this component in a while, but I'm unable to reproduce this bug: https://github.com/cengage/react-magma/assets/91160746/946c3d5f-c5c4-451d-a04a-519983232e4d