Re: WCAG2.1 and keyboard navigation

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

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

Received on Tuesday, 21 January 2020 18:20:01 UTC