Re: Issue 1489 - Does Dragging blur platofrm and author considerations? https://github.com/w3c/wcag/issues/1489

Hi Detlev,

Thank you so much for going through an actual user flow to highlight the
difference between having an alternative, and the feasibility of using it.
I have combined our responses into one, and posted on Github
<https://github.com/w3c/wcag/issues/1489#issuecomment-766390246>.

@Mike, please let us know if there's anything we missed, and whether you'd
like to join the next MATF meeting to discuss more. Thank you!

Best,
Sukriti

On Thu, Jan 21, 2021 at 1:09 PM Detlev Fischer <detlev.fischer@testkreis.de>
wrote:

> 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>
> 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>
>> 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://github.com/patrickhlauke
>>> https://flickr.com/photos/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
>
>