Concurrent input mechanisms

[kwahlbin]

Current versions of SC and Definitions

• SC for viewing | SC for editing
• SC in draft guidelines

SC Shortname

Concurrent input mechanisms

SC Text

Web content does not restrict use of input modalities available on a platform except where the restriction is essential, required to ensure the security of the content, or respect user settings.

Suggestion for Priority Level (A/AA/AAA)

Level AA

Related Glossary additions or changes

N/A

What Principle and Guideline the SC falls within.

Principle 2, potentially a new guideline concerning general "Input"

Description

There is a wide range of potential input devices that a user may be using to access / interact with a web site or web application. These include keyboard and keyboard-like interfaces, mice, touchscreens, pen/stylus, as well as advanced input mechanisms such as speech and inputs mediated through assistive technologies.

On most devices, it is possible for users to switch between different input mechanisms during the same session/interaction (for instance, on a touchscreen-enabled laptop, users may begin interacting with a site using their trackpad and keyboard, but switch to using the touchscreen for certain interactions).

A site/application should not assume that a user will always start with, and exclusively use, a particular input mechanism, and allow users to operate a site/application with any form of input mechanism available to them.

(Note: there is concern in the MATF about the requirement being too broad / covering "all" possible input types, even when they're unsupported by an OS/UA altogether - this is intended to only cover inputs that are supported by operating systems / are accessibility supported)

Benefits

A site/application that can be used/operated by users with multi-input devices (e.g. a touchscreen enabled laptop, a mobile phone with paired bluetooth keyboard/mouse) and allow users to switch between their different input mechanisms.

Testability

Manual testing - authors should test their site/application using the widest possible range of input devices available, and switching input devices during the same session/interaction.

Techniques

• rely on high-level, input-agnostic events like focus/blur/click; by definition, these events are not input-specific, and generally user agents are designed to trigger these regardless of specific input device; however, note the peculiarities of specific input mechanisms (for instance, how the concepts of focus and blur differ for touchscreen inputs compared to keyboard/mouse)
• register separate event handlers to cover various input devices - e.g. register handlers to cover mouse, keyboard and touch interactions, instead of simply relying on just one set of event handlers specific to a particular input modality

[alastc]

Is it possible to create a list of "good" and "bad" event handlers?

I'm not asking for the list, but from people with more experience of input events (cough @patrickhlauke) is such a thing possible?

I'm concerned by the broadness (as mentioned in the description), as an accessibility tester I'm not clear how you would test it.

If there were a list of event handlers to watch out for that would be something concrete. E.g. onclick works across devices (assuming you can tab to it), but onmouseover can be problematic.

If it is possible to create a table of good/bad event handlers and what to test if you find one, then it could work in practice.

If that isn't possible in theory, I'm not sure this will be practical.

[patrickhlauke]

It's not necessarily just a question of which event handlers have been used (though there are "safe" ones, such as click, focus, blur, contextmenu which are reasonably input-independent in that they get triggered - sometimes in different situations, depending on the type of element they're on - by various input mechanisms), but also about whether or not handlers have been doubled up for different inputs (so that yes, you could use mouseover, but then need to also account for other inputs and that they can also trigger the same/equivalent functionality), and crucially that there's no code anywhere that makes naive "EITHER touch OR mouse" type branching when attaching event handlers.

In short, it's something that would need to be tested by actually using different inputs (either real or emulated, such as with Developer Tools that support touch emulation), rather than something that can be easily gleaned from just looking at code.

[patrickhlauke]

I can, however, see that this is perhaps leaning more towards general usability/UX, rather than accessibility (as in all users would be inconvenienced by this, rather than disproportionately users with disabilities)

[mbgower]

As with several MATF items, to the degree comments accurately describe what is being sought here, it feels like existing 2.1.1 seems to cover the requirement.

G90: Providing keyboard-triggered event handlers using one of the following techniques:

• SCR20: Using both keyboard and other device-specific functions
• SCR35: Making actions keyboard accessible by using the onclick event of anchors and buttons
• SCR2: Using redundant keyboard and mouse event handlers

Is the concern that "Keyboard" is too restrictive or not descriptive enough as a general Input guide? Perhaps what is needed is some text in 2.1.1 noting that Keyboard in WCAG is treated as a foundational input category which many other technology and input modalities emulate or can exploit. For the era in which it was written, some content is in the Understanding document now. An update to make it broader in scope may satisfy the overall perceived need.

