WebAIM - Web Accessibility In Mind

E-mail List Archives

Thread: Firefox, about:cofig: "Browse with caret" required for accessibility?

for

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

From: Detlev Fischer
Date: Tue, Jul 17 2018 4:56AM
Subject: Firefox, about:cofig: "Browse with caret" required for accessibility?
No previous message | Next message →

A customer suggests I should turn off the flag
accessibility.browsewithcaret in Firefox' about:config settings so that
keyboard navigation in the site under test should work. Is that a
legitimite demand, or can it create accessibility problems for some users?

Any thoughts?

Best,
Detlev

--
Detlev Fischer
Testkreis
Werderstr. 34, 20144 Hamburg

Mobil +49 (0)157 57 57 57 45

http://www.testkreis.de
Beratung, Tests und Schulungen für barrierefreie Websites


---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus

From: Patrick H. Lauke
Date: Tue, Jul 17 2018 5:40AM
Subject: Re: Firefox, about:cofig: "Browse with caret" required for accessibility?
← Previous message | Next message →

On 17/07/2018 11:56, Detlev Fischer wrote:
> A customer suggests I should turn off the flag
> accessibility.browsewithcaret in Firefox' about:config settings so that
> keyboard navigation in the site under test should work. Is that a
> legitimite demand, or can it create accessibility problems for some users?

Browse with caret overrides (of conflicts with) any custom keyboard
handling that may be happening on the page, perhaps.

Caret browsing is needed for keyboard (no AT) users to be able to
arbitrarily move through and select text etc.

If AT was running, AT would be intercepting cursor key commands, unless
role="application" or specific roles (like role="menu" and a correctly
implemented ARIA menu structure) are present. However, pure caret
browsing without AT won't have those specific adaptations of when to act
on cursor keys or when to send the key commands only to the page.

In short, I think the scenario for caret browsing can be problematic.
The customer may be right. But I've no data about how many keyboard
users actually use/need caret browsing on (all the time), or if they
might enable it just when they need to do some arbitrary copy/paste
activity...

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: glen walker
Date: Tue, Jul 17 2018 3:00PM
Subject: Re: Firefox, about:cofig: "Browse with caret" required for accessibility?
← Previous message | Next message →

I agree with Patrick. Additionally, anytime you turn on or off some
feature that is useful for one person but problematic for another, you get
into a lose-lose situation. It's best left for the user to decide if they
want that feature on or off.

Glen

From: Mallory
Date: Thu, Jul 19 2018 3:42AM
Subject: Re: Firefox, about:cofig: "Browse with caret" required for accessibility?
← Previous message | Next message →

Why not let users turn it on and off as needed with f7? People who use caret nav experience right off the bat that it's generally not on by default. People who need it for stuff like text selection have to learn somewhere which browsers can even do it and how to turn it on.

I only turn it on when I want to do specific things because otherwise, at least on this machine (Ubuntu on a Thinkpad) it messes with page scrolling.

cheers,
Mallory

On Tue, Jul 17, 2018, at 11:00 PM, glen walker wrote:
> I agree with Patrick. Additionally, anytime you turn on or off some
> feature that is useful for one person but problematic for another, you get
> into a lose-lose situation. It's best left for the user to decide if they
> want that feature on or off.
>
> Glen
> > > >

From: Patrick H. Lauke
Date: Thu, Jul 19 2018 4:23AM
Subject: Re: Firefox, about:cofig: "Browse with caret" required for accessibility?
← Previous message | Next message →

On 19/07/2018 10:42, Mallory wrote:
> Why not let users turn it on and off as needed with f7? People who use caret nav experience right off the bat that it's generally not on by default. People who need it for stuff like text selection have to learn somewhere which browsers can even do it and how to turn it on.

But I think the core question here was: if a site doesn't work when
caret browsing is on, is that a failure (of WCAG in general, or more
generally of accessibility).

If a site relies in some way on cursor key use, and caret browsing
"steals" the cursor keys (or perhaps even worse, moves the caret BUT
also passes on the keypress to the page which then triggers JS there),
there's going to be problems. When AT is running, AT will disambiguate
whether it needs to react to cursor keys itself (by moving the
reading/accessibility focus) OR just pass on the keystroke to the page
(e.g. when inside a proper role="menu")...but I suspect pure caret
browsing without AT doesn't do anything clever like that, so things will
get funky. Whose fault is it? The browser's, the author's? I tend to
think it's the browser's, in this case...

