E-mail List Archives

Search E-mail List Archives for

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

From: isabel brison
Date: Mon, Jan 11 2016 6:13PM
Subject: keyboard navigable photo gallery
No previous message | Next message →

Hi all,

I have a photo gallery that can be navigated with two buttons: "previous"
and "next". When the user reaches the last photo in the gallery, the "next"
button is set to "disabled" with JS. This causes issues with keyboard
navigation, as when the user clicks "next" to go to the last photo, their
focus is on that button, and when it becomes disabled, some browsers will
move focus to the top of the page (Chrome and IE do this, Firefox moves
focus to the next element in the tab order).

I'm wondering if anyone has tips as to the best way to handle focus in this
situation. Should I move it programmatically to the next element in the tab
order?

Also, is it best to use the disabled attribute in this situation, or would
a negative tabindex be better?

Cheers,

Isabel

--
http://isabelbrison.com

http://tellthemachines.com

From: Birkir R. Gunnarsson
Date: Mon, Jan 11 2016 7:26PM
Subject: Re: keyboard navigable photo gallery
← Previous message | Next message →

So are you saying that the act of setting the disabled attribute on
the button while it has focus causes browser scrolling? What happens
if you use Javascript to prevent default?
If that is impossible, technically you could use aria-disabled="true"
to present the button as unavailable to assistive technologies, and
use CSS to create a visual effect such as greying out the button, or
using an effect similar to the browser disabled element.
Just some thoughts, hope they help. This is an interesting problem.



On 1/11/16, isabel brison < = EMAIL ADDRESS REMOVED = > wrote:
> Hi all,
>
> I have a photo gallery that can be navigated with two buttons: "previous"
> and "next". When the user reaches the last photo in the gallery, the "next"
> button is set to "disabled" with JS. This causes issues with keyboard
> navigation, as when the user clicks "next" to go to the last photo, their
> focus is on that button, and when it becomes disabled, some browsers will
> move focus to the top of the page (Chrome and IE do this, Firefox moves
> focus to the next element in the tab order).
>
> I'm wondering if anyone has tips as to the best way to handle focus in this
> situation. Should I move it programmatically to the next element in the tab
> order?
>
> Also, is it best to use the disabled attribute in this situation, or would
> a negative tabindex be better?
>
> Cheers,
>
> Isabel
>
> --
> http://isabelbrison.com
>
> http://tellthemachines.com
> > > > >


--
Work hard. Have fun. Make history.

From: isabel brison
Date: Mon, Jan 11 2016 8:24PM
Subject: Re: keyboard navigable photo gallery
← Previous message | Next message →

Thanks for the prompt reply!

Setting the disabled attribute by itself doesn't cause scrolling but on
Chrome, when I next press the tab key, I'm taken to the first link on the
page. Only when that happens does the page scroll.

On Firefox, focus is transferred to the next focusable element, which to me
seems a more user-friendly behaviour. It would be possible to emulate that
for the other browsers with JS.

I haven't been able to find any documentation on this subject, and would
love to know what can be considered best practice in this situation.

On 12 January 2016 at 13:26, Birkir R. Gunnarsson <
= EMAIL ADDRESS REMOVED = > wrote:

> So are you saying that the act of setting the disabled attribute on
> the button while it has focus causes browser scrolling? What happens
> if you use Javascript to prevent default?
> If that is impossible, technically you could use aria-disabled="true"
> to present the button as unavailable to assistive technologies, and
> use CSS to create a visual effect such as greying out the button, or
> using an effect similar to the browser disabled element.
> Just some thoughts, hope they help. This is an interesting problem.
>
>
>
> On 1/11/16, isabel brison < = EMAIL ADDRESS REMOVED = > wrote:
> > Hi all,
> >
> > I have a photo gallery that can be navigated with two buttons: "previous"
> > and "next". When the user reaches the last photo in the gallery, the
> "next"
> > button is set to "disabled" with JS. This causes issues with keyboard
> > navigation, as when the user clicks "next" to go to the last photo, their
> > focus is on that button, and when it becomes disabled, some browsers will
> > move focus to the top of the page (Chrome and IE do this, Firefox moves
> > focus to the next element in the tab order).
> >
> > I'm wondering if anyone has tips as to the best way to handle focus in
> this
> > situation. Should I move it programmatically to the next element in the
> tab
> > order?
> >
> > Also, is it best to use the disabled attribute in this situation, or
> would
> > a negative tabindex be better?
> >
> > Cheers,
> >
> > Isabel
> >
> > --
> > http://isabelbrison.com
> >
> > http://tellthemachines.com
> > > > > > > > > >
>
>
> --
> Work hard. Have fun. Make history.
> > > > >



--
http://isabelbrison.com

http://tellthemachines.com

From: Bryan Garaventa
Date: Mon, Jan 11 2016 10:57PM
Subject: Re: keyboard navigable photo gallery
← Previous message | Next message →

Basically, when a natively active element that has focus is disabled, it is no longer focusable in the browser, so some browsers may allow focus to move to the next focusable element when tab is pressed, and others will simply start over by setting focus to the first focusable element on the page instead. After focus is lost in this way, it has to be manually reset if you want to maintain the same tab order using the JavaScript focus() method.

So, if you add one line of code to your script after the element.disabled statement, that uses element.focus() to set focus to the next intuitive focusable element, that should do the trick. E.G If you keep pressing Enter while focus is on a Previous button, which then becomes disabled when it can't go back any further, focus is then automatically moved to the Next button. Hopefully that example makes sense.

Best wishes,
Bryan


-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of isabel brison
Sent: Monday, January 11, 2016 7:25 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] keyboard navigable photo gallery

Thanks for the prompt reply!

