E-mail List Archives

Search E-mail List Archives for

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

From: Ramya Sethuraman
Date: Fri, Aug 03 2012 5:00PM
Subject: Reg focus management for web application screen/layout changes.
No previous message | Next message →

Hi,

My question is about focus management for web accessibility. When we launch
a popup/dialog, does focus always need to go to the first focusable element
for accessibility reasons or is it acceptable to set focus on an element
that we think the user is more likely to want to work with?

For example, if a dialog starts with an input field and a cancel link
followed by a dropdown and we think the user would most likely want to work
with the dropdown when the dialog loads, is it ok to set focus on the
dropdown element? In this case, how would the user know about the previous
focusable elements existing on the dialog? But, if the dropdown is where
80% of the users will want to be when the dialog is launched, it doesn't
make much sense placing focus on the initial input field...

Thoughts?


Thanks,

Ramya

From: Ryan Hemphill
Date: Sat, Aug 04 2012 8:20AM
Subject: Re: Reg focus management for web application screen/layout changes.
← Previous message | Next message →

This is a very interesting question. One of the things that this brings up
is the need to consider the fact that the popup (also called "modal") can
be used for a large variety of content - pretty much all the content that
you would see in a normal web page.

It is for this reason that I feel pretty strongly that you should be
handling your modal window content the same way you would focus on a normal
page, but let the user know about the focus change. I know there are
others that feel differently about this, but I would ask those that object
to take a look at the different ways that modal windows are being used out
in the wild these days. I think you will find that it demonstrates the
diversity I was referring to.

I think the most important thing, Ramya, is to let the user know that a
focus change has occurred, drop it at the top of the dialog/popup/modal and
give them a sense of where they have jumped to and the nature of the
content. I would also like to mention that while you might be tempted to
drop focus on a heading at the top of your popup, which would make sense -
don't. JAWS has a bug in 10, 11 and 12(not sure about 13) that will cause
it to read off as an empty text field.

With that, I'm off to vacation land. Have a good weekend, all!

Ryan

On Fri, Aug 3, 2012 at 7:00 PM, Ramya Sethuraman < = EMAIL ADDRESS REMOVED =
> wrote:

> Hi,
>
> My question is about focus management for web accessibility. When we launch
> a popup/dialog, does focus always need to go to the first focusable element
> for accessibility reasons or is it acceptable to set focus on an element
> that we think the user is more likely to want to work with?
>
> For example, if a dialog starts with an input field and a cancel link
> followed by a dropdown and we think the user would most likely want to work
> with the dropdown when the dialog loads, is it ok to set focus on the
> dropdown element? In this case, how would the user know about the previous
> focusable elements existing on the dialog? But, if the dropdown is where
> 80% of the users will want to be when the dialog is launched, it doesn't
> make much sense placing focus on the initial input field...
>
> Thoughts?
>
>
> Thanks,
>
> Ramya
> > > >



--



Shipping is a Feature...Perhaps the Most Important Feature.

From: Ramya Sethuraman
Date: Sat, Aug 04 2012 9:42AM
Subject: Re: Reg focus management for web application screen/layout changes.
← Previous message | Next message →

Thanks for the info but I think my question is slightly different: more
details in this stackoverflow post I made:
http://stackoverflow.com/questions/11804257/web-accessibility-does-it-make-sense-for-focus-to-go-to-another-element-other-t/11804950#comment15694876_11804950


On Sat, Aug 4, 2012 at 10:20 AM, Ryan Hemphill < = EMAIL ADDRESS REMOVED =
> wrote:

