Re: Duplicate Accesskey Values

Hi John,

The only scenario I can think of is if the accesskey were the only way to do a function with the keyboard. E.g. The link with accesskey is present but not in the focus order. Then the second one with the same accesskey value would fail 2.1.1 as it doesn’t work.

(I haven’t tested it, but I assume the second one fails to activate if they have the same value?)

Otherwise, the ability to achieve the function will be available as it is a feature on the page. The accesskey is a faster way of doing it, but not the only way. I can’t think of anything that would fail.

I don’t think it fails 4.1.1 Parsing because, as you said, a duplicate attribute value isn’t in scope.

HTH,

-Alastair


From: John Foliot
Hi All,

Putting aside the fact that Accesskeys are, in context, fairly rare today, I am wondering what others do when they encounter two unique controls that share the same accesskey value.

I've gone through all of WCAG 2.x multiple times, and this use case doesn't seem to have surfaced. The closest analogy I can find is SC 4.1.2, where (I argue) a duplicate Accesskey Value has the same functional impact as a duplicate ID value: i.e. two unique things that share the same trigger mechanism, and no way to address conflict resolution. Currently SC 4.1.2 states "...elements do not contain duplicate attributes..." but the issue isn't a duplicate attribute, but rather a duplicate attribute VALUE. (FWIW, I do note that axe-core's rule set currently calls this out as a Best Practice).

Polling your thoughts - would you fail a duplicate Accesskey value under SC 4.1.2, despite the fact that duplicate Accesskey values are not specifically called out in that SC?

JF
--
John Foliot |
Senior Industry Specialist, Digital Accessibility |
W3C Accessibility Standards Contributor |
"I made this so long because I did not have time to make it shorter." - Pascal "links go places, buttons do things"