E-mail List Archives
Re: Controlling focus in a dialog and an app dialog
From: glen walker
Date: Jul 19, 2018 2:16PM
- Next message: Jonathan Avila: "Re: Confirmation of actions - violation or feature?"
- Previous message: Jim Homme: "NVDA Input Fields: Is This New Behavior"
- Next message in Thread: None
- Previous message in Thread: Karin Carlson: "Controlling focus in a dialog and an app dialog"
- View all messages in this Thread
Great questions, because they straddle the line between UX and
accessibility, although there really shouldn't be a line. From a
compliance perspective, as long as you have a heading for #1, a focus for
#2, and minimal tab stops for #3, you're ok.
But for a good user experience for all, you can dig into more detail.
For #1, the heading in the dialog can be an h1 or h2 (or h3 or whatever).
You and the developer both have valid points and neither of you are more
"right" than the other. Perhaps it's good to let the developer have this
one so that when another a11y issue comes up, you'll be able to push
harder. Here are two well-respected accessibility experts that have dialog
examples. The first uses an h1 and the second uses an h2.
http://gdkraus.github.io/accessible-modal-dialog/
http://scottaohara.github.io/accessible_modal_window/
For #2, my personal preference is to put the focus on the dialog itself,
but you can certainly put the focus on the first interactive element.
Greg's example above puts it on the first element. Scott has various
examples of different focus areas at:
http://scottaohara.github.io/accessible_modal_window/tests/general.html
I probably would **not** put the focus on the heading because the heading
is not an interactive element. If you want the heading announced (which
would be a good thing), the dialog itself can have aria-labelledby pointing
to the heading.
For #3, you **could** put a skip link in the dialog, but with only 3 tab
stops, you're actually adding a 4th tab stop for the skip link and possibly
making the situation worse. If I tab once and get to the skip link, hit
enter to select the link and be taken to the main contents, then i'm only
saving 2 keystrokes (compared tabbing through the three common elements and
a 4th tab to get to the first interactive element). It's probably not
worth the effort of a skip link to save two keystrokes.
I also wouldn't visually place elements at the top but have them in the tab
order at the bottom because that might look weird for sighted users,
especially if there are cognitive issues. But having that weirdness might
not be noticeable. As you tab through all the elements, after going
through the elements visually at the top (but at the bottom of the DOM),
the focus would then move to the "real" elements at the top of the dialog
DOM, which are visually after the elements at the top, and you'd cycle
through them all and eventually it would just look like you're tabbing from
top to bottom (if that makes sense). So you could do that, but again,
perhaps not worth it.
Glen
On Wed, Jul 18, 2018 at 8:40 PM, Karin Carlson < <EMAIL REMOVED> >
wrote:
> Hi, everybody.
>
> I have a multi-faceted question about dialogs and apps. I am working with
> someone who is developing an application. Every screen is technically a
> dialog, but there are dialogs which are more like "traditional" dialogs,
> like the "are you sure you want to quit" dialog.
>
> I'm struggling with finding guidance specifically for applications in
> regard to three accessibility concerns: if it's appropriate to use a
> heading 2 or 3 as the primary heading, where the focus should be placed
> upon the dialog opening, and if a dialog ever needs a skip link.
>
> 1) The developer thinks that because the containing page ("under" the
> application) has a heading 1, that it's appropriate to use heading 2 or 3
> as the "primary" heading on the dialogs in the app. I think that when an
> app window/dialog is open, it's its own little world, and a heading 1 (or
> ARIA role for level 1) is appropriate for the main heading.
>
> 2) There is guidance from the W3C that when a dialog opens, the focus
> should be placed on an element inside the dialog (like a heading). The
> developer is focusing on the entire dialog. As long as the information in
> the dialog is read aloud, does it matter?
>
> 3) At the top of almost every dialog/screen in the app, there are three
> focusable elements before one gets to the content (help, contact us, and
> the close button which he's labelled "exit"). This is consistent, but I
> find it strange to have three things to ALWAYS have to tab through to get
> to the business part of the dialogs that have interaction (which is pretty
> much all of them). I've suggested that the developer move the source code
> around so those 3 things are at the end of all the other tabbing, but that
> might be weird because visually they are at the top. So the only other
> solution I can think of is to place a skip link at the top. Do people do
> that? Or is 3 tabs, consistently placed, actually not that big a deal?
>
> Thanks very much in advance for your help,
>
> Karin Carlson
> > > > >
- Next message: Jonathan Avila: "Re: Confirmation of actions - violation or feature?"
- Previous message: Jim Homme: "NVDA Input Fields: Is This New Behavior"
- Next message in Thread: None
- Previous message in Thread: Karin Carlson: "Controlling focus in a dialog and an app dialog"
- View all messages in this Thread