d2l-dialog: unable to add autofocus to the non-primary button in the footer to focus the least destructive action
OksanaSam opened this issue · comments
Unlike dialog-confirm that has the first non-primary button focused, the regular d2l-dialog has the first interactive element focused by default which in my case is the primary button and the most destructive action
Also getting a lint error (lit-a11y plugin) for autofocus:
Is it safe to disable eslint for the lines containing autofocus?
Currently, the dialog only looks in the default slot for elements that have autofocus. It does not check the footer slot. We could probably update the logic to check the footer slot as well, assuming this is what we want.
What will be announced to screen readers though? Will they have any context, or will it just read the button text? i.e. will they even know what they are cancelling out of? Another option is to decorate the first paragraph with tabindex="-1" so that focus goes there first. I feel like this scenario has come up before, where there are interactive elements in the dialog content. @geurts , do you know if there is some design guidance on the best practice for this, given our current components?
Thank you!
Yes, that's what we ended up doing
<div style="font-weight: bold;" tabindex="-1" autofocus>${dialogText}</div>
- disabling eslint for that line
@geurts , do you know if there is some design guidance on the best practice for this, given our current components?
The existing Focus Management section in the docs does call this out, but it could use some clarification since it doesn't explicitly describe adding this to a paragraph element. We're also tracking the need for a design pattern around how to use dialogs (language, buttons, accessibility).
Is it safe to disable eslint for the lines containing autofocus?
Oof. So yes it is, but also you wouldn't have to if we called the attribute anything other than autofocus.
What will be announced to screen readers though? Will they have any context, or will it just read the button text? i.e. will they even know what they are cancelling out of?
I could've sworn there was a way to read the dialog content even when you've sent to focus to a button. Turns out there is, and we already have it implemented! Just gotta use the describe-content property. This will set aria-describedby on the outer modal element, so the SR knows to announce it before the button it's focused on. See an example of its behaviour at Modal Dialog Example - ARIA Authoring Practices Guide (APG).
Also, I'm no designer, but using more meaningful terms such as "Delete" and "Cancel" rather than "Yes" and "No" might help to remove some confusion.
Nvm we totally have that in our docs.
Also, is there a reason we don't just have the buttons in the other order, so that the cancel button comes first? Like as part of our general dialog design I mean. I know it can be done in the code, but I don't think we ever do it. Is it just for looks?
No wait we totally do with confirm-dialog And it also uses describe-content. Maybe that should just be used here instead of the general dialog.
Should we revise the docs for the dialog component to include instructions for when to use describe-content?
(Sorry for rambling everyone)
Sorry, I'm not great at staying on top of GitHub emails. Yes, that's a good idea -- maybe you could rename the Focus Management section to Accessibility and have sub-sections for Focus Management and the describe-content property?
We now have a section in the docs to address this issue. Can it now be closed?
https://daylight.d2l.dev/components/dialog/#announcing-the-dialog-text
Looks great!