Re: Duplicate Accesskey Values

There is nothing in the HTML spec that forbids using the same accesskey, which allows what Oliver and Jon are describing: https://html.spec.whatwg.org/multipage/interaction.html#the-accesskey-attribute


So, it seems that it is following the rules of the formal grammar (and I agree with Alastair that it wouldn’t be an id either), so I also don’t believe that 4.1.1 would apply.

Thanks,
AWK

Andrew Kirkpatrick
Director, Accessibility
Adobe

akirkpat@adobe.com<mailto:akirkpat@adobe.com>
http://twitter.com/awkawk



From: John Foliot <john@foliot.ca>
Date: Thursday, December 15, 2022 at 1:16 PM
To: Alastair Campbell <acampbell@nomensa.com>
Cc: John Foliot <john@foliot.ca>, WAI-IG <w3c-wai-ig@w3.org>, WCAG <w3c-wai-gl@w3.org>
Subject: Re: Duplicate Accesskey Values
Resent-From: WCAG <w3c-wai-gl@w3.org>
Resent-Date: Thursday, December 15, 2022 at 1:16 PM


EXTERNAL: Use caution when clicking on links or opening attachments.


Alastair writes:
>  Therefore, it doesn’t come under 4.1.1.

Respectfully, that is your opinion (and yes I am seeking opinions), however it is important to remember that the title of SC 4.1.1 is "Parsing" and not "No Duplicate IDs".

The intent of this Success Criterion is to ensure that user agents, including assistive technologies, can accurately interpret and parse content. If the content cannot be parsed into a data structure, then different user agents may present it differently or be completely unable to parse it... Therefore, the Success Criterion requires that the content can be parsed using only the rules of the formal grammar.
(https://www.w3.org/WAI/WCAG21/Understanding/parsing.html<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FWAI%2FWCAG21%2FUnderstanding%2Fparsing.html&data=05%7C01%7Cakirkpat%40adobe.com%7C25e28656b4ce4f8219bf08dadec8778c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638067249827367267%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=HlTP1%2FMn3pVAArtm7MY90uj1CsczWXi0yTeu52Dkq7I%3D&reserved=0>)

To my mind then, this is clearly a potential parsing issue, because the rendering agent (and the DOM) will be provided with conflicting information via the attribute values (how can that NOT be a parsing issue?) - that the code snippet is not "...using the rules of the formal grammar."

Now, one could also argue that in this use-case, ALL users would be impacted negatively, and so it isn't just an "accessibility" issue, but rather a potential usability issue - and that would be a fair position to take as well.

So thank you for your opinion, but I am hopeful others will weigh in here as well (and, BTW, I presume your response is/was as a SME, and not on behalf of the WCAG Chairs).

JF

On Thu, Dec 15, 2022 at 12:29 PM Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>> wrote:
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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhtml.spec.whatwg.org%2Fmultipage%2Finteraction.html%23keyboard-shortcuts-processing-model&data=05%7C01%7Cakirkpat%40adobe.com%7C25e28656b4ce4f8219bf08dadec8778c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638067249827367267%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=9ISbf1mYlQeUq8Xu1aYRaW7yI8Kk9ay%2B0Z%2Fx%2Fq9qeWg%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"


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