E-mail List Archives

Search E-mail List Archives for

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

From: Ramakrishnan Subramanian
Date: Tue, Jan 31 2017 11:19AM
Subject: in a modal dialog can the tab focus go to the browser UI?
No previous message | Next message →

Dear members,
I kindly request your inputs on the following scenario as per the WCAG
guideline and aria authorization practice:

Actual behavior:
In a modal dialog while navigating using tab /shift tab keys: though
the focus is trapped inside the dialog, when we hit tab key from the
last focusable element inside the dialog, the focus is going to the
browser UI.
Expected behavior:
1. When we hit tab from the last focusable element, the focus should
go to the first focusable element inside the dialog.
2. when we hit shift tab from the first focusable element, the focus
should go to the last focusable element inside the dialog.

Is this only a best practice? Or
Is this mandatory to pause wecag guidelines?

: should we flag this as bug as per wcag and aria authorization?
If the developers feel that this is something which is a browser
behavior which need not be altered.
Is that fine?

Thanks and Regards,
Ramakrishnan

From: Birkir R. Gunnarsson
Date: Tue, Jan 31 2017 11:26AM
Subject: Re: in a modal dialog can the tab focus go to the browser UI?
← Previous message | Next message →

The ARIA Authoring Practices guide is not normative (i.e. it is not a
fflat out violation when its recommendations are not followed).
That being said, it is the model that we should always follow whe
constructing custom components.
When there is a significant deviation from that spec we should explore
it, ask ourselves if the users are likely to be affected, and file an
issue if we feel this is the case.
In this case, the spec recommends that the focus order is trapped
inside the dialog, as you describe very well.
I don't know why the focus is escaping out to the address bar, it does
ot in this example for instance:
https://dequeuniversity.com/library/aria/popups-dialogs/sf-modal-dialog
What browser are you using? It could be a browser thing.



On 1/31/17, Ramakrishnan Subramanian < = EMAIL ADDRESS REMOVED = > wrote:
> Dear members,
> I kindly request your inputs on the following scenario as per the WCAG
> guideline and aria authorization practice:
>
> Actual behavior:
> In a modal dialog while navigating using tab /shift tab keys: though
> the focus is trapped inside the dialog, when we hit tab key from the
> last focusable element inside the dialog, the focus is going to the
> browser UI.
> Expected behavior:
> 1. When we hit tab from the last focusable element, the focus should
> go to the first focusable element inside the dialog.
> 2. when we hit shift tab from the first focusable element, the focus
> should go to the last focusable element inside the dialog.
>
> Is this only a best practice? Or
> Is this mandatory to pause wecag guidelines?
>
> : should we flag this as bug as per wcag and aria authorization?
> If the developers feel that this is something which is a browser
> behavior which need not be altered.
> Is that fine?
>
> Thanks and Regards,
> Ramakrishnan
> > > > >


--
Work hard. Have fun. Make history.

From: JP Jamous
Date: Tue, Jan 31 2017 11:27AM
Subject: Re: in a modal dialog can the tab focus go to the browser UI?
← Previous message | Next message →

Answers below.

From: Lucy Greco
Date: Tue, Jan 31 2017 3:22PM
Subject: Re: in a modal dialog can the tab focus go to the browser UI?
← Previous message | Next message →

hello:
i think it is a best practice to restrict focus to the dialog if the
dialog has actions that need to happen before the user can move on. the
user will become confused if they are interacting with a dialog and then
the contents out side the dialog start coming up. also i have seen the
behavior wear the dialog comes up but the screen reader is focused on the
contents behind the dialog visually so that is an other reason to restrict
focus. This situation is vary bad if the screen reader user is trying to
get support and the sited person does not know they are on hidden
content.lastly the one point no one has made is that once the user is done
in the dialog you must be sure to bring them back to the write place i.e.
wear they initiated the dialog or on the write place of the new page if a
new page is generated from the dialog.

Lucia Greco
Web Accessibility Evangelist
IST - Architecture, Platforms, and Integration
University of California, Berkeley
(510) 289-6008 skype: lucia1-greco
http://webaccess.berkeley.edu
Follow me on twitter @accessaces


On Tue, Jan 31, 2017 at 10:27 AM, JP Jamous < = EMAIL ADDRESS REMOVED = > wrote:

> Answers below.
>
>

From: chaals
Date: Wed, Feb 01 2017 3:19AM
Subject: Re: in a modal dialog can the tab focus go to the browser UI?
← Previous message | Next message →

Note also that this is a current issue for the HTML spec: https://github.com/w3c/html/issues/773

cheers

31.01.2017, 23:23, "Lucy Greco" < = EMAIL ADDRESS REMOVED = >:
> hello:
>  i think it is a best practice to restrict focus to the dialog if the
> dialog has actions that need to happen before the user can move on. the
> user will become confused if they are interacting with a dialog and then
> the contents out side the dialog start coming up. also i have seen the
> behavior wear the dialog comes up but the screen reader is focused on the
> contents behind the dialog visually so that is an other reason to restrict
> focus. This situation is vary bad if the screen reader user is trying to
> get support and the sited person does not know they are on hidden
> content.lastly the one point no one has made is that once the user is done
> in the dialog you must be sure to bring them back to the write place i.e.
> wear they initiated the dialog or on the write place of the new page if a
> new page is generated from the dialog.
>
> Lucia Greco
> Web Accessibility Evangelist
> IST - Architecture, Platforms, and Integration
> University of California, Berkeley
> (510) 289-6008 skype: lucia1-greco
> http://webaccess.berkeley.edu
> Follow me on twitter @accessaces
>
> On Tue, Jan 31, 2017 at 10:27 AM, JP Jamous < = EMAIL ADDRESS REMOVED = > wrote:
>
>>  Answers below.
>>
>>  

From: JP Jamous
Date: Wed, Feb 01 2017 6:21AM
Subject: Re: in a modal dialog can the tab focus go to the browserUI?
← Previous message | Next message →

Lucy,

Don't steal my words. I informed him to use a Close button to return the user to the page. What a sneaky lady you are. LOL

From: Sailesh Panchang
Date: Wed, Feb 01 2017 7:11AM
Subject: Re: in a modal dialog can the tab focus go to the browser UI?
← Previous message | No next message

Hello Ramakrishnan,
By terming it as modal, the expectation is that one can navigate and
operate only within the dialog.
However, if the content of the parent page appears graded and is not
navigable with a mouse but is available via a keyboard / or to AT
users then it may trigger an SC 1.3.1 error (presentation is not
exposed via markup) and maybe SC 2.4.3 too.
If the background content is available (navigable and operable) to
all users, then it is important that the boundaries of the dialog are
clearly marked and exposed to AT too. Of course focus management is
important here too: focus should be placed in the dialog when launched
and back on the trigger element / at a logical spot on the page when
dismissed.
In your example it appears the last focusable element in the dialog is
treated like the last element on any page: the next tab moves focus
to the browser UI.
Thanks and best wishes,
Sailesh Panchang
Principal Accessibility Consultant
Deque Systems Inc
Phone 703-225-0380 ext 105
Mobile: 571-344-1765