Setting the disabled attribute by itself doesn't cause scrolling but on Chrome, when I next press the tab key, I'm taken to the first link on the page. Only when that happens does the page scroll.

On Firefox, focus is transferred to the next focusable element, which to me seems a more user-friendly behaviour. It would be possible to emulate that for the other browsers with JS.

I haven't been able to find any documentation on this subject, and would love to know what can be considered best practice in this situation.

On 12 January 2016 at 13:26, Birkir R. Gunnarsson < = EMAIL ADDRESS REMOVED = > wrote:

> So are you saying that the act of setting the disabled attribute on
> the button while it has focus causes browser scrolling? What happens
> if you use Javascript to prevent default?
> If that is impossible, technically you could use aria-disabled="true"
> to present the button as unavailable to assistive technologies, and
> use CSS to create a visual effect such as greying out the button, or
> using an effect similar to the browser disabled element.
> Just some thoughts, hope they help. This is an interesting problem.
>
>
>
> On 1/11/16, isabel brison < = EMAIL ADDRESS REMOVED = > wrote:
> > Hi all,
> >
> > I have a photo gallery that can be navigated with two buttons: "previous"
> > and "next". When the user reaches the last photo in the gallery, the
> "next"
> > button is set to "disabled" with JS. This causes issues with
> > keyboard navigation, as when the user clicks "next" to go to the
> > last photo, their focus is on that button, and when it becomes
> > disabled, some browsers will move focus to the top of the page
> > (Chrome and IE do this, Firefox moves focus to the next element in the tab order).
> >
> > I'm wondering if anyone has tips as to the best way to handle focus
> > in
> this
> > situation. Should I move it programmatically to the next element in
> > the
> tab
> > order?
> >
> > Also, is it best to use the disabled attribute in this situation, or
> would
> > a negative tabindex be better?
> >
> > Cheers,
> >
> > Isabel
> >
> > --
> > http://isabelbrison.com
> >
> > http://tellthemachines.com
> > > > > > archives at http://webaim.org/discussion/archives
> > > >
>
>
> --
> Work hard. Have fun. Make history.
> > > archives at http://webaim.org/discussion/archives
> >



--
http://isabelbrison.com

http://tellthemachines.com

From: _mallory
Date: Tue, Jan 12 2016 2:24AM
Subject: Re: keyboard navigable photo gallery
← Previous message | Next message →

Hi, this is pretty common in a lot of JS-scripted things like
lightboxes etc.

The best thing to do usually is find the most obvious place a
user would go next (this might be the "prev" button) and move
focus there manually. In my galleries, my buttons didn't get
disabled-- they'd completely disappear, so users no longer
got the visual feedback of "more." This meant I had to manage
focus, in my case on the "prev" buttons, where the next tab
would go to the next logical focus spot on the page (the close
button).

_mallory

On Tue, Jan 12, 2016 at 12:13:10PM +1100, isabel brison wrote:
> Hi all,
>
> I have a photo gallery that can be navigated with two buttons: "previous"
> and "next". When the user reaches the last photo in the gallery, the "next"
> button is set to "disabled" with JS. This causes issues with keyboard
> navigation, as when the user clicks "next" to go to the last photo, their
> focus is on that button, and when it becomes disabled, some browsers will
> move focus to the top of the page (Chrome and IE do this, Firefox moves
> focus to the next element in the tab order).
>
> I'm wondering if anyone has tips as to the best way to handle focus in this
> situation. Should I move it programmatically to the next element in the tab
> order?
>
> Also, is it best to use the disabled attribute in this situation, or would
> a negative tabindex be better?
>
> Cheers,
>
> Isabel
>
> --
> http://isabelbrison.com
>
> http://tellthemachines.com
> > > >

From: isabel brison
Date: Tue, Jan 12 2016 5:58PM
Subject: Re: keyboard navigable photo gallery
← Previous message | No next message

Thanks everyone!

I'm going with manually transferring focus back to the "previous" button
(or whichever button is not disabled at the time). Keeping focus within the
gallery makes sense as this component can be used in several different
contexts, so the next focusable element on the page could potentially be
anything.

On 12 January 2016 at 20:24, _mallory < = EMAIL ADDRESS REMOVED = > wrote:

> Hi, this is pretty common in a lot of JS-scripted things like
> lightboxes etc.
>
> The best thing to do usually is find the most obvious place a
> user would go next (this might be the "prev" button) and move
> focus there manually. In my galleries, my buttons didn't get
> disabled-- they'd completely disappear, so users no longer
> got the visual feedback of "more." This meant I had to manage
> focus, in my case on the "prev" buttons, where the next tab
> would go to the next logical focus spot on the page (the close
> button).
>
> _mallory
>
> On Tue, Jan 12, 2016 at 12:13:10PM +1100, isabel brison wrote:
> > Hi all,
> >
> > I have a photo gallery that can be navigated with two buttons: "previous"
> > and "next". When the user reaches the last photo in the gallery, the
> "next"
> > button is set to "disabled" with JS. This causes issues with keyboard
> > navigation, as when the user clicks "next" to go to the last photo, their
> > focus is on that button, and when it becomes disabled, some browsers will
> > move focus to the top of the page (Chrome and IE do this, Firefox moves
> > focus to the next element in the tab order).
> >
> > I'm wondering if anyone has tips as to the best way to handle focus in
> this
> > situation. Should I move it programmatically to the next element in the
> tab
> > order?
> >
> > Also, is it best to use the disabled attribute in this situation, or
> would
> > a negative tabindex be better?
> >
> > Cheers,
> >
> > Isabel
> >
> > --
> > http://isabelbrison.com
> >
> > http://tellthemachines.com
> > > > > > > > > > > > >



--
http://isabelbrison.com

http://tellthemachines.com