Re: Duplicate Accesskey Values

Hi John,

I agree that it would be useful for the error correction to be clear. I suspect it is defined somewhere, but someone with better knowledge on the HTML spec would need to say where (or that it isn’t).

Sure, it is the ID values that must be unique, but that is for IDs, not all attributes. Therefore, it doesn’t come under 4.1.1.

Kind regards,

-Alastair



From: John Foliot <
Hi Alastair,

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

I haven't tested it either, but I am slightly concerned that error/conflict resolution is unclear - the assumption that the first instance of invoking the accesskey is the "hot" instance is just that, an assumption. Hopefully all browsers will do error handling the same way(*), but not all user-agents are "browsers" in the traditional sense, and in my work with ePubs I think it would be a bit of a stretch to say all ePub readers are browsers (for example, Adobe's Digital Editions is a stand alone reader - it likely invokes an (x)HTML parsing engine under the hood but it is a specialize user-agent nonetheless.)

(* A review of the spec does not speak to conflict resolution:
https://html.spec.whatwg.org/multipage/interaction.html#keyboard-shortcuts-processing-model<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhtml.spec.whatwg.org%2Fmultipage%2Finteraction.html%23keyboard-shortcuts-processing-model&data=05%7C01%7Cacampbell%40nomensa.com%7C89b4f53cef5f49cbda7a08dadec02dbb%7Cebea4ad6fbbf43bd8449c56e26692c35%7C0%7C0%7C638067214238178946%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=TJCe5Ha6wJzemvd6r%2B4TFfwZo7etluOH1cfGevXwgWk%3D&reserved=0>)

Additionally, when we say "...and any IDs are unique..." in SC 4.1.1 what we *really* mean is that any ID values must be unique - it's the value of the ID that can cause a conflict, not simply the presence of "ID" in an element string.

JF

On Thu, Dec 15, 2022 at 11:51 AM Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>> wrote:
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"


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