The principle of being able to switch between different modalities in mid activity can perhaps be captured with some additions to 2.1.1. Ironically, I've had more issues with the opposite problem of being forced to switch modalities -- iOS not allowing me to select or reject word suggestions with an external keyboard thus forcing me to reach out and touch the screen, even within the onscreen keyboard modality. I had a client with both fine motor skill and cognitive issues, who ultimately could not use the iPad form factor at the time for this exact reason

Assuming these objections are overlooked or resolved, I'm also wondering how a tester is supposed to differentiate between issues caused by an author and an OS. For example, physically unplugging a headset in the native iOS music application stops playback. Ignoring for the moment this is an output, not input example, how do I as a tester determine if this is an application feature failing concurrent (output) mechanisms, or something triggered by the operating system?
An example that involves input and output that is definitely affected by the OS is switching between a bluetooth headset and the built-in microphone in the middle of an activity. Expecting a graceful switch over without any disruption is optimistic. You don't have any language surrounding acceptable transitions, etc. I supposed such language could address this.

[patrickhlauke]

Is the concern that "Keyboard" is too restrictive or not descriptive enough as a general Input guide? Perhaps what is needed is some text in 2.1.1 noting that Keyboard in WCAG is treated as a foundational input category which many other technology and input modalities emulate or can exploit.