> I only turn it on when I want to do specific things because otherwise, at least on this machine (Ubuntu on a Thinkpad) it messes with page scrolling.
>
> cheers,
> Mallory
>
> On Tue, Jul 17, 2018, at 11:00 PM, glen walker wrote:
>> I agree with Patrick. Additionally, anytime you turn on or off some
>> feature that is useful for one person but problematic for another, you get
>> into a lose-lose situation. It's best left for the user to decide if they
>> want that feature on or off.
>>
>> Glen
>> >> >> >> > > > > >


--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Mallory
Date: Thu, Jul 19 2018 10:47AM
Subject: Re: Firefox, about:cofig: "Browse with caret" required for accessibility?
← Previous message | Next message →

Ah, if that's the question, it's a good one. And it sounds like something that, if it's not a failure, could be turned into one (as single-character-key shortcuts did).

cheers,
_mallory

On Thu, Jul 19, 2018, at 12:23 PM, Patrick H. Lauke wrote:
> On 19/07/2018 10:42, Mallory wrote:
> > Why not let users turn it on and off as needed with f7? People who use caret nav experience right off the bat that it's generally not on by default. People who need it for stuff like text selection have to learn somewhere which browsers can even do it and how to turn it on.
>
> But I think the core question here was: if a site doesn't work when
> caret browsing is on, is that a failure (of WCAG in general, or more
> generally of accessibility).
>
> If a site relies in some way on cursor key use, and caret browsing
> "steals" the cursor keys (or perhaps even worse, moves the caret BUT
> also passes on the keypress to the page which then triggers JS there),
> there's going to be problems. When AT is running, AT will disambiguate
> whether it needs to react to cursor keys itself (by moving the
> reading/accessibility focus) OR just pass on the keystroke to the page
> (e.g. when inside a proper role="menu")...but I suspect pure caret
> browsing without AT doesn't do anything clever like that, so things will
> get funky. Whose fault is it? The browser's, the author's? I tend to
> think it's the browser's, in this case...
>
> > I only turn it on when I want to do specific things because otherwise, at least on this machine (Ubuntu on a Thinkpad) it messes with page scrolling.
> >
> > cheers,
> > Mallory
> >
> > On Tue, Jul 17, 2018, at 11:00 PM, glen walker wrote:
> >> I agree with Patrick. Additionally, anytime you turn on or off some
> >> feature that is useful for one person but problematic for another, you get
> >> into a lose-lose situation. It's best left for the user to decide if they
> >> want that feature on or off.
> >>
> >> Glen
> >> > >> > >> > >> > > > > > > > > > >
>
>
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > >

From: Patrick H. Lauke
Date: Thu, Jul 19 2018 11:31AM
Subject: Re: Firefox, about:cofig: "Browse with caret" required for accessibility?
← Previous message | Next message →

On 19/07/2018 17:47, Mallory wrote:
> Ah, if that's the question, it's a good one. And it sounds like something that, if it's not a failure, could be turned into one (as single-character-key shortcuts did).

However, how do you square that circle with things like ARIA patterns?
If the pattern demands that, for instance, cursor keys are used to
navigate up/down in a menu, then failing can't really fail this sort of
thing if it has weird side effects when caret browsing is
enabled...unless you'd expect a site to offer two separate modes of
navigation through menus (one just in case a caret browsing user tries
to use the menu as well)?

P

> cheers,
> _mallory
>
> On Thu, Jul 19, 2018, at 12:23 PM, Patrick H. Lauke wrote:
>> On 19/07/2018 10:42, Mallory wrote:
>>> Why not let users turn it on and off as needed with f7? People who use caret nav experience right off the bat that it's generally not on by default. People who need it for stuff like text selection have to learn somewhere which browsers can even do it and how to turn it on.
>>
>> But I think the core question here was: if a site doesn't work when
>> caret browsing is on, is that a failure (of WCAG in general, or more
>> generally of accessibility).
>>
>> If a site relies in some way on cursor key use, and caret browsing
>> "steals" the cursor keys (or perhaps even worse, moves the caret BUT
>> also passes on the keypress to the page which then triggers JS there),
>> there's going to be problems. When AT is running, AT will disambiguate
>> whether it needs to react to cursor keys itself (by moving the
>> reading/accessibility focus) OR just pass on the keystroke to the page
>> (e.g. when inside a proper role="menu")...but I suspect pure caret
>> browsing without AT doesn't do anything clever like that, so things will
>> get funky. Whose fault is it? The browser's, the author's? I tend to
>> think it's the browser's, in this case...
>>
>>> I only turn it on when I want to do specific things because otherwise, at least on this machine (Ubuntu on a Thinkpad) it messes with page scrolling.
>>>
>>> cheers,
>>> Mallory
>>>
>>> On Tue, Jul 17, 2018, at 11:00 PM, glen walker wrote:
>>>> I agree with Patrick. Additionally, anytime you turn on or off some
>>>> feature that is useful for one person but problematic for another, you get
>>>> into a lose-lose situation. It's best left for the user to decide if they
>>>> want that feature on or off.
>>>>
>>>> Glen
>>>> >>>> >>>> >>>> >>> >>> >>> >>> >>>
>>
>>
>> --
>> Patrick H. Lauke
>>
>> www.splintered.co.uk | https://github.com/patrickhlauke
>> http://flickr.com/photos/redux/ | http://redux.deviantart.com
>> twitter: @patrick_h_lauke | skype: patrick_h_lauke
>> >> >> >> > > > > >


