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<mailto: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<mailto: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
>
>