- From: Detlev Fischer <detlev.fischer@testkreis.de>
- Date: Thu, 21 Jan 2021 19:08:59 +0100
- To: public-mobile-a11y-tf@w3.org
- Message-ID: <79253ce9-fa79-99ed-76db-9b90b371f168@testkreis.de>
Hi all, after today's brief discussion in the MATF call of Mike's Github issue #1489 and Sukriti's draft response, I had another read through the issue and see a few additional points. Mike hypothetizes a situation "where every touch-OS provides affordances for simple-touch drag and drop, and yet we continue to insist author's solve this." Going ill-prepared into our discussion, I actually mixed up AssistiveTouch with pass-through gestures, so what I said about double tap and hold was nonsense. So to repent, I had a go at iOS Assistive Touch. The functionality offered there is quite complex, and I admit that I am not sure that what I tried was meaningful. I called up, as example page, https://loryjs.github.io/lory/ which has sliders that you can drag and swipe. I used the first, SINGLE ELEMENT DOT NAVIGATION, ignoring the static arrows that are provided here. Then I went to Accessibility > AssistiveTouch and assigned the custom action for single tap to "Hold and Drag", assuming this would allow me to tap once (to set, as it were, the anchor of the movement) and then tap again (to indicate the location where the anchor should go). I am not entirely sure this is the way to do it, not even after studying https://support.apple.com/en-us/HT202658 (and would imagine evaluating the options provided in AsssistiveTouch would not be easy for *anyone* needing single tap activation). Whatever, things did happen - I could, somewhat erratically, use single tap to move the slider, but had a hard time reversing direction. Once it is on, the behaviour is pretty difficult to predict (you can also see this when selecting text). To conclude, it seems that we cannot simply assume that AssistiveTouch "provides affordances for simple-touch drag and drop". To configure it to purpose, understand / train yourself in how it works, and then carry out an action suported by it seems an undue burden when all you want to do is occasionally manage to drag-and-drop when such a control happens to be offered without single-activation equivalent. For image sliders as well as control sliders, providing arrows for alternative single tap navigation (or for control sliders, allowing activation of the groove) is an established and widespread practice and not difficult to implement. For things like Kanban boards we have seen mainstream implementations where users can single-tap items to select and then move them via a dropdown menu. Single touch implementations exist also for list sorting that supports dragging. I think Mike's second related logic puzzle (how can a user use a mobile device anyway other than by using gestures such as swiping/dragging) has been answered well by Sukriti. Users can use voice input, attached keyboards, or even define custom actions in AssistiveTouch for those generic actions they need all the time (rather than use it to tackle the occasional drag-n-drop interface). So in my view, the assumption in scenario 2 "The user is already able to operate the OS with the accommodations" seems quite unrealistic. Detlev PS: maybe this should have gone into GitHub but I leave it to Sukriti to phrase a proposed WG answer... Am 15.01.2021 um 23:51 schrieb Sukriti Chadha: > Hello MATF members, > > I looked at the issue Mike raised and it poses really interesting > questions to our overall approach. It made me appreciate the approach > of Silver and its focus on functional needs and outcomes, instead of > rigidly defining how they are met. > > Below is my initial take from only a mobile and touch devices > perspective, given that it is for a response from the MATF. Please > send any feedback or comments so we can discuss this with Mike and > others on the thread, who can then consider the wider application of > the SC beyond mobile. > > Have a great weekend! > > Best, > Sukriti > > *_Response_*: > > /_1. However, it is easy to demonstrate that mobile systems do not > meet scenario 1. For instance, the only touch way to scroll inside a > mobile touch browser is by flicking or dragging up and down. There is > no simple touch equivalent that I am aware of. Therefore, the only > ways someone can even view a web page on a mobile touch screen (whose > content exceeds the viewport) is to do actions the user in our > hypothetical cannot achieve -- or to invoke a different modality, like > keyboard operation._/ > / > / > This is not entirely true on the latest OS versions. Apart from > external keyboards, a user can navigate through web pages and apps on > both Android and iOS through voice access. You can say “scroll down”, > “swipe left” and other phrases to navigate. > > /_2. Re: larger question about the current state of things on mobile > touch devices and workarounds_/ > > Currently, if we just look at Android and iOS, that cover 99% of the > mobile operating systems market > <https://www.statista.com/statistics/272698/global-market-share-held-by-mobile-operating-systems-since-2009/#:~:text=Android%20maintained%20its%20position%20as,of%20the%20global%20market%20share.>, > assistive touch and voice access options are built in and provide > workarounds. We cannot not consider these solutions universal yet. > > a) These features are part of relatively newer OS versions. Mobile is > notorious for the long tail adoption by users who are either not able > to (because of older models that will not upgrade), or have not > upgraded to the latest version of the OS will continue to struggle > with the lack of these features for a long time. Once there is over a > certain threshold of adoption (not sure what that threshold should be) > of the latest OS versions that have it as an option, it will reduce > the burden for individual app developers or mobile web developers from > building their own solutions. > b) Not all assistive functionality is available on both platforms in > the same modes. For example, on Android, dragging is not one of the > supported gestures on the list of supported voice gestures > <https://support.google.com/accessibility/android/answer/6151854>. > > If an application is offered only on an OS that provides a workaround > by default, the author can rely on those and perhaps that should > suffice as a sufficient technique. It makes more sense for native apps > than mobile web to have this suffice as a technique. > > Overall, we can only write SCs that address the present state of > things, instead of how defaults might look in the future. A similar > argument might be made for image labels where most browsers start > assigning labels to images with AI. When these defaults become common > practice and universally available and adopted, maybe we can drop the > related SCs altogether. > > > On Fri, Jan 8, 2021 at 10:34 AM Sukriti Chadha <sukriti1408@gmail.com > <mailto:sukriti1408@gmail.com>> wrote: > > Of course, that is understood. The mobile task force however, is > best equipped to focus on the mobile specific aspects, and share > findings with the wider group. > > On Fri, Jan 8, 2021, 10:27 AM Patrick H. Lauke > <redux@splintered.co.uk <mailto:redux@splintered.co.uk>> wrote: > > On 08/01/2021 15:10, Sukriti Chadha wrote: > > > Thank you for sharing this. I just read the thread and it > looks like we > > need some more research on use cases, as well as on what is > currently > > available on mobile operating systems that will inform the > response. > > As mentioned in the thread on github, I'll also reiterate that > this is > not just a mobile/touch related issue. It applies to > desktop/laptop > devices/operating systems with touch, and more generally to > pointers > mouse interactions as well. In short, not necessarily a "mobile" > specific thing. > > P > -- > Patrick H. Lauke > > https://www.splintered.co.uk/ <https://www.splintered.co.uk/> > | https://github.com/patrickhlauke > <https://github.com/patrickhlauke> > https://flickr.com/photos/redux/ > <https://flickr.com/photos/redux/> | > https://www.deviantart.com/redux > <https://www.deviantart.com/redux> > twitter: @patrick_h_lauke | skype: patrick_h_lauke > -- Detlev Fischer DIAS GmbH (Testkreis is now part of DIAS GmbH) Mobil +49 (0)157 57 57 57 45 http://www.dias.de Beratung, Tests und Schulungen für barrierefreie Websites
Received on Thursday, 21 January 2021 18:09:12 UTC