WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Jaws going to top of page when closing modal

for

From: Birkir R. Gunnarsson
Date: Sep 27, 2019 5:28PM

If the user interaction wit the dialog does not change the context of
the page (i.e. if user clicks "close" or "cancel") then, yes, browsers
should handle sending the focus back to the element that triggered the
dialog (if support for the <dialog> element is ever fully
implemented).
But if the user takes action that changes the context of the page,
like clicking "delete user" or something, developers will have to
manage the focus, only they will understand where it should go for
that situation.
I've been testing an Angular library from Google and I'll give them
that the dialogs are handled beautifully, focus is consistently
trapped in the dialog and sent back to the trigger when you click a
"close" or "cancel" button.

On 9/27/19, David Engebretson Jr. < <EMAIL REMOVED> > wrote:
> This is a super confusing aspect to screen reader navigation with custom
> elements; if the developer doesn't keep track of focus and set it to where
> they want any users focus to be (screen reader user or not), it can become
> a
> usability nightmare.
>
> Hopefully, someday, setting focus won't be so dynamic or easy to forget. A
> users focus should always be brought back to where they were, IMO. It's not
> a difficult thing to do programmatically, but it is difficult for
> developers
> to remember to provide the functionality. Why? You might ask? In my opinion
> it is because that is not a part of the web developer curriculum. If
> developers were to use a modal html5 <dialog> wouldn't focus be set to the
> previous control automagically? If not, it should, in my thinking.
>
> I love this list, btw. I'm always learning.
>
> Best,
> David
>
>
>