Re: Duplicate Accesskey Values

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
)

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