WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Mallory
Date: Jul 20, 2018 1:17PM

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
> > > >