Imagine the scenario where I have a touchscreen-enabled laptop - this SC aims to make sure that even though a touchscreen is present, the site/app does not stop me from also using my mouse, and vice-versa. Nothing to do with keyboard (and both touch and mouse in this scenario do not "emulate or exploit" keyboard input, i.e. they don't look like a keyboard-like input to the site/app).

In this scenario as well, assume I'm using an external USB mouse, and then pull out the USB cable...the site/app should be still operable with the touchscreen, or after I plug another mouse in, or decide to instead use the keyboard, or start issuing voice commands. In short, this is about ensuring that sites/apps don't assume one input (the "primary", whatever that may be, or whatever I was using when I first launched the site/app) is the only one that I want/can use. Basically, being input-agnostic and not seeing it as something like "mouse OR touch OR keyboard OR ..." but "mouse AND touch AND keyboard AND ..."

In code terms, avoiding to do things like (using pseudocode)

if (device has touchscreen) {
  only listen to touchscreen events
} else {
  listen to mouse
}

or similar.

Having said all that, I think that perhaps this may be another candidate for a proposed SC that I could live with withdrawing / postponing for Silver. Part of my thinks that this is a problem that can affect all users, not just PWD (or rather, that it possibly doesn't unduly affect PWD more than other user groups).

[mbgower]

Thanks for that explanation, @patrickhlauke .

I would concur that it is a consideration for all users, and it's not readily apparent to me how it places extra burden on PwDs or users of AT.

[patrickhlauke]

it's not readily apparent to me how it places extra burden on PwDs or users of AT

to play devil's advocate, I could see how - taking the touchscreen / mouse / keyboard scenario, and assuming that a site, on noticing touch, defaults to just using touch - all users would potentially be inconvenienced that they can't use their preferred/current input, but potentially PwDs who have greater difficulty using the touchscreen over using the mouse or keyboard for whatever reason would find this far more problematic. Or how a user that experiences discomfort/pain after prolonged use of one input would want to seamlessly switch to another input type without having to reload an app / interrupt their current activity / etc

[shwetank]

I think it overall support it as a I think the intent of the SC is good. However, with time, as input mechanism increase, the potential permutations and combinations to test this could become unwieldy. To reduce the chances of this, I think we would need to work a bit more on the suggested techniques and list more good practices (and also maybe some bad practices to avoid).

[patrickhlauke]

I'd officially propose postponing this for WCAG 2.1 and revisiting this for Silver, which may take a wider look at good/best practices and usability on top of simply "affects PwD more than others".

@shwetank agree that conclusive testing will be potentially complex, though you could roughly split it into "test with a keyboard/keyboard-like interface, a mouse, and a touchscreen/stylus/other type of pointer" (as i can't foresee at this stage any new input method that would not fall under these, in terms of how they expose themselves to the OS/UA - e.g. switch access "looks" like a keyboard to the OS)

[kwahlbin]

Based on the comments on the working group call on Jan 31, it is not off the table to make changes to 2.1.1.

[joshueoconnor]

@kwahlbin who is the SC manager for this?

[patrickhlauke]

@joshueoconnor i may be wrong, but i believe this SC may well be retired / unneeded now. further, i can't see how the concept here (which is arguably more of a usability concern first and foremost) can be grafted onto 2.1.1 in any meaningful way

[kwahlbin]

This SC was covering the scenario where users should be able to operate all functionality between the different input methods such as starting with touch and the going to keyboard input. I agree with Patrick that I don't see how that can be integrated into 2.1.1.

[patrickhlauke]

i'd suggest deferring this to silver, as it's possibly more of a usability issue

[DavidMacDonald]

Agree with @patrickhlauke on this.

[greg-lowney]

Assuming the explanation provided by @patrickhlauke on 2017-01-19 that the goal is not to require that every task can be performed with every input device, but rather merely to prevent sites from unnecessarily disabling the ability to use one device for a task, how about: "The ability to perform an action using a given input device or modality is not restricted due to either of the following: (a) the presence of a different input device or modality on the system; (b) the user having used a different input device or modality at a previous time." That does not require that a touchscreen be supported, but it cannot be disabled merely because a mouse is present or has been used. Alternate wording might be "The presence of one input dvice or modality on the system, or the user having used that device, does not prevent the use of any other device for performing subsequent actions"

[kwahlbin]

Based on conversations from today's AG call:

The ability to perform an action using a given input device or modality is not restricted due to either of the following:
(a) the presence of a different input device or modality on the system;
(b) the user having used a different input device or modality at a previous time

unless it would jeopardize the security of the content or invalidate the action.

[johnfoliot]

unless it would jeopardize the security of the content or invalidate the

action. I am increasingly becoming concerned that we are inserting language similar to this when crafting these new SC: variants of this type of vague exemption rule have shown up recently in more than one SC (including some that have already advanced). Some questions for the WG: - How would you test for this exemption? - Do we have a definition of what we mean when we claim something would "jeopardize security"? - Who decides whether "security", as mentioned here, over-rides the accessibility requirement being brought forward with this SC? I was unable to attend today's call, but on the surface this seems to say that all a website needs to do to circumvent this SC is to make a claim of "Security", and then walk away. JF

…

On Thu, Jun 22, 2017 at 2:18 PM, kwahlbin ***@***.***> wrote: Based on conversations from today's AG call: The ability to perform an action using a given input device or modality is not restricted due to either of the following: (a) the presence of a different input device or modality on the system; (b) the user having used a different input device or modality at a previous time unless it would jeopardize the security of the content or invalidate the action. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#64 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABK-c3sx7uk3ujsM2n5G2EUgQYg94q5gks5sGr4DgaJpZM4K-jIc> .

-- John Foliot Principal Accessibility Strategist Deque Systems Inc. john.foliot@deque.com Advancing the mission of digital accessibility and inclusion

[KimPatch]

There have been questions about use cases. I'm one. I often use speech and pointer input the same time. That's what makes it possible for me to participate on W3C calls and not have to constantly mute/unmute. Not to say that I don't mute/unmute often – I do, and it's a pain. But if I weren't able to use the concurrent input mechanisms of speech and mouse (wacom tablet to be precise) participation would more difficult. I would be less likely to volunteer for minutes and if I did there would be times when I would lose things. Assistive technologies are very often imperfect and users very often have to be innovative to figure out how to get something done efficiently. Concurrent input mechanisms is an important part of our toolkit.

[mraccess77]

I often switch between keyboard and mouse for navigation depending on the situation and how easily I can get keyboard focus to something and see the visual indication of keyboard focus.

[patrickhlauke]

use case: using a touch-enabled laptop, sites that feature-detect for presence of a touchscreen and then only implement touch-based functionality (e.g. only listening to touchstart/touchmove/touchend JS events) effectively block the user from then using the mouse or keyboard. similarly, even on nominally "touch only" devices like phones/tablets, it's possible for a user to also pair a physical keyboard and mouse (on Android, Windows Phone). once again, only detecting the presence of a touchscreen (or doing a user-agent sniff and determining "this is a touch-only device") will prevent users from using those input mechanisms.

[kwahlbin]

New language suggested for the SC:

Web content does not restrict user input modalities available on a platform unless it would jeopardize the security of the content, invalidate an activity, or override a user setting.

Please let us know your comments

[kwahlbin]

Patrick provided some examples of where this is an issue that I would also post here:

I have a short video demonstrating one of these types of issues (mouse not working anymore on touch-enabled laptop, but only for a particular feature not the entire page/site) here https://www.youtube.com/watch?v=f_2GKsI9TQU (sadly the audio is out of sync with the video, but hopefully gives an idea)...but after speaking to the folks at Flickr they fixed it...

Similarly in frameworks like Bootstrap, where I file fixes
twbs/bootstrap#22442

[mbgower]

Patrick provided some examples

Great example! Thanks @kwahlbin and @patrickhlauke

[kwahlbin]

The text has been updated to "Web content does not restrict use of input modalities available on a platform except where the restriction is essential, required to ensure the security of the content, or respect user settings"