WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Non-interactive elements

for

From: Mallory
Date: May 8, 2020 8:23AM


Hi Sumit
the point of my long rambley post was to list which WCAG SCs I might use when writing a ticket about the bad practice of making an inert (non-interactive) element focusable.

In short, there isn't an SC that directly addresses this, and my personal feeling usually isn't to use 2.4.3 because the problem really isn't the *order*. Instead I tend to try to use one of the other WCAG SCs if I can.

If I have a client which insists that I only make tickets based on the WCAG, I throw up in a garbage can and decide I never want to waste my time auditing them again. Or instead, charge them a lot of money for pain and suffering.

cheers,
_mallory

On Thu, May 7, 2020, at 1:15 PM, Sumit Patel wrote:
> So, does it mean - If a non-interactive element is coming on tab
> focus, is it a best practice?
>
> On 07/05/2020, Mallory < <EMAIL REMOVED> > wrote:
> > I haven't tended to use 2.4.3 for that (usually it's very much in the
> > regular content and Tab order). Sometimes I set it under 4.1.2, with the
> > explanation that if I can focus it, it must be interactive and interactive
> > things need a name and role. Then in the recommendation of my ticket, if
> > they just threw tabindex="0" on random things like a span, I'd recommend
> > they remove the tabindex instead of trying to add a name and role to the
> > thing.
> >
> > If it can be mouse-clicked and it's focusable but I can't keyboard it,
> > 2.1.1.
> >
> > If it can be focussed and also doesn't show a focus outline, I can hit it
> > with 2.4.7. This includes when developers add a tabindex to a scrollable
> > region (which I encourage, since only Firefox does it automatically) so
> > keybaorders can scroll content: then I'll recommend they make that focus
> > visible, and since it's interactive I'll try to think of an appropriate name
> > and role for the area if they can't redesign the section to prevent having a
> > scrollable area. This also includes making a widget (like a tablist)
> > focusable, which might be how the widget is built instead of making one of
> > the tabs inside focusable. I'm okay with making the whole list a focusable
> > group, since once it has focus, users need to switch to arrows. It needs a
> > group name then in my opinion. Same for listboxes and other similar widgets.
> > If you don't feel that is right, then insist developers put focus on the
> > first (or active) control inside when users Tab to the widget, and never the
> > entire widget itself.
> >
> > In another mail someone argued that if you can focus on something but it
> > doesn't do anything with keyboard (and wouldn't anyway because it's
> > something inert like a container or a span), that could still go under
> > 2.1.1, but that SC is really about things users *can* interact with via a
> > mouse or something, but can't with keyboard.
> >
> > You could maybe also argue 2.4.1. The point of Bypass Blocks is to prevent
> > keyboarders from needing to Tab a thousand times to reach something. If
> > every page (or View in an SPA) happens to have the same focusable-but-inert
> > areas and users have to Tab past a bunch on every page to reach actual
> > content or controls, you could probably put it under the same reasoning as
> > Bypass Blocks (lots of Tab stops) but then suggest removing the
> > focusability, instead of adding a skip mechanism.
> >
> > In the end, WCAG doesn't explicitly say anything about being able to focus
> > on useless stuff. It only says that people *can* do things with keyboard
> > (and not even that it works following any particular expected pattern with
> > keyboard either). You either have to be creative or let it pass.
> >
> > This is why WCAG-only audits suck.
> >
> > cheers,
> > _mallory
> >
> > On Thu, May 7, 2020, at 10:11 AM, Sumit Patel wrote:
> >> Hi all,
> >>
> >> Hope you all are doing well....
> >>
> >> Today I came across through a discussion regarding Non-interactive
> >> elements coming on Tab focus. I was considering it as the violation of
> >> 2.4.3 . Is it fall into 2.4.3 or any other SC.
> >> Waiting for replies...
> >>
> >> And what about tab focus is going to interactive and non-interactive
> >> elements together?
> >> > >> > >> > >> > >>
> >
>