WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Non-interactive elements

for

From: Sumit Patel
Date: May 7, 2020 5:15AM

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