--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Mallory
Date: Fri, Jul 20 2018 1:17PM
Subject: Re: Firefox, about:cofig: "Browse with caret" required for accessibility?
← Previous message | No next message

I would put the onus on the user for having caret browsing on while in a menu that, like a select, needs to be navigated by JS'd arrow keys. I would not blame or fail the webpage in that specific instance. There are browser plugins that can break stuff too.

And as Glen says, users who have it on generally turned it on. They can turn it off (and if they want to use pgUp/pfDwn or do faster page scrolling, they do anyway, or at least I have to).

But there may be some other places where it's not so clear.

cheers,
_mallory

On Thu, Jul 19, 2018, at 7:31 PM, Patrick H. Lauke wrote:
> On 19/07/2018 17:47, Mallory wrote:
> > Ah, if that's the question, it's a good one. And it sounds like something that, if it's not a failure, could be turned into one (as single-character-key shortcuts did).
>
> However, how do you square that circle with things like ARIA patterns?
> If the pattern demands that, for instance, cursor keys are used to
> navigate up/down in a menu, then failing can't really fail this sort of
> thing if it has weird side effects when caret browsing is
> enabled...unless you'd expect a site to offer two separate modes of
> navigation through menus (one just in case a caret browsing user tries
> to use the menu as well)?
>
> P
>
> > cheers,
> > _mallory
> >
> > On Thu, Jul 19, 2018, at 12:23 PM, Patrick H. Lauke wrote:
> >> On 19/07/2018 10:42, Mallory wrote:
> >>> Why not let users turn it on and off as needed with f7? People who use caret nav experience right off the bat that it's generally not on by default. People who need it for stuff like text selection have to learn somewhere which browsers can even do it and how to turn it on.
> >>
> >> But I think the core question here was: if a site doesn't work when
> >> caret browsing is on, is that a failure (of WCAG in general, or more
> >> generally of accessibility).
> >>
> >> If a site relies in some way on cursor key use, and caret browsing
> >> "steals" the cursor keys (or perhaps even worse, moves the caret BUT
> >> also passes on the keypress to the page which then triggers JS there),
> >> there's going to be problems. When AT is running, AT will disambiguate
> >> whether it needs to react to cursor keys itself (by moving the
> >> reading/accessibility focus) OR just pass on the keystroke to the page
> >> (e.g. when inside a proper role="menu")...but I suspect pure caret
> >> browsing without AT doesn't do anything clever like that, so things will
> >> get funky. Whose fault is it? The browser's, the author's? I tend to
> >> think it's the browser's, in this case...
> >>
> >>> I only turn it on when I want to do specific things because otherwise, at least on this machine (Ubuntu on a Thinkpad) it messes with page scrolling.
> >>>
> >>> cheers,
> >>> Mallory
> >>>
> >>> On Tue, Jul 17, 2018, at 11:00 PM, glen walker wrote:
> >>>> I agree with Patrick. Additionally, anytime you turn on or off some
> >>>> feature that is useful for one person but problematic for another, you get
> >>>> into a lose-lose situation. It's best left for the user to decide if they
> >>>> want that feature on or off.
> >>>>
> >>>> Glen
> >>>> > >>>> > >>>> > >>>> > >>> > >>> > >>> > >>> > >>>
> >>
> >>
> >> --
> >> Patrick H. Lauke
> >>
> >> www.splintered.co.uk | https://github.com/patrickhlauke
> >> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> >> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> >> > >> > >> > >> > > > > > > > > > >
>
>
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > >