WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: WebAIM-Forum Digest, Vol 189, Issue 19

for

From: Brooks Newton
Date: Dec 31, 2020 1:04PM

Like Birkir, I'd call tab stops on static text a failure every time. From
my personal view, it is not permissible to include non-interactive elements
in the page focus order and have the page WCAG-compliant. I understand and
accept that others disagree.

Here's how I get to my conclusion to exclude non-interactive elements from
the focus order using the normative language in S.C. 2.4.3 Focus Order:

The normative text from this S.C. reads " If a Web page can be navigated
sequentially and the navigation sequences affect meaning or operation,
focusable components receive focus in an order that preserves meaning and
operability." I think including non-interactive elements in the navigation
sequence definitely affects the meaning or operation of focusable
components. People expect page components that receive focus to be
interactive. When they encounter an interface component with tab stops
that aren't actionable, they give up trying to interact with it.
Effectively, including non-actionable focusable elements in the page focus
order, can make the component inoperable because the users expectation of
the meaning of tab stops isn't met and they think the interface is broken.

Here's another way I get to that conclusion that non-interactive elements
should be excluded from the page focus order, this time as interpreted
through the informative language in S.C. 2.4.7 Focus Visible:

Can we all agree that all elements in the page focus order require a
visible focus indicator under S.C. 2.4.7 Focus Visible? One of the stated
benefits in the Understanding Document for S.C. 2.4.7 Focus Visible says
the following: "This Success Criterion helps anyone who relies on the
keyboard to operate the page, by letting them visually determine the
component on which keyboard operations will interact at any point in
time." If you place a visual focus indicator (VFI) on focusable
non-interactive elements to maintain the continuity of the VFI in the page
focus order, you are tricking users. You are tricking users by failing to
meet the explicit SC benefit and associated user expectation that elements
with visible focus indication are keyboard operable.

Just my two cents.

Brooks

<http://www.avg.com/email-signature?utm_medium=email&;utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.
www.avg.com
<http://www.avg.com/email-signature?utm_medium=email&;utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#m_-2617979330802611193_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Thu, Dec 31, 2020 at 1:03 PM < <EMAIL REMOVED> >
wrote:

