- From: Bryan Garaventa <bryan.garaventa@levelaccess.com>
- Date: Tue, 12 Feb 2019 23:09:01 +0000
- To: "public-aria-practices@w3.org" <public-aria-practices@w3.org>, "public-aria@w3.org" <public-aria@w3.org>
- Message-ID: <BYAPR03MB4805E725C77DA1528E7AE461F2650@BYAPR03MB4805.namprd03.prod.outlook.com>
Hi, Based on our discussion yesterday, I've made several important changes to the ARIA date pickers I've referenced for testing. This will probably help as we try to document a reliable keyboard paradigm for both combobox and non-combobox patterns, as well as to address hybrid patterns that work equally well across both keyboard and touch devices, so please test these using both device types. The same text has been added to the github issue at https://github.com/w3c/aria-practices/issues/34#issuecomment-462974477 James, I tried to locate the test urls you sent me, but I couldn't access this in my IRC history and it doesn't appear to be in the meeting minutes. Either way though, I understand your points about having a need to display the date picker on touch without showing the virtual keyboard, and I have already solved this without requiring focus redirection to do so. A few notes about the changes. 1. I have made it possible to auto-render the calendar on touch screen devices, which includes hybrid laptops, and mobile devices like iPads and iPhones. This includes relevant state indicators such as aria-expanded where relevant to convey this to screen reader users. For editable date picker input fields, you can touch the input to render the calendar, yet this will not render the virtual keyboard, but if you touch the field again, it will render the virtual keyboard and make the calendar disappear. This works with VoiceOver running by double-tapping the input field as well. 2. For sighted keyboard only users, I have added a visual indicator to convey that the ‘down’ arrow key is active when the calendar is rendered, which disappears when the calendar is closed, to make it clear that you can press the Down arrow to navigate into the date picker after focus is set to the input field. 3. I have updated the instructions at the end of the page to match the page functionality so as not to confuse everybody going forward. Test urls 1. Editable <http://whatsock.com/tsg/Coding%20Arena/ARIA%20Date%20Pickers/ARIA%20Date%20Picker%20(Basic,%20Auto%20Open)/demo.htm> 2. Readonly <http://whatsock.com/tsg/Coding%20Arena/ARIA%20Date%20Pickers/ARIA%20Date%20Picker%20(Basic,%20ReadOnly%20Auto%20Open%20plus%20Disabled%20Ranges)/demo.htm> Explanation As a general design pattern, we should not rely upon focus movement hacks to either display or not display specific platform features like virtual keyboards. Instead, we should keep focus in a predictable and accessibility approved location and update functionality accordingly using the attached events for whatever widget currently has focus. This can be done by modifying the event order of precedence when triggered on the input field, and it does not require setting focus to inactive parent elements to trick the browser into doing something different. The above examples show the results of this methodology, and the only technique that is being used is the utilization and conditional processing of specific attached events on the input field. Specifically, these include the ontouchstart and onfocus event handlers. The ontouchstart handler is always processed before the display of a virtual keyboard, and if returned false (event.preventDefault) is used to cancel this handler, then it will not display the virtual keyboard on the screen, and this event will only fire when the input field is touched using a touch screen. If ontouchstart is canceled, then the onFocus event will not fire either. So, to achieve the same logic on an auto-opening calendar when focus is set to an editable input field, do the following. 1. Attach both an ontouchstart and onfocus handler to the input. 2. Within the ontouchstart handler, check if the calendar is already open, and if so, do nothing. Otherwise, render the calendar and return false to prevent further processing. The ontouchstart handler will only fire when touched. 3. Within the onfocus handler, check if the calendar is already open, and do nothing if so. Otherwise, render the calendar and provide a help prompt such as a live region to convey to non-sighted screen reader users that the down arrow key is needed to move focus into the calendar. The onfocus handler will fire when keyboard users set focus to the input, and also after ontouchstart fires if ontouchstart is not cancelled beforehand. The touch event can be queried to ensure that keyboard specific instructions are only announced for keyboard users. 4. Add an onclick to the input field, and within that handler, check if the calendar is already open, and close it if so, which will turn the input field into a toggle and allow for the display of the virtual keyboard when the editable input field is touched a second time using a touch device. Every time a calendar is rendered, preferably within a callback for this purpose, aria-expanded needs to be set on the input field to convey the active state of this calendar for non-sighted screen reader users. Also, if a separate triggering element is present that can be used as a toggle like in the examples above, these too need to include aria-expanded to convey the same thing, since both control the same calendar, and the triggering element that has focus must convey its active state regardless which one it is. I've also had these example design patterns extensively reviewed internally, and to ensure accessibility for sighted keyboard only users, it is necessary to include a dynamically updated visual indicator such as an arrow icon to convey that the user can press the Down arrow when the input has focus to then move focus into the calendar for navigation. Also, a clear visual indicator does not have to be normalized for different languages like a plain text message would have to be. By combining all of these things as I did, you can indeed create a reliable and provably accessible auto-renderrable date picker that works across both desktop and touch devices equally within the same design pattern; without having to include focus movement hacks to disrupt native functionality within mobile devices. To review the code for these widgets, it has already been added to https://github.com/whatsock/tsg Bryan Garaventa Principal Accessibility Architect Level Access, Inc. Bryan.Garaventa@LevelAccess.com 415.624.2709 (o) www.LevelAccess.com<http://www.levelaccess.com/> From: Ann Abbott <annabbott@gmail.com> Sent: Monday, February 11, 2019 11:05 AM To: Matt King <a11ythinker@gmail.com> Cc: public-aria-practices@w3.org Subject: Minutes for Monday, 11 February 2019 ARIA Authoring Practices Task Force CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Minutes: https://www.w3.org/2019/02/11-aria-apg-minutes.html Kind Regards, Ann annabbott@gmail.com<mailto:annabbott@gmail.com> 512-451-8267 On Fri, Feb 8, 2019 at 7:19 PM Matt King <a11ythinker@gmail.com<mailto:a11ythinker@gmail.com>> wrote: Monday, 11 February 2019 ARIA Authoring Practices Task Force Time: 10:00 AM US Pacific, 1:00 PM US Eastern duration: 60 minutes IRC server: irc.w3.org<http://irc.w3.org>, port: 6665, channel: #aria-apg Agenda wiki page: https://github.com/w3c/aria-practices/wiki/February-11%2C-2019-Meeting Topics: * ARIA and AT Project Update * House keeping update * Issue triage * Date Picker Combo Box Example * Editorial guidelines - Comma and Quote Placement * Future meetings and other business * Github PR Review Tutorial ------------------------------------------------------- To join the WebEx audio conference, you may call in via phone or join the online meeting and request a call back to any number. US toll call-in: +1-617-324-0000 Access code (meeting number): 640 859 469 Mobile Auto Dial:+1-617-324-0000,,,640859469# To join the online meeting: 1. Go to https://mit.webex.com/mit/j.php?MTID=ma880be53415dc3d751387cd2fcc47cb7 2. Enter your name and email address. 3. Enter the meeting password. You may ask for it on the IRC channel if you do not know it. 4. Click "Join". WebEx support: 1. Go to https://mit.webex.com/mit/mc 2. From the left navigation bar, choose "Support".
Received on Tuesday, 12 February 2019 23:09:28 UTC