WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: keyboard navigable photo gallery

for

From: Bryan Garaventa
Date: Jan 11, 2016 10:57PM


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 REMOVED> ] On Behalf Of isabel brison
Sent: Monday, January 11, 2016 7:25 PM
To: WebAIM Discussion List < <EMAIL 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 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 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