LG-7033: change hint text element from span to div

[svalexander]

🎫 Ticket

Lg-7033

🛠 Summary of changes

This pr addresses the hint text for the date of birth portion of the state_id form. The text is being read by the VoiceOver and NVDA screen readers - but the latter does not highlight the element that displays that text (it's not focusable). This was happening because that text is within a span. This pr changes the span to a div so that the element is not focusable when the NVDA screen reader reaches it.

📜 Testing Plan

Provide a checklist of steps to confirm the changes.
Tested this using AssistivLabs

• Follow the instructions on the AssistivLab's dashboard to enable a tunnel
• Start a new session by clicking "Start Testing"
• Open the finder on the bottom left hand screen by clicking "start"
• Create a new error.yml file and save in downloads ( can accomplish by opening an existing document in notepad then clicking new under the file tab)
• Navigate to localhost:3000/
• Create an account and navigate to /verify
• Choose upload from phone and upload yml file you just created
• Navigate through screens until you reach state id form
• Use shift + option + down-arrow to navigate through form
• Screen reader should read out hint text under Date of Birth and it should be outlined with a red box

👀 Screenshots

If relevant, include a screenshot or screen capture of the changes.

Before:

After:

🚀 Notes for Deployment

N/A

[NavaTim]

Were you able to reproduce the reported behavior of the State or ID Number fields?

[svalexander]

Were you able to reproduce the reported behavior of the State or ID Number fields?

they both are working as expected

[aduth]

Are there any resources you can share which talk about this distinction between <span> and <div> with NVDA specifically? It wouldn't seem to me that these should behave fundamentally different, since they're both presentational elements, and the only difference should be that is visually displayed as a block (vs. inline).

[aduth]

The standout thing for me is that there is no relationship defined between the fields and this hint, unlike the default ValidatedFieldComponent, which assigns an ID to the hint and associates the field with it using aria-describedby. Should we be doing that here too?

identity-idp/app/components/validated_field_component.html.erb

Lines 19 to 30 in 592623a

	aria: {
	invalid: false,
	describedby: [
	*tag_options.dig(:input_html, :aria, :describedby),
	"validated-field-error-#{unique_id}",
	"validated-field-hint-#{unique_id}",
	],
	},
	},
	hint_html: {
	id: "validated-field-hint-#{unique_id}",
	},

[svalexander]

that's an interesting point. It might indeed make sense to add an aria describedby label to the hint in order to associate it with the field it's coupled with by the field's id. The way we're doing it in those other examples though is currently raising a red flag with one of the accessibility checkers I used. I still have to dig into what about the id is causing a violation (perhaps b/c the same id is appended onto the describedby property in multiple places and maybe it should instead have the id of the field? not 100% sure)

[aduth]

To me, this would seem to explain why the hint isn't being announced, since the screen reader wouldn't have any indication that the text has anything to do with the field when the field is focused.

[svalexander]

i see what you're saying. So question I have now is this - adding the aria-describedby reads out the example for the memorable date component when the user navigates to the month, day and year input fields. This is what we'd expect, buuuuut- does it make sense to a user to hear "example 4 28 1986" for the month, then the day and then the year? because really for month an example would be just "4". Or maybe I'm overthinking it. I'm gonna put this in slack also so folks can chime in.

[NavaTim]

Maybe this is a good use case for aria-placeholder instead.

[aduth]

i see what you're saying. So question I have now is this - adding the aria-describedby reads out the example for the memorable date component when the user navigates to the month, day and year input fields. This is what we'd expect, buuuuut- does it make sense to a user to hear "example 4 28 1986" for the month, then the day and then the year? because really for month an example would be just "4". Or maybe I'm overthinking it. I'm gonna put this in slack also so folks can chime in.

That's a good question! I agree with your concern that it would be confusing to say the full example text given how we've split the input values across three fields.

To this and @NavaTim 's suggestion, I'd also want to be careful about introducing inconsistency between the visual text and how it's conveyed to assistive technology (similar but not same as G211). This might be an acceptable case to make an exception, however.

For what it's worth, the canonical markup example from the design system uses aria-describedby with the same (full) hint example for each input, and typically we should be able to trust that they've put some thought into the accessibility implications.

[NavaTim]

For what it's worth, the canonical markup example from the design system uses aria-describedby with the same (full) hint example for each input, and typically we should be able to trust that they've put some thought into the accessibility implications.

That's a good point. Since they included the full example as a hint, I would be inclined to do the same.

[svalexander]

yes i agree -it makes sense for us to remain consistent with how they've implemented the hint. i'll go ahead and push up the change.

[NavaTim]

It looks like this found an important difference between the Memorable Date component and the default input wrapper, so I can understand how this may fix the issue. That said, I do recommend implementing @aduth's suggestion as well.

[aduth]

LGTM 👍