- From: Alisa Smith <asmith@audioeye.com>
- Date: Fri, 11 Aug 2023 11:21:27 -0400
- To: Matthew Atkinson <matkinson@tpgi.com>
- Cc: "public-apa-admin@w3.org" <public-apa-admin@w3.org>
- Message-ID: <CACRdv5qU9XBXsxrBuedVYTzKKbGPAT1WuyV=JaHZbqdnQnrjtQ@mail.gmail.com>
+1 On Wed, Aug 9, 2023 at 5:10 PM Matthew Atkinson <matkinson@tpgi.com> wrote: > Colleagues: > > This is a Call for Consensus (CfC) to the Accessible Platform > Architectures (APA) Working Group testing for agreement on a formal comment > on an HTML repo issue (<https://github.com/whatwg/html/issues/8339>). > APA's input was requested as part of our role in performing horizontal > review of accessibility concerns. > > APA's background discussion on this issue is tracked in our tracking > issue: https://github.com/w3c/a11y-review/issues/138 > > Thanks to Niklas for writing this comment on our behalf. > > <APA Comment> > > We addressed this question in the course of several APA meetings and came > to the conclusion that the current behavior of the native dialog element > should be kept as it is. So, that you can tab from the dialog to the > browser functionalities. > > We see especially the benefit that keyboard users can, for example, open a > new tab to look something important up or to change a browser setting this > way. At the same time, the dialog element thus provides an additional > natural escape mechanism (i.e. moving to the address bar) in, for example, > kiosk situations where the user cannot use other standard keyboard > shortcuts. > > In addition, we also see how this can confuse some developers, as prior to > the native dialog it was common when implementing a custom dialog component > to really trap the focus. For this reason, we will also get in contact with > the APG group to talk about a change in the guide for the dialog (modal) > pattern. We think an additional note is useful, pointing out that when > using the native dialog element, tabbing to browser functionality is normal > and wanted, and does not need to be "fixed" by one's own hand. Since for > many developers APG's guides are the go-to resource for implementing > accessible components, hopefully this will prevent more confusion in the > future. > > </APA Comment> > > As always with APA CfCs, editorial corrections, such as spelling or > grammar, will be made as needed without further notice. Please do draw our > attention to any editorial issues you find in this draft. > > *** Action to Take *** > > This CfC is now open for objection, comment, as well as statements of > support via email. Silence will be interpreted as support, though messages > of support are certainly welcome. > > If you object to this proposed action, or have comments concerning this > proposal, please respond by replying on list to this message no later than > 23:59 (Midnight) Boston Time, Friday 11 August. > > NOTE: This Call for Consensus is being conducted in accordance with the > APA Decision Policy published at: > http://www.w3.org/WAI/APA/decision-policy > > -- > Matthew Tylee Atkinson (he/him) > -- > Principal Accessibility Engineer > TPG Interactive > https://www.tpgi.com > A Vispero Company > https://www.vispero.com > -- > This message is intended to be confidential and may be legally privileged. > It is intended solely for the addressee. If you are not the intended > recipient, please delete this message from your system and notify us > immediately. > Any disclosure, copying, distribution or action taken or omitted to be > taken by an unintended recipient in reliance on this message is prohibited > and may be unlawful. > > -- The information in this communication is intended for the use of the individual or entity to which it is addressed, and may contain information that is PRIVILEGED, CONFIDENTIAL and/or exempt from disclosure under law. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited.
Received on Friday, 11 August 2023 15:21:44 UTC