WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Non-interactive elements

for

From: Mallory
Date: May 7, 2020 3:55AM

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