> This is a very interesting question. One of the things that this brings up
> is the need to consider the fact that the popup (also called "modal") can
> be used for a large variety of content - pretty much all the content that
> you would see in a normal web page.
>
> It is for this reason that I feel pretty strongly that you should be
> handling your modal window content the same way you would focus on a normal
> page, but let the user know about the focus change. I know there are
> others that feel differently about this, but I would ask those that object
> to take a look at the different ways that modal windows are being used out
> in the wild these days. I think you will find that it demonstrates the
> diversity I was referring to.
>
> I think the most important thing, Ramya, is to let the user know that a
> focus change has occurred, drop it at the top of the dialog/popup/modal and
> give them a sense of where they have jumped to and the nature of the
> content. I would also like to mention that while you might be tempted to
> drop focus on a heading at the top of your popup, which would make sense -
> don't. JAWS has a bug in 10, 11 and 12(not sure about 13) that will cause
> it to read off as an empty text field.
>
> With that, I'm off to vacation land. Have a good weekend, all!
>
> Ryan
>
> On Fri, Aug 3, 2012 at 7:00 PM, Ramya Sethuraman <
> = EMAIL ADDRESS REMOVED =
> > wrote:
>
> > Hi,
> >
> > My question is about focus management for web accessibility. When we
> launch
> > a popup/dialog, does focus always need to go to the first focusable
> element
> > for accessibility reasons or is it acceptable to set focus on an element
> > that we think the user is more likely to want to work with?
> >
> > For example, if a dialog starts with an input field and a cancel link
> > followed by a dropdown and we think the user would most likely want to
> work
> > with the dropdown when the dialog loads, is it ok to set focus on the
> > dropdown element? In this case, how would the user know about the
> previous
> > focusable elements existing on the dialog? But, if the dropdown is where
> > 80% of the users will want to be when the dialog is launched, it doesn't
> > make much sense placing focus on the initial input field...
> >
> > Thoughts?
> >
> >
> > Thanks,
> >
> > Ramya
> > > > > > > >
>
>
>
> --
>
>
>
> Shipping is a Feature...Perhaps the Most Important Feature.
> > > >



--
*I also exist @: http://www.ramyasethuraman.com*

From: Stella Mudd
Date: Sat, Aug 04 2012 12:25PM
Subject: Re: Reg focus management for web application screen/layout changes.
← Previous message | Next message →

Ramya, for me, it always depends on context. What type of app is this, who
is it for, what is the current and surrounding information, etc.? For most
of my dialog with forms, I typically focus the first input by default even
if the majority gravitate toward the following input. There is no
steadfast rule for accessibility, only that there are no *barriers* to
access. I would think your users will find the drop-down it if it directly
proceeds, but users looking for a preceding input may find it difficult to
find. However, your situation might be different. What I suggest is to
turn on a screen reader, turn off the monitor, and have someone who doesn't
know your app try to use it with the tab/arrow keys. Can they find what
they are looking for? If so, then a screen reader user probably can too.
Do whatever works for your users.

Best,
Stella

On Sat, Aug 4, 2012 at 8:42 AM, Ramya Sethuraman < = EMAIL ADDRESS REMOVED =
> wrote:

> Thanks for the info but I think my question is slightly different: more
> details in this stackoverflow post I made:
>
> http://stackoverflow.com/questions/11804257/web-accessibility-does-it-make-sense-for-focus-to-go-to-another-element-other-t/11804950#comment15694876_11804950
>
>
> On Sat, Aug 4, 2012 at 10:20 AM, Ryan Hemphill <
> = EMAIL ADDRESS REMOVED =
> > wrote:
>
> > This is a very interesting question. One of the things that this brings
> up
> > is the need to consider the fact that the popup (also called "modal") can
> > be used for a large variety of content - pretty much all the content that
> > you would see in a normal web page.
> >
> > It is for this reason that I feel pretty strongly that you should be
> > handling your modal window content the same way you would focus on a
> normal
> > page, but let the user know about the focus change. I know there are
> > others that feel differently about this, but I would ask those that
> object
> > to take a look at the different ways that modal windows are being used
> out
> > in the wild these days. I think you will find that it demonstrates the
> > diversity I was referring to.
> >
> > I think the most important thing, Ramya, is to let the user know that a
> > focus change has occurred, drop it at the top of the dialog/popup/modal
> and
> > give them a sense of where they have jumped to and the nature of the
> > content. I would also like to mention that while you might be tempted to
> > drop focus on a heading at the top of your popup, which would make sense
> -
> > don't. JAWS has a bug in 10, 11 and 12(not sure about 13) that will
> cause
> > it to read off as an empty text field.
> >
> > With that, I'm off to vacation land. Have a good weekend, all!
> >
> > Ryan
> >
> > On Fri, Aug 3, 2012 at 7:00 PM, Ramya Sethuraman <
> > = EMAIL ADDRESS REMOVED =
> > > wrote:
> >
> > > Hi,
> > >
> > > My question is about focus management for web accessibility. When we
> > launch
> > > a popup/dialog, does focus always need to go to the first focusable
> > element
> > > for accessibility reasons or is it acceptable to set focus on an
> element
> > > that we think the user is more likely to want to work with?
> > >
> > > For example, if a dialog starts with an input field and a cancel link
> > > followed by a dropdown and we think the user would most likely want to
> > work
> > > with the dropdown when the dialog loads, is it ok to set focus on the
> > > dropdown element? In this case, how would the user know about the
> > previous
> > > focusable elements existing on the dialog? But, if the dropdown is
> where
> > > 80% of the users will want to be when the dialog is launched, it
> doesn't
> > > make much sense placing focus on the initial input field...
> > >
> > > Thoughts?
> > >
> > >
> > > Thanks,
> > >
> > > Ramya
> > > > > > > > > > > >
> >
> >
> >
> > --
> >
> >
> >
> > Shipping is a Feature...Perhaps the Most Important Feature.
> > > > > > > >
>
>
>
> --
> *I also exist @: http://www.ramyasethuraman.com*
> > > >

