RE: WCAG2.1 and keyboard navigation

I’ve found focusable, Scrollable divs (e.g., overflow:auto) to be pretty problematic from a screen reader perspective.  They are not useful to a screen reader user, and they generate a ton of speech that can be pretty confusing to users. I haven’t figured out a role and name that would remove that confusion. While they apparently provide functionality similar to a scrollbar, they don’t fit the definition of an ARIA scrollbar.

 

In some cases I’ve avoided the problem by removing their focusability and using a widget inside that provides scroll. For example, a grid that is navigable with arrow keys can scroll as focus moves from row to row. And, you can use page up and down to scroll a block of rows. That can satisfy the needs of both screen reader and keyboard users.

 

BTW, a grid is a good widget for a chat log. It can provide infinite scroll and a grid cell can contain any type of element.

 

Matt

 

From: Mitchell Evan <mtchllvn@gmail.com> 
Sent: Friday, August 21, 2020 6:31 AM
To: Marjanska, Martyna (SSC/SPC) <martyna.marjanska@canada.ca>
Cc: Matt King <a11ythinker@gmail.com>; 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

 

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 <mailto: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 <mailto: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 <https://www.youtube.com/watch?v=pHvMPSL_2CM&t=73s> &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 <mailto:mtchllvn@gmail.com> > 
Sent: August 21, 2020 4:44 AM
To: Matt King <a11ythinker@gmail.com <mailto:a11ythinker@gmail.com> >
Cc: Will Ringland <wringlan@epic.com <mailto:wringlan@epic.com> >; Amber Holladay <amber-holladay@pluralsight.com <mailto:amber-holladay@pluralsight.com> >; WAI Interest Group <w3c-wai-ig@w3.org <mailto:w3c-wai-ig@w3.org> >; Ginger Claassen <ginger.claassen@gmx.de <mailto: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 <mailto: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 <mailto: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 <mailto:wringlan@epic.com> > 
Sent: Wednesday, August 19, 2020 8:28 AM
To: Amber Holladay <amber-holladay@pluralsight.com <mailto:amber-holladay@pluralsight.com> >; w3c-wai-ig@w3.org <mailto:w3c-wai-ig@w3.org> 
Cc: Ginger Claassen <ginger.claassen@gmx.de <mailto: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 <mailto:amber-holladay@pluralsight.com> > 
Sent: Tuesday, January 21, 2020 1:17 PM
To: w3c-wai-ig@w3.org <mailto:w3c-wai-ig@w3.org> 
Cc: Ginger Claassen <ginger.claassen@gmx.de <mailto: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
> 
>