E-mail List Archives

Search E-mail List Archives for

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

From: Sumit Patel
Date: Thu, May 07 2020 2:11AM
Subject: Non-interactive elements
No previous message | Next message →

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?

From: Mallory
Date: Thu, May 07 2020 3:55AM
Subject: Re: Non-interactive elements
← Previous message | Next message →

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

From: Sumit Patel
Date: Thu, May 07 2020 5:15AM
Subject: Re: Non-interactive elements
← Previous message | Next message →

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

From: glen walker
Date: Thu, May 07 2020 5:55PM
Subject: Re: Non-interactive elements
← Previous message | Next message →

I would say it's the opposite - a worst practice, not a best practice. Or
perhaps an anti-pattern.

Non-interactive elements shouldn't receive keyboard focus.

I can kind of see using 2.4.3 as the failure. I typically use 2.1.1 even
though as Mallory said, 2.1.1 is typically for things that should receive
keyboard focus, not for things that shouldn't.

As I've said on a few posts recently, even if you don't have the perfect
success criteria for the failure, the important thing is to report it.

On Thu, May 7, 2020 at 5:15 AM Sumit Patel < = EMAIL ADDRESS REMOVED = >
wrote:

> So, does it mean - If a non-interactive element is coming on tab
> focus, is it a best practice?
>
>

From: Murphy, Sean
Date: Thu, May 07 2020 6:22PM
Subject: Re: Non-interactive elements
← Previous message | Next message →

Tab focus is to perform an action. Non-interaction elements is for information. Placing keyboard focus on non-interactive items confuse people from my point of view.





Sean Murphy | Digital System specialist (Accessibility)
Telstra Digital Channels | Digital Systems
Mobile: 0405 129 739 | Desk: (02) 9866-7917

-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Sumit Patel
Sent: Thursday, 7 May 2020 9:15 PM
To: Mallory < = EMAIL ADDRESS REMOVED = >
Cc: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Non-interactive elements

[External Email] This email was sent from outside the organisation – be cautious, particularly with links and attachments.

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 ADDRESS 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?
>> >> >> archives at http://webaim.org/discussion/archives
>> >>
>

From: Mallory
Date: Fri, May 08 2020 8:23AM
Subject: Re: Non-interactive elements
← Previous message | No next message

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