From: Ramya Sethuraman
Date: Mon, Aug 06 2012 12:58PM
Subject: Re: Reg focus management for web application screen/layout changes.
← Previous message | Next message →

That makes sense, Stella. I think for my use case, an iPhone app where
users know the general layout of the popup from repeated use, it probably
makes sense to put focus on the element they would pick 90% of the time
instead of the preceding links. I don't think this constitutes barrier to
access but I do think placing focus on the first less likely link reduces
usability of the app for screen reader, keyboard only users...

On Sat, Aug 4, 2012 at 2:25 PM, Stella Mudd < = EMAIL ADDRESS REMOVED = > wrote:

> Ramya, for me, it always depends on context. What type of app is this, who
> is it for, what is the current and surrounding information, etc.? For most
> of my dialog with forms, I typically focus the first input by default even
> if the majority gravitate toward the following input. There is no
> steadfast rule for accessibility, only that there are no *barriers* to
> access. I would think your users will find the drop-down it if it directly
> proceeds, but users looking for a preceding input may find it difficult to
> find. However, your situation might be different. What I suggest is to
> turn on a screen reader, turn off the monitor, and have someone who doesn't
> know your app try to use it with the tab/arrow keys. Can they find what
> they are looking for? If so, then a screen reader user probably can too.
> Do whatever works for your users.
>
> Best,
> Stella
>
> On Sat, Aug 4, 2012 at 8:42 AM, Ramya Sethuraman <
> = EMAIL ADDRESS REMOVED =
> > wrote:
>
> > Thanks for the info but I think my question is slightly different: more
> > details in this stackoverflow post I made:
> >
> >
> http://stackoverflow.com/questions/11804257/web-accessibility-does-it-make-sense-for-focus-to-go-to-another-element-other-t/11804950#comment15694876_11804950
> >
> >
> > On Sat, Aug 4, 2012 at 10:20 AM, Ryan Hemphill <
> > = EMAIL ADDRESS REMOVED =
> > > wrote:
> >
> > > This is a very interesting question. One of the things that this
> brings
> > up
> > > is the need to consider the fact that the popup (also called "modal")
> can
> > > be used for a large variety of content - pretty much all the content
> that
> > > you would see in a normal web page.
> > >
> > > It is for this reason that I feel pretty strongly that you should be
> > > handling your modal window content the same way you would focus on a
> > normal
> > > page, but let the user know about the focus change. I know there are
> > > others that feel differently about this, but I would ask those that
> > object
> > > to take a look at the different ways that modal windows are being used
> > out
> > > in the wild these days. I think you will find that it demonstrates the
> > > diversity I was referring to.
> > >
> > > I think the most important thing, Ramya, is to let the user know that a
> > > focus change has occurred, drop it at the top of the dialog/popup/modal
> > and
> > > give them a sense of where they have jumped to and the nature of the
> > > content. I would also like to mention that while you might be tempted
> to
> > > drop focus on a heading at the top of your popup, which would make
> sense
> > -
> > > don't. JAWS has a bug in 10, 11 and 12(not sure about 13) that will
> > cause
> > > it to read off as an empty text field.
> > >
> > > With that, I'm off to vacation land. Have a good weekend, all!
> > >
> > > Ryan
> > >
> > > On Fri, Aug 3, 2012 at 7:00 PM, Ramya Sethuraman <
> > > = EMAIL ADDRESS REMOVED =
> > > > wrote:
> > >
> > > > Hi,
> > > >
> > > > My question is about focus management for web accessibility. When we
> > > launch
> > > > a popup/dialog, does focus always need to go to the first focusable
> > > element
> > > > for accessibility reasons or is it acceptable to set focus on an
> > element
> > > > that we think the user is more likely to want to work with?
> > > >
> > > > For example, if a dialog starts with an input field and a cancel link
> > > > followed by a dropdown and we think the user would most likely want
> to
> > > work
> > > > with the dropdown when the dialog loads, is it ok to set focus on the
> > > > dropdown element? In this case, how would the user know about the
> > > previous
> > > > focusable elements existing on the dialog? But, if the dropdown is
> > where
> > > > 80% of the users will want to be when the dialog is launched, it
> > doesn't
> > > > make much sense placing focus on the initial input field...
> > > >
> > > > Thoughts?
> > > >
> > > >
> > > > Thanks,
> > > >
> > > > Ramya
> > > > > > > > > > > > > > > >
> > >
> > >
> > >
> > > --
> > >
> > >
> > >
> > > Shipping is a Feature...Perhaps the Most Important Feature.
> > > > > > > > > > > >
> >
> >
> >
> > --
> > *I also exist @: http://www.ramyasethuraman.com*
> > > > > > > >
> > > >



--
*I also exist @: http://www.ramyasethuraman.com*

From: Birkir R. Gunnarsson
Date: Wed, Aug 08 2012 1:31PM
Subject: Re: Reg focus management for web application screen/layout changes.
← Previous message | No next message

Hi

I think placing the focus on the first element is the most sensible
one. Screen reader users in general (well, in my experience), need
consistency and predictability, to the extent possible, and when you
start putting the focus and skipping elements they canot be aware of,
it may cause a lot of confusion.
Now whether the screen readers themselves need to reconsider their
approach to the web, to e.g. play a sound if the page is moving focus
to a field with other fields in-between (or announced, skiping over x
fields when that happens), is another topic for another discussion,
personally I am all for it.
But my point is, that if you are using a typical dropdown menu, the
user can get from it with one key stroke in most screen readers (c for
instance), using the SR's built-in navigation keys to jump to the next
element of a particular type, so you would really only be saving the
user one element (unless he or she has forms mode activated by
default). I think it'd be best to start the area of with a heading and
place the focus on there myself. If, for some reason, you are using
AJAX or ARIA implementation of a dropdown list, you might even want to
consider creating a shortcut key (I know this is not PC, some people
do not like access keys at all, but I still feel there are situations,
such as this one, where it actually does make some sense).
Just my 2 cents.
Thanks
-B

On 8/6/12, Ramya Sethuraman < = EMAIL ADDRESS REMOVED = > wrote:
> That makes sense, Stella. I think for my use case, an iPhone app where
> users know the general layout of the popup from repeated use, it probably
> makes sense to put focus on the element they would pick 90% of the time
> instead of the preceding links. I don't think this constitutes barrier to
> access but I do think placing focus on the first less likely link reduces
> usability of the app for screen reader, keyboard only users...
>
> On Sat, Aug 4, 2012 at 2:25 PM, Stella Mudd < = EMAIL ADDRESS REMOVED = > wrote:
>
>> Ramya, for me, it always depends on context. What type of app is this,
>> who
>> is it for, what is the current and surrounding information, etc.? For
>> most
>> of my dialog with forms, I typically focus the first input by default
>> even
>> if the majority gravitate toward the following input. There is no
>> steadfast rule for accessibility, only that there are no *barriers* to
>> access. I would think your users will find the drop-down it if it
>> directly
>> proceeds, but users looking for a preceding input may find it difficult
>> to
>> find. However, your situation might be different. What I suggest is to
>> turn on a screen reader, turn off the monitor, and have someone who
>> doesn't
>> know your app try to use it with the tab/arrow keys. Can they find what
>> they are looking for? If so, then a screen reader user probably can too.
>> Do whatever works for your users.
>>
>> Best,
>> Stella
>>
>> On Sat, Aug 4, 2012 at 8:42 AM, Ramya Sethuraman <
>> = EMAIL ADDRESS REMOVED =
>> > wrote:
>>
>> > Thanks for the info but I think my question is slightly different: more
>> > details in this stackoverflow post I made:
>> >
>> >
>> http://stackoverflow.com/questions/11804257/web-accessibility-does-it-make-sense-for-focus-to-go-to-another-element-other-t/11804950#comment15694876_11804950
>> >
>> >
>> > On Sat, Aug 4, 2012 at 10:20 AM, Ryan Hemphill <
>> > = EMAIL ADDRESS REMOVED =
>> > > wrote:
>> >
>> > > This is a very interesting question. One of the things that this
>> brings
>> > up
>> > > is the need to consider the fact that the popup (also called "modal")
>> can
>> > > be used for a large variety of content - pretty much all the content
>> that
>> > > you would see in a normal web page.
>> > >
>> > > It is for this reason that I feel pretty strongly that you should be
>> > > handling your modal window content the same way you would focus on a
>> > normal
>> > > page, but let the user know about the focus change. I know there are
>> > > others that feel differently about this, but I would ask those that
>> > object
>> > > to take a look at the different ways that modal windows are being
>> > > used
>> > out
>> > > in the wild these days. I think you will find that it demonstrates
>> > > the
>> > > diversity I was referring to.
>> > >
>> > > I think the most important thing, Ramya, is to let the user know that
>> > > a
>> > > focus change has occurred, drop it at the top of the
>> > > dialog/popup/modal
>> > and
>> > > give them a sense of where they have jumped to and the nature of the
>> > > content. I would also like to mention that while you might be
>> > > tempted
>> to
>> > > drop focus on a heading at the top of your popup, which would make
>> sense
>> > -
>> > > don't. JAWS has a bug in 10, 11 and 12(not sure about 13) that will
>> > cause
>> > > it to read off as an empty text field.
>> > >
>> > > With that, I'm off to vacation land. Have a good weekend, all!
>> > >
>> > > Ryan
>> > >
>> > > On Fri, Aug 3, 2012 at 7:00 PM, Ramya Sethuraman <
>> > > = EMAIL ADDRESS REMOVED =
>> > > > wrote:
>> > >
>> > > > Hi,
>> > > >
>> > > > My question is about focus management for web accessibility. When
>> > > > we
>> > > launch
>> > > > a popup/dialog, does focus always need to go to the first focusable
>> > > element
>> > > > for accessibility reasons or is it acceptable to set focus on an
>> > element
>> > > > that we think the user is more likely to want to work with?
>> > > >
>> > > > For example, if a dialog starts with an input field and a cancel
>> > > > link
>> > > > followed by a dropdown and we think the user would most likely want
>> to
>> > > work
>> > > > with the dropdown when the dialog loads, is it ok to set focus on
>> > > > the
>> > > > dropdown element? In this case, how would the user know about the
>> > > previous
>> > > > focusable elements existing on the dialog? But, if the dropdown is
>> > where
>> > > > 80% of the users will want to be when the dialog is launched, it
>> > doesn't
>> > > > make much sense placing focus on the initial input field...
>> > > >
>> > > > Thoughts?
>> > > >
>> > > >
>> > > > Thanks,
>> > > >
>> > > > Ramya
>> > > > >> > > > >> > > > >> > > >
>> > >
>> > >
>> > >
>> > > --
>> > >
>> > >
>> > >
>> > > Shipping is a Feature...Perhaps the Most Important Feature.
>> > > >> > > >> > > >> > >
>> >
>> >
>> >
>> > --
>> > *I also exist @: http://www.ramyasethuraman.com*
>> > >> > >> > >> >
>> >> >> >>
>
>
>
> --
> *I also exist @: http://www.ramyasethuraman.com*
> > > >