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.

-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Ramakrishnan Subramanian
Sent: Tuesday, January 31, 2017 12:20 PM
To: = EMAIL ADDRESS REMOVED =
Subject: [WebAIM] in a modal dialog can the tab focus go to the browser UI?

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.

That's typical as that is the standard behavior unless you restrict the user to the modal.

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.

You can do the above with ARIA. You won't be violating any WCAG criteria. Unless you provide a Close button to allow the user to return to the browser UI. If you do not provide a Close button, you won't be in compliance with WCAG level A criteria.



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: 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.
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Ramakrishnan Subramanian
> Sent: Tuesday, January 31, 2017 12:20 PM
> To: = EMAIL ADDRESS REMOVED =
> Subject: [WebAIM] in a modal dialog can the tab focus go to the browser UI?
>
> 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.
>
> That's typical as that is the standard behavior unless you restrict the
> user to the modal.
>
> 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.
>
> You can do the above with ARIA. You won't be violating any WCAG criteria.
> Unless you provide a Close button to allow the user to return to the
> browser UI. If you do not provide a Close button, you won't be in
> compliance with WCAG level A criteria.
>
>
>
> 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
> > > at http://webaim.org/discussion/archives
> >
> > > > >

From: chaals@yandex-team.ru
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.
>>
>>  -----Original Message-----
>>  From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On
>>  Behalf Of Ramakrishnan Subramanian
>>  Sent: Tuesday, January 31, 2017 12:20 PM
>>  To: = EMAIL ADDRESS REMOVED =
>>  Subject: [WebAIM] in a modal dialog can the tab focus go to the browser UI?
>>
>>  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.
>>
>>  That's typical as that is the standard behavior unless you restrict the
>>  user to the modal.
>>
>>  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.
>>
>>  You can do the above with ARIA. You won't be violating any WCAG criteria.
>>  Unless you provide a Close button to allow the user to return to the
>>  browser UI. If you do not provide a Close button, you won't be in
>>  compliance with WCAG level A criteria.
>>
>>  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
>>  >>  >>  at http://webaim.org/discussion/archives
>>  >>
>>  >>  >>  >>  >
> > > > -- 
Charles McCathie Nevile - standards - Yandex
= EMAIL ADDRESS REMOVED = - - - Find more at http://yandex.com

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

-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Lucy Greco
Sent: Tuesday, January 31, 2017 4:22 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] in a modal dialog can the tab focus go to the browser UI?

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.
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Ramakrishnan Subramanian
> Sent: Tuesday, January 31, 2017 12:20 PM
> To: = EMAIL ADDRESS REMOVED =
> Subject: [WebAIM] in a modal dialog can the tab focus go to the browser UI?
>
> 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.
>
> That's typical as that is the standard behavior unless you restrict
> the user to the modal.
>
> 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.
>
> You can do the above with ARIA. You won't be violating any WCAG criteria.
> Unless you provide a Close button to allow the user to return to the
> browser UI. If you do not provide a Close button, you won't be in
> compliance with WCAG level A criteria.
>
>
>
> 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
> > > archives at http://webaim.org/discussion/archives
> >
> > > archives at http://webaim.org/discussion/archives
> >

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