Re: WCAG2.1 and keyboard navigation

Hi Martyna,

Good catch! Here's the challenge: A block element such as a <div> or
<section> becomes scrollable with CSS overflow:scroll or overflow:auto.
Some browsers automatically make the scrollable block tab focusable, but
other browsers don't.

To enable keyboard access for visual scrolling in all browsers, here are
some options:
(1) Ensure that there are nested links or buttons near the top and bottom
of the block's content, or
(2) Add tabindex=0 to the block element (as described in the video you
sent), or
(3) Slowest but best: convince browser developers to fix the underlying
problem. Example: https://www.chromestatus.com/feature/5231964663578624

Cheers,

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 Fri, Aug 21, 2020 at 2:49 PM Marjanska, Martyna (SSC/SPC) <
martyna.marjanska@canada.ca> wrote:

> I would have to agree, almost never.
>
> Another example when tab focus on text may be needed is chatbot. I am
> testing one at the moment.
>
> The conversations usually have 3 elements:
>
>    1. bot said
>    2. user said
>    3. date
>
> The conversations are non-interactive elements typically wrapped in <div>.
> The navigation between the conversations and conversation history is
> painful.
>
> The recommendation (https://www.youtube.com/watch?v=pHvMPSL_2CM&t=73s) is
> to wrap the conversation in <section> element to create regions with
> tabindex=0 to give focus. This way user can easily tab (shift tab) from one
> block of text to another.
>
>
>
> Please tell me if this is wrong, or maybe you have different solutions.
>
>
>
> Regards,
>
> Martyna
>
>
>
> *From:* Mitchell Evan <mtchllvn@gmail.com>
> *Sent:* August 21, 2020 4:44 AM
> *To:* Matt King <a11ythinker@gmail.com>
> *Cc:* Will Ringland <wringlan@epic.com>; Amber Holladay <
> amber-holladay@pluralsight.com>; WAI Interest Group <w3c-wai-ig@w3.org>;
> Ginger Claassen <ginger.claassen@gmx.de>
> *Subject:* 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
> >
> >
>
>