Re: Duplicate Accesskey Values

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)


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