> Send WebAIM-Forum mailing list submissions to
> <EMAIL REMOVED>
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://list.webaim.org/mailman/listinfo/webaim-forum
> or, via email, send a message with subject or body 'help' to
> <EMAIL REMOVED>
>
> You can reach the person managing the list at
> <EMAIL REMOVED>
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of WebAIM-Forum digest..."
> Today's Topics:
>
> 1. Re: WCAG - Fail or not to - Static text tab-focusable in
> tables (Patrick H. Lauke)
> 2. Re: WCAG - Fail or not to - Static text tab-focusable in
> tables (Sailesh Panchang)
> 3. Re: WCAG - Fail or not to - Static text tab-focusable in
> tables (Birkir R. Gunnarsson)
>
>
>
> ---------- Forwarded message ----------
> From: "Patrick H. Lauke" < <EMAIL REMOVED> >
> To: <EMAIL REMOVED>
> Cc:
> Bcc:
> Date: Thu, 31 Dec 2020 13:25:58 +0000
> Subject: Re: [WebAIM] WCAG - Fail or not to - Static text tab-focusable in
> tables
> On 30/12/2020 15:39, Sailesh Panchang wrote:
>
> > SC 2.4.3 reads: If a Web page can be navigated sequentially and the
> > navigation sequences affect meaning or operation, focusable components
> > receive focus in an order that preserves meaning and operability.
> >
> > Yes, navigation sequences affect meaning or operation when it
> > needlessly navigates to static content.
>
> The *order* seems to be meaningfully correct though. In terms of
> operation, it makes it more tedious to operate, but it doesn't *affect*
> operation in terms of not making it operable.
>
> 2.1.1 specifies that things need to be operable with a keyboard. Again,
> it doesn't say *how*, or that it must be nice/easy. So 2.1.1 would also
> not fail, normatively.
>
> Long story short, I'd lean towards: doesn't actually hard-fail any WCAG
> SC, but is still horrible usability and should be noted as a best
> practice advice.
>
> P
> --
> Patrick H. Lauke
>
> https://www.splintered.co.uk/ | https://github.com/patrickhlauke
> https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
>
>
>
>
> ---------- Forwarded message ----------
> From: Sailesh Panchang < <EMAIL REMOVED> >
> To: WebAIM Discussion List < <EMAIL REMOVED> >
> Cc:
> Bcc:
> Date: Thu, 31 Dec 2020 09:48:32 -0500
> Subject: Re: [WebAIM] WCAG - Fail or not to - Static text tab-focusable in
> tables
> I encourage the and patient readers to browse through the WebAim
> thread started in Nov/2015 and later on had some posts in 2017:
> "[WebAIM] Misuse of TabIndex 0"
> Thanks and best wishes,
> Sailesh
>
>
> On 12/31/20, Patrick H. Lauke < <EMAIL REMOVED> > wrote:
> > On 30/12/2020 15:39, Sailesh Panchang wrote:
> >
> >> SC 2.4.3 reads: If a Web page can be navigated sequentially and the
> >> navigation sequences affect meaning or operation, focusable components
> >> receive focus in an order that preserves meaning and operability.
> >>
> >> Yes, navigation sequences affect meaning or operation when it
> >> needlessly navigates to static content.
> >
> > The *order* seems to be meaningfully correct though. In terms of
> > operation, it makes it more tedious to operate, but it doesn't *affect*
> > operation in terms of not making it operable.
> >
> > 2.1.1 specifies that things need to be operable with a keyboard. Again,
> > it doesn't say *how*, or that it must be nice/easy. So 2.1.1 would also
> > not fail, normatively.
> >
> > Long story short, I'd lean towards: doesn't actually hard-fail any WCAG
> > SC, but is still horrible usability and should be noted as a best
> > practice advice.
> >
> > P
> > --
> > Patrick H. Lauke
> >
> > https://www.splintered.co.uk/ | https://github.com/patrickhlauke
> > https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
> > twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > > > > > > > >
>
>
> --
> Join me at axe-con 2021: a free digital accessibility conference. Read
> more at
> https://www.deque.com/axe-con/
> Feel free to contact Deque marketing if you have any questions. Thanks!
>
> Sailesh Panchang
> Principal Accessibility Consultant
> Deque Systems Inc
> 381 Elden Street, Suite 2000, Herndon, VA 20170
> Mobile: 571-344-1765
>
> ** Stay Positive Test Negative **
>
>
>
>
> ---------- Forwarded message ----------
> From: "Birkir R. Gunnarsson" < <EMAIL REMOVED> >
> To: WebAIM Discussion List < <EMAIL REMOVED> >
> Cc:
> Bcc:
> Date: Thu, 31 Dec 2020 11:42:39 -0500
> Subject: Re: [WebAIM] WCAG - Fail or not to - Static text tab-focusable in
> tables
> I guess it's the luxury of working with one program ;) I can use the
> "Birkir says it's a fail" without having to exercise WCAG gymnastics.
> I don't use it all the time, but for this problem I wouldn't allow it.
> *grin*
> One more creative option, again a longshot, is evoking 2.1.2 .. if the
> table has hundreds of static focusable elements I think one can argue
> that while it is not an absolute keyboard trap, for practical
> purposes, it acts as one for anyone who needs to navigate to functions
> further down the page.
> In fact, if the page is in an authenticated environment with session
> timeouts, it is possible that getting through the table would be so
> slow that the session times out, and then the user is sent back to the
> top of the page. In that situation it would be a keyboard trap.
> Again, the main issue is to file a bug with React and getting this
> resolved for future developers.
>
> On 12/31/20, Sailesh Panchang < <EMAIL REMOVED> > wrote:
> > I encourage the and patient readers to browse through the WebAim
> > thread started in Nov/2015 and later on had some posts in 2017:
> > "[WebAIM] Misuse of TabIndex 0"
> > Thanks and best wishes,
> > Sailesh
> >
> >
> > On 12/31/20, Patrick H. Lauke < <EMAIL REMOVED> > wrote:
> >> On 30/12/2020 15:39, Sailesh Panchang wrote:
> >>
> >>> SC 2.4.3 reads: If a Web page can be navigated sequentially and the
> >>> navigation sequences affect meaning or operation, focusable components
> >>> receive focus in an order that preserves meaning and operability.
> >>>
> >>> Yes, navigation sequences affect meaning or operation when it
> >>> needlessly navigates to static content.
> >>
> >> The *order* seems to be meaningfully correct though. In terms of
> >> operation, it makes it more tedious to operate, but it doesn't *affect*
> >> operation in terms of not making it operable.
> >>
> >> 2.1.1 specifies that things need to be operable with a keyboard. Again,
> >> it doesn't say *how*, or that it must be nice/easy. So 2.1.1 would also
> >> not fail, normatively.
> >>
> >> Long story short, I'd lean towards: doesn't actually hard-fail any WCAG
> >> SC, but is still horrible usability and should be noted as a best
> >> practice advice.
> >>
> >> P
> >> --
> >> Patrick H. Lauke
> >>
> >> https://www.splintered.co.uk/ | https://github.com/patrickhlauke
> >> https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
> >> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> >> > >> > >> > >> > >>
> >
> >
> > --
> > Join me at axe-con 2021: a free digital accessibility conference. Read
> more
> > at
> > https://www.deque.com/axe-con/
> > Feel free to contact Deque marketing if you have any questions. Thanks!
> >
> > Sailesh Panchang
> > Principal Accessibility Consultant
> > Deque Systems Inc
> > 381 Elden Street, Suite 2000, Herndon, VA 20170
> > Mobile: 571-344-1765
> >
> > ** Stay Positive Test Negative **
> > > > > > > > > >
>
>
> --
> Work hard. Have fun. Make history.
>
> > > > >

<http://www.avg.com/email-signature?utm_medium=email&;utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.
www.avg.com
<http://www.avg.com/email-signature?utm_medium=email&;utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>