WebAIM - Web Accessibility In Mind

E-mail List Archives

Thread: Pop-up question

for

Number of posts in this thread: 5 (In chronological order)

From: Laura Roberts
Date: Sun, May 15 2022 7:21PM
Subject: Pop-up question
No previous message | Next message →

I'm testing a webpage with JAWS that has a pop-up window.

The pop-up window has two tabs at the top, text in the body, and one button
at the bottom: "close".

The focus is on the "close" button and I have to hit CTRL+Home to make JAWS
read from the top of the pop-up window, or Shift+Tab (but a blind user
wouldn't know the tab buttons exist) or hit the up arrow a bunch of times.

This doesn't seem accessible to me, but maybe there's a good reason to have
focus on "close". I mainly work on PDF remediation so I don't know WCAG
inside and out.

I hope I explained that ok! I'm under an NDA so I'd have to redact stuff on
a screenshot.

Thanks,
Laura

From: Mark Magennis
Date: Mon, May 16 2022 2:19AM
Subject: Re: Pop-up question
← Previous message | Next message →

Placing focus on the Close button at the bottom of the dialog is a bit of a throwback to the days when modal dialogs generally contained a short text statement, e.g. a warning or a question, one or more form fields for making choices, and one or more action buttons, typically, OK, Cancel, or Continue. It made sense to read the title and the text and place focus on the first form field or action button. The user will have ben given all of the information above the focus point and would not need to backtrack.

A modal like you describe is different. Because there is a lot of content that the user will need to read and/or interact with before the Close button, I think your intuition is correct that it doesn't make sense to put focus on the Close button as that would require backtracking. I would recommend putting focus on the dialog's container (the <div role="dialog">).

An alternative, if your dialog has an x-icon Close button in the top right corner which is increasingly common these days, is to have that first in the reading order (and therefore Tab order) and place focus on that.

Mark

From: Laura Roberts
Date: Mon, May 16 2022 6:50AM
Subject: Re: Pop-up question
← Previous message | Next message →

Thanks a lot - I will let them know.
I appreciate your explanation!

On Mon, May 16, 2022, 4:19 AM Mark Magennis < = EMAIL ADDRESS REMOVED = >
wrote:

> Placing focus on the Close button at the bottom of the dialog is a bit of
> a throwback to the days when modal dialogs generally contained a short text
> statement, e.g. a warning or a question, one or more form fields for making
> choices, and one or more action buttons, typically, OK, Cancel, or
> Continue. It made sense to read the title and the text and place focus on
> the first form field or action button. The user will have ben given all of
> the information above the focus point and would not need to backtrack.
>
> A modal like you describe is different. Because there is a lot of content
> that the user will need to read and/or interact with before the Close
> button, I think your intuition is correct that it doesn't make sense to put
> focus on the Close button as that would require backtracking. I would
> recommend putting focus on the dialog's container (the <div role="dialog">).
>
> An alternative, if your dialog has an x-icon Close button in the top right
> corner which is increasingly common these days, is to have that first in
> the reading order (and therefore Tab order) and place focus on that.
>
> Mark
>
>

From: Mark Magennis
Date: Mon, May 16 2022 7:53AM
Subject: Re: Pop-up question
← Previous message | Next message →

I should add that another possibility in your case would be to place focus on the Tab bar, if that's the first piece of content, or the first thing after an x-icon close button. I have a feeling that the result might be a bit strange with a screen reader though so you'd have to test it.

From: glen walker
Date: Mon, May 16 2022 10:11AM
Subject: Re: Pop-up question
← Previous message | No next message

This feels like a UX question and not a WCAG conformance question, or at
least that's my take on it.

One might argue that 2.4.3 Focus Order comes into play but having the focus
at the end of the dialog DOM, to me, does not affect "the meaning or
operation" of the page. That is, the focus order does not traverse in an
unusual way. The initial focus position might not be where you expect but
if the dialog is coded properly, I can press TAB and get to all the
elements in the dialog in an expected order and the keyboard focus remains
trapped in the dialog.

Now, you mentioned there are two tabs at the top. Are you referring to
tabs in a tab navigator widget,
https://www.w3.org/TR/wai-aria-practices/#tabpanel ? If so, then I would
expect my initial focus to be on the tab. That is, on the first
interactive element in the dialog. If it's not on the first element, then
that's unexpected, but again, I'm not sure I'd fail 2.4.3.

Whether the close button is in the upper right of the dialog (and the
beginning of the dialog DOM) or at the bottom of the dialog (and the end of
the dialog DOM) doesn't really matter with regards to whether the initial
focus should be on it. That is, if the close button is in the upper right
and the initial focus is on it and you pass WCAG conformance but then
another dialog has the close at the bottom and the initial focus is on it
and you fail WCAG, that would seem to be inconsistent. What you hear with
a screen read would be exactly the same: "close button", (tab key), "tab
navigator widget".

Of course, having a different DOM order means the up/down arrow keys with
the screen reader would read things differently, so you might think 1.3.2
comes into play. I personally don't think it would fail 1.3.2.

I'm just tossing out another take on this. Accessibility is obviously more
than just WCAG conformance. Does WCAG say you should have the focus on the
first interactive element in the dialog? No. Should the focus be on the
first interactive element from a UX perspective? That's generally a good
practice but it can make sense to not do that too.