Re: WCAG2.1 and keyboard navigation

Patrick said correctly that non-interactive elements should almost
never be *tab
focusable.*

There's another special case worth mentioning: when necessary for focus
management, sometimes a non-interactive element needs to be *script
focusable*. I'm mentioning this because one instance does occur in the Modal
Dialog Example
<https://w3c.github.io/aria-practices/examples/dialog-modal/dialog.html>
page which Matt sent. The second dialog there has a paragraph
with tabindex=-1, making it script focusable but not tab focusable.

To be very clear, these are special cases only. Most text should not be
focusable.

Mitchell Evan
mtchllvn@gmail.com
linkedin.com/in/mitchellrevan <https://www.linkedin.com/in/mitchellrevan>
Twitter @mitchellrevan <https://twitter.com/mitchellrevan>
+49 1525 8950540
+1 510 375 6104


On Wed, Aug 19, 2020 at 8:11 PM Matt King <a11ythinker@gmail.com> wrote:

> Here’s an example of an accessible dialog:
>
> https://w3c.github.io/aria-practices/examples/dialog-modal/dialog.html
>
>
>
> As mentioned below, only include interactive elements in the Tab sequence,
> except in very rare circumstances, e.g., a disabled element where
> discoverability via Tab is critical to understanding.
>
>
>
> Matt King
>
>
>
> *From:* Will Ringland <wringlan@epic.com>
> *Sent:* Wednesday, August 19, 2020 8:28 AM
> *To:* Amber Holladay <amber-holladay@pluralsight.com>; w3c-wai-ig@w3.org
> *Cc:* Ginger Claassen <ginger.claassen@gmx.de>
> *Subject:* RE: WCAG2.1 and keyboard navigation
>
>
>
> I’d agree with Amber and add that screen read virtual cursor navigation
> should access all the component of the popup without needing to, say, add a
> tab stop to the text.
>
>
>
> For popups specifically, using the text in the popup to describe the popup
> container via “aria-describedby” aria  would ensure it is read when the
> popup appears even if focus is placed on a button within the popup. That
> way, you provide the text of the dialog without having to manipulate the
> text elements.
>
>
>
> Unclear if that is the best way to do it but we’ve had success doing it
> that way.
>
>
>
> Will Ringland
>
> All Epic Accessibility
>
> Accessible design is *Epic* design.
>
> *He/Him*
>
>
>
> *From:* Amber Holladay <amber-holladay@pluralsight.com>
> *Sent:* Tuesday, January 21, 2020 1:17 PM
> *To:* w3c-wai-ig@w3.org
> *Cc:* Ginger Claassen <ginger.claassen@gmx.de>
> *Subject:* Re: WCAG2.1 and keyboard navigation
>
>
>
> *External Mail.* Careful of links / attachments. Submit Helpdesk if
> unsure.
>
>
>
> All active and inactive elements must be in logical navigation order, only
> active elements must be in TAB order. For example, if the text and images
> on the page are not coded in the same order as they are visually, I may not
> be able to access the information in the logical navigation order while
> using a screen reader. I have seen this when something (the main menu, a
> popup dialog) is coded into the bottom of the page, but using CSS it
> visually appears somewhere else on the page. This forces screen reader
> users to navigate to the bottom of the page to access the information
> visually at the top.
>
>
>
> Something else to think about, if all elements are forced into the TAB
> order, a keyboard user would never know which elements are supposed to be
> active (clickable) and which are basic text, images, etc. Therefore,
> putting non-interactive elements into the TAB order creates a perceived
> "broken" or "inaccessible" link.
>
>
>
> On Tue, Jan 21, 2020 at 11:26 AM Marc Haunschild <
> haunschild@mhis.onmicrosoft.de> wrote:
>
> You’ve got already all information about how to meet the wcag success
> criterion. Beyond this I make sometimes elements focus able, to improve the
> user experience. For example an a-element without href Attribute in the
> navigation (usually representing the currently opened page). Here it seems
> for me important, that this particular text is not skipped, when tabbing
> through the page (of course it also should get aria-current="page").
>
> So while this is not essential to get a wcag compliance badge (what never
> should be, what you are aiming for), I’d recommend to make a few texts
> accessible for tabbing - but use it wise and rarely, else it would be more
> annoying than helpful...
>
> --
> Mit freundlichen Grüßen
>
> Marc Haunschild
> www.mhis.de
> <https://urldefense.com/v3/__http:/www.mhis.de__;!!BJMh1g!pLMEKA_ND7rntLolJNm4mVVihDi0q33O4EiS29Gj3yCd4IK2TGLtEsXi_1p_Nw$>
>
> > On 21. Jan 2020, at 13:11, Ginger Claassen <ginger.claassen@gmx.de>
> wrote:
> >
> > Hi folks,
> >
> >
> > I have a question regarding keyboard navigation and WCAG2.1. We had a
> > discussion today with one colleague who is blind and one who is visually
> > impaired (screen magnifier user).
> >
> > What exactly has to be in keyboard navigation - especially in a pop-up
> > dialogue. I, as a screen reader user, am of the opinion that only
> > interaction elements have to be keyboard navigateable and my colleague
> > is of the opinion that also the text in a dialogue box as well as text
> > in general has to be in the tab-order.
> >
> > Looking in the WCAG2.1 we were not sure how to interpret it: At one
> > point it says all elements have to be in tab-order and a bit further
> > down it says only interaction elements have to be in tab-order.
> >
> > Thus, is there a clear rule for this, is this rather weak and therefore
> > depends (both would be a pass) or is there a destinction missing between
> > SR and SM users?
> >
> >
> > I am looking forward for your expert opinions!
> >
> >
> > Solong and thx
> >
> >
> >      Ginger
> >
> >
>
>