- From: John Foliot <john@foliot.ca>
- Date: Thu, 15 Dec 2022 15:24:27 -0500
- To: Alastair Campbell <acampbell@nomensa.com>
- Cc: Wai-Ig <w3c-wai-ig@w3.org>, WCAG <w3c-wai-gl@w3.org>, John Foliot <john@foliot.ca>
- Message-ID: <CAFmg2sXCWvArNh_tw7UoQF-ThN+X4MjjR_5m+CveDVdcz3mkwA@mail.gmail.com>
> It could be a parsing issue and not covered by 4.1.1, the SC wasn’t intended to capture all parsing issues. Well, see, that's where I'm not in full agreement. I always refer to the Understanding document to be sure I understand the Intent, and the intent extends beyond closing tags and no duplicate IDs. That document clearly states: "The intent of this Success Criterion is to ensure that user agents, including assistive technologies, can accurately interpret and parse content." If the intent was to constrain this to a narrow subset of parsing, one would presume the Intent document would say so. But the Understanding doc says " The concept of "well formed" is close to what is required here." However, this thread did confirm and surface the fact that the HTML5 spec allows for multiple controls having the same accesskey value, and that user-agents have a user-mechanism for when that happens. That plus the fact that accesskeys is about rapid focus management, and NOT control activation, so I got the *real* answer I was seeking to confirm - that duplicate accesskey values are NOT a violation of WCAG (even though on the surface it felt like it was - and that axe-core's rule set calls this out as a BP today). Thanks to everyone who contributed to my better understanding. JF On Thu, Dec 15, 2022 at 2:58 PM Alastair Campbell <acampbell@nomensa.com> wrote: > Andrew wrote: > > There is nothing in the HTML spec that forbids using the same accesskey > > I wasn’t ruling out there being a behaviour for duplicate attribute values > defined somewhere else, but from Jon & Oliver’s comments it appears not. > > > > John wrote: > > it is important to remember that the title of SC 4.1.1 is "Parsing" and > not "No Duplicate IDs". > > Sure, but the other parts of 4.1.1 don’t apply to this scenario either. If > you’re looking for a WCAG fail, it should be apparent from the SC text. > There are grey areas when we have broad guidelines, but 4.1.1 is one of the > more narrow criteria. > > It could be a parsing issue and not covered by 4.1.1, the SC wasn’t > intended to capture all parsing issues. From Jon & Oliver, duplicate > accesskeys might even be a desirable behavior. (My lack of knowledge on > accesskey workings shows how much I come across them these days!) > > > I presume your response is/was as a SME, and not on behalf of the WCAG > Chairs > > Of course. Chairs manage agendas, discussions, and consensus. Our opinions > on a topic like this have the same value as anyone else’s. Any “official” > opinion would be based on group consensus and stated as such. > > Kind regards, > > -Alastair > -- *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"
Received on Thursday, 15 December 2022 20:24:57 UTC