NVDA reads the placeholder letter by letter

[martinlex]

Describe the bug

NVDA reads the placeholder as "Y Y Y Y M M D D". It is not pleasant or helpful for the user. Please put the format in the label along with a more clear readout.

By the way: Why is there a placeholder? I mean, it's the date picker's job to populate with the correct format when we choose date from the date picker. Right?

Desktop (please complete the following information):

• OS: Win10
• Chrome with NVDA

[WickyNilliams]

Placeholder is to allow manual entry as well as selection via calendar. Don't want to restrict people's input mode!

[martinlex]

If you want to help the user with format, do not use placeholder for this. Place it preferrably in the label alongside with a proper aria-label readout. When you start typing, the placeholder disappears, and I forget which is the correct format.

[aardrian]

Removing instructions necessary to successfully complete the control without generating an error may be a 3.3.2 Labels or Instructions violation (depending on the context of the page). Similarly, retaining the formatting instructions can help mitigate 3.3.3 Error Suggestion (again, depending on context).

[WickyNilliams]

@aardrian what are you referring to? Removal of the placeholder? Not sure if I've missed some context here sorry

[WickyNilliams]

@martinlex are your suggestions regarding the demo page specifically? Both placeholder and label are customisable via attributes, so you can always remove the placeholder and add format to the label if you wished. Or are you suggesting we should recommend this as a sort of exemplary approach?

[aardrian]

@WickyNilliams Yes, I am referring to the placeholder text. Since that is the only formatting hint for the field on the control, there is no other way I see to convey the required format.

[WickyNilliams]

@aardrian OK, so placeholder is customisable already. Do you think we should avoid having a placeholder by default? And in the examples we should move the format into the <label>?

[aardrian]

@WickyNilliams The context is generally going to determine where the format hint goes...

• If you have an application where a particular date format is constant throughout, you may not need a persistent formatting hint;
• If you want the hint to be announced every time with the field, then the <label> is a good choice;
• If you want it to be less verbose but still announced, a text node after the field associated with aria-describedby can do the trick;
• If you have a trained set of users in a known environment, see the first bullet.

If you offer three options (in the <label>, in a <span> with aria-describedby, as placeholder) and give guidance on which to use and caveats, then your implementors will be on a better track to choose one that fits and satisfies the WCAG SCs I reference.

[WickyNilliams]

Awesome, thanks! So placeholder and label are already configurable by developers. Meaning we need to add an option for aria-describedby. That would suffice, right?

[WickyNilliams]

Eg then you could have a format hint...

Using a label:

<label for="date">Choose a date (YYYY-MM-DD) </label>
<duet-date-picker
  identifier="date"
  placeholder="" 
></duet-date-picker>

Or using a placeholder:

<label for="date">Choose a date</label>
<duet-date-picker
  identifier="date"
  placeholder="YYYY-MM-DD" 
></duet-date-picker>

Or using aria-describedby:

<label for="date">Choose a date</label>
<duet-date-picker
  identifier="date"
  placeholder="" 
  description="YYYY-MM-DD" 
></duet-date-picker>

Happy to then include examples of all three in the docs

[aardrian]

Label example looks good.

Placeholder example looks acceptable, but that should be a last resort when the other options do not fly. I understand some devs will do it regardless, but if you put all the caveats and warnings and WCAG failures on it, they cannot reasonably blame the component when their code fails a WCAG review.

The aria-describedby is hard to say because you are showing the component code, not the raw HTML output. If your code generates something that looks like this then I think it works:

<input […] aria-describedby="dateHint">
<span id="dateHint">YYYY-MM-DD</span>

I think your demo should default to the label or described approach as well. People like me get tasked with evaluating libraries and components and sandwiches based on the demo provided by the maker, and if I see a violation I include it in my report. Better to have a clean version to start.

[WickyNilliams]

Sorry, typed the examples above on mobile, so tried to keep them terse. But yes, that's exactly what I meant: if description (name TBD) is provided, output the raw html as you show.

So, game plan here will be to:

1. Add some support for a description via aria-describedby
2. No placeholder by default
3. Update examples to place format in <label>

[aardrian]

[ animated thumbs-up emoji] That plan works for me.

[JamesCatt]

Bumping this. It looks like the description feature was never implemented?