This repository has been archived by the owner. It is now read-only.

Device sensors #67

Closed
kwahlbin opened this Issue Nov 29, 2016 · 85 comments

Comments

Projects
None yet
@kwahlbin
Contributor

kwahlbin commented Nov 29, 2016

Current versions of SC and Definitions

SC Shortname

Device sensors

SC Text

All functionality of the content can be operated without requiring specific device sensor information unless the device sensor is essential for the function and not using it would invalidate the activity.

Suggestion for Priority Level (A/AA/AAA)

Level A

Related Glossary additions or changes

Editors´ Note: The Working Group has identified questions of scope for this SC, and is exploring rewording to resolve this. The main question is about the relationship to indirect motion associated with operating a keyboard, pointer, or assistive technology. Draft new wording is available at #67 (comment)

Device sensor: A device sensor is a device component that detects and responds to some type of input from the physical environment. Examples on mobile devices are the measurement of motion, orientation, and various environmental conditions.

What Principle and Guideline the SC falls within.

Principle 2, new Guideline "Additional sensor inputs"

Description

Devices may have sensors that act as inputs - e.g. tilt/orientation sensors on a mobile/tablet, allowing the user to control something by simply changing the orientation of the device in space. Not all devices may have these sensors. Even when the device has these sensors, the user may not be unable to operate these sensors (either not at all, or not precisely enough). Functionality must therefore be implemented in a way that other means are available to activate the function that do not rely on additional sensor input.

Examples

  • After text input in a field, shaking a device shows a dialog offering users to undo the input. A cancel button next to the text field offers the same functionality - activating it reverts to the content (if any) that was shown before the user input replaced it.

Benefits

Users with disabilities may be unable to perform particular actions impacting on sensors (such as tilting or shaking) because the device may be mounted or users may be physically unable to perform the necessary action. This sucess scriterion ensures that users can still operate all functionality by other means (e.g., touch or voice input). All users benefit from this, for example, users who are temporarily unable to hold and move the device because their hands are occupied with some other activity.

Testability

Manual test - if the content provides functionality tied to particular sensors, ensure that an alternative method is available to trigger the same functionality without the use of these sensors.

Procedure

For each function that can activated via additional sensor input:

  1. check that there is an alternative accessibility supported method to activate the function

Expected Results

  • All checks above are true

Techniques

Functionality/content must not solely rely on device inputs (e.g. an alternative which does not require the user to manipulate their device/use these device inputs must be available)

@mraccess77

This comment has been minimized.

Show comment
Hide comment
@mraccess77

mraccess77 Dec 13, 2016

Contributor

Signing up as SC manager.

Contributor

mraccess77 commented Dec 13, 2016

Signing up as SC manager.

@mbgower

This comment has been minimized.

Show comment
Hide comment
@mbgower

mbgower Jan 18, 2017

Contributor

In what way is this not already achieved by 2.11 Keyboard?

: All functionality of the content is operable through a keyboard interface

In regard to the "device sensor is essential" language, I would like some concrete examples of this, as I am having difficulties imagining a situation where this isn't already covered by the exception language in 2.1.1:

except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.

Even though that obviously was conceived to cover things like drawing with a pointer, not mobile tilt, etc., it seems to cover mobile sensors quite effectively.

Contributor

mbgower commented Jan 18, 2017

In what way is this not already achieved by 2.11 Keyboard?

: All functionality of the content is operable through a keyboard interface

In regard to the "device sensor is essential" language, I would like some concrete examples of this, as I am having difficulties imagining a situation where this isn't already covered by the exception language in 2.1.1:

except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.

Even though that obviously was conceived to cover things like drawing with a pointer, not mobile tilt, etc., it seems to cover mobile sensors quite effectively.

@mraccess77

This comment has been minimized.

Show comment
Hide comment
@mraccess77

mraccess77 Jan 18, 2017

Contributor

@mbgower An example of essential sensor might be a pedometer. Yes, the function could be made keyboard accessible -- each time I press a key it simulates a step. but that would defeat the purpose of the activity for most purposes and thus is why we need the exception.

Regarding keyboard interface functionality -- In my experience some mobile platforms such as Safari on iOS do not pass through the keyboard interface from a physical or on-screen keyboard to web apps. So there is a need to provide alternative methods that don't rely on the keyboard interface. This might also allow for sensor info to be collected in other accessible way that don't meet the keyboard interface requirement but provide sufficient access.

Contributor

mraccess77 commented Jan 18, 2017

@mbgower An example of essential sensor might be a pedometer. Yes, the function could be made keyboard accessible -- each time I press a key it simulates a step. but that would defeat the purpose of the activity for most purposes and thus is why we need the exception.

Regarding keyboard interface functionality -- In my experience some mobile platforms such as Safari on iOS do not pass through the keyboard interface from a physical or on-screen keyboard to web apps. So there is a need to provide alternative methods that don't rely on the keyboard interface. This might also allow for sensor info to be collected in other accessible way that don't meet the keyboard interface requirement but provide sufficient access.

@mbgower

This comment has been minimized.

Show comment
Hide comment
@mbgower

mbgower Jan 18, 2017

Contributor

@mraccess77

An example of essential sensor might be a pedometer.

Okay, that's stretching the definition of "path of user's movement", grin, but it still ties in with the overall concept of the exception in 2.1.1. I guess what I'm getting at is that listing an exception for every technology separately wouldn't be necessary if the 2.1.1 exception wasn't so technology-fixated with 'drawing' the mouse coordinates through time. How about if we just used the words of 2.1.1's Understanding doc for its exception language: "those things that cannot reasonably be controlled from a keyboard".
Or better "...except those things that cannot reasonably be approximated by a keyboard" (or "simulated with")

In my experience some mobile platforms such as Safari on iOS do not pass through the keyboard interface from a physical or on-screen keyboard to web apps.

Unless I am misunderstanding, that sounds like a pretty clear violation of UAAG Guideline 2.1 - Ensure full keyboard access.

Contributor

mbgower commented Jan 18, 2017

@mraccess77

An example of essential sensor might be a pedometer.

Okay, that's stretching the definition of "path of user's movement", grin, but it still ties in with the overall concept of the exception in 2.1.1. I guess what I'm getting at is that listing an exception for every technology separately wouldn't be necessary if the 2.1.1 exception wasn't so technology-fixated with 'drawing' the mouse coordinates through time. How about if we just used the words of 2.1.1's Understanding doc for its exception language: "those things that cannot reasonably be controlled from a keyboard".
Or better "...except those things that cannot reasonably be approximated by a keyboard" (or "simulated with")

In my experience some mobile platforms such as Safari on iOS do not pass through the keyboard interface from a physical or on-screen keyboard to web apps.

Unless I am misunderstanding, that sounds like a pretty clear violation of UAAG Guideline 2.1 - Ensure full keyboard access.

@mraccess77

This comment has been minimized.

Show comment
Hide comment
@mraccess77

mraccess77 Jan 18, 2017

Contributor

@mbgower "Or better "...except those things that cannot reasonably be approximated by a keyboard" (or "simulated with")"

Things like geolocation can be spoofed on Android in a keyboard accessible way but it may invalidate an activity -- such as playing Pokémon. So I'd rather focus on invalidation of the activity rather than the feasibility.

Contributor

mraccess77 commented Jan 18, 2017

@mbgower "Or better "...except those things that cannot reasonably be approximated by a keyboard" (or "simulated with")"

Things like geolocation can be spoofed on Android in a keyboard accessible way but it may invalidate an activity -- such as playing Pokémon. So I'd rather focus on invalidation of the activity rather than the feasibility.

@mbgower

This comment has been minimized.

Show comment
Hide comment
@mbgower

mbgower Jan 18, 2017

Contributor

So I'd rather focus on invalidation of the activity rather than the feasibility.

Sure, that's fine. But as an overall concept, how do you feel about capturing this as revised exception language in 2.1.1?

Contributor

mbgower commented Jan 18, 2017

So I'd rather focus on invalidation of the activity rather than the feasibility.

Sure, that's fine. But as an overall concept, how do you feel about capturing this as revised exception language in 2.1.1?

@mraccess77

This comment has been minimized.

Show comment
Hide comment
@mraccess77

mraccess77 Jan 18, 2017

Contributor

@mbgower Changes to 2.1.1 is an optimal place -- however, I'd defer to others as to how/where that is best handled.

Contributor

mraccess77 commented Jan 18, 2017

@mbgower Changes to 2.1.1 is an optimal place -- however, I'd defer to others as to how/where that is best handled.

@kwahlbin

This comment has been minimized.

Show comment
Hide comment
@kwahlbin

kwahlbin Jan 31, 2017

Contributor

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. Are there suggestions on what language should be updated to incorporate this?

Contributor

kwahlbin commented Jan 31, 2017

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. Are there suggestions on what language should be updated to incorporate this?

@joshueoconnor

This comment has been minimized.

Show comment
Hide comment
@joshueoconnor

joshueoconnor Feb 4, 2017

Contributor

@kwahlbin @mraccess77 Yes, if you think this SC may indicate a need for a more fundamental change to 2.1.1 - we'd like to hear it.

Contributor

joshueoconnor commented Feb 4, 2017

@kwahlbin @mraccess77 Yes, if you think this SC may indicate a need for a more fundamental change to 2.1.1 - we'd like to hear it.

@kwahlbin

This comment has been minimized.

Show comment
Hide comment
@kwahlbin

kwahlbin Feb 9, 2017

Contributor

This one I think stands on its own. Incorporating it into 2.1.1 will need to state that input should not rely on device sensor information.

Contributor

kwahlbin commented Feb 9, 2017

This one I think stands on its own. Incorporating it into 2.1.1 will need to state that input should not rely on device sensor information.

@mraccess77

This comment has been minimized.

Show comment
Hide comment
@mraccess77

mraccess77 Feb 10, 2017

Contributor

I agree with Kathy this SC is best separate from SC 2.1.1

Contributor

mraccess77 commented Feb 10, 2017

I agree with Kathy this SC is best separate from SC 2.1.1

@jasonjgw

This comment has been minimized.

Show comment
Hide comment
@jasonjgw

jasonjgw Feb 10, 2017

My problem with this proposal is that I don't know how to satisfy 2.1.1 and yet fail to satisfy this proposed SC. It isn't merely that this proposal overlaps 2.1.1, but rather that the content author has to meet 2.1.1 in any case (and this won't change); but meeting 2.1.1 seems to preclude the kind of dependence on device sensor information that this proposal is designed to prevent. The logic is: assume that 2.1.1 is passed, at which point it's far from obvious how one could fail here.

It's possible that there are scenarios which fall under the exception in 2.1.1 but which aren't covered by the exception in this proposal. However, none comes immediately to mind.

The problem of the relationship with 2.1.1 makes this proposal very confusing. I think the best solution would be to drop it at this point, or to write a very focused proposal that clearly identifies whatever isn't already addressed by 2.1.1 and deals with it specifically.

My problem with this proposal is that I don't know how to satisfy 2.1.1 and yet fail to satisfy this proposed SC. It isn't merely that this proposal overlaps 2.1.1, but rather that the content author has to meet 2.1.1 in any case (and this won't change); but meeting 2.1.1 seems to preclude the kind of dependence on device sensor information that this proposal is designed to prevent. The logic is: assume that 2.1.1 is passed, at which point it's far from obvious how one could fail here.

It's possible that there are scenarios which fall under the exception in 2.1.1 but which aren't covered by the exception in this proposal. However, none comes immediately to mind.

The problem of the relationship with 2.1.1 makes this proposal very confusing. I think the best solution would be to drop it at this point, or to write a very focused proposal that clearly identifies whatever isn't already addressed by 2.1.1 and deals with it specifically.

@patrickhlauke

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke Feb 10, 2017

Member

Fundamentally, is it a problem if an SC is satisfied automatically if another SC is already satisfied? i.e. if passing 2.1.1 makes this pass automatically? (and conversely, failing this SC would also fail 2.1.1)

The danger is for 2.1.1 to become a catch-all SC, but due to its name "Keyboard" it's far from obvious that it relates to all sorts of other things

Member

patrickhlauke commented Feb 10, 2017

Fundamentally, is it a problem if an SC is satisfied automatically if another SC is already satisfied? i.e. if passing 2.1.1 makes this pass automatically? (and conversely, failing this SC would also fail 2.1.1)

The danger is for 2.1.1 to become a catch-all SC, but due to its name "Keyboard" it's far from obvious that it relates to all sorts of other things

@jasonjgw

This comment has been minimized.

Show comment
Hide comment
@jasonjgw

jasonjgw Feb 10, 2017

@DavidMacDonald

This comment has been minimized.

Show comment
Hide comment
@DavidMacDonald

DavidMacDonald Feb 10, 2017

Contributor

I think the note should be a glossary entry
Instead of:

Note 1: device sensor information includes, but is not limited to, additional input values such as tilt, orientation, proximity.

Something like:
Glossary

device sensor: [few word definition] this includes, but is not limited to, additional input values such as tilt, orientation, proximity.

Contributor

DavidMacDonald commented Feb 10, 2017

I think the note should be a glossary entry
Instead of:

Note 1: device sensor information includes, but is not limited to, additional input values such as tilt, orientation, proximity.

Something like:
Glossary

device sensor: [few word definition] this includes, but is not limited to, additional input values such as tilt, orientation, proximity.

@jasonjgw

This comment has been minimized.

Show comment
Hide comment
@jasonjgw

jasonjgw Feb 10, 2017

@goodwitch

This comment has been minimized.

Show comment
Hide comment
@goodwitch

goodwitch Feb 10, 2017

Contributor

I agree that this SC is best kept separate from SC 2.1.1. If it needs more clarity, that is great...but I think in the long run it is distinct and therefore easier to define, explain, test and get consistency as a separate SC.

Contributor

goodwitch commented Feb 10, 2017

I agree that this SC is best kept separate from SC 2.1.1. If it needs more clarity, that is great...but I think in the long run it is distinct and therefore easier to define, explain, test and get consistency as a separate SC.

@DavidMacDonald

This comment has been minimized.

Show comment
Hide comment
@DavidMacDonald

DavidMacDonald Feb 10, 2017

Contributor

I agree with Jason IF in every passing condition of 2.1.1 this is covered. I haven't thought through it enough to be sure of that.

Contributor

DavidMacDonald commented Feb 10, 2017

I agree with Jason IF in every passing condition of 2.1.1 this is covered. I haven't thought through it enough to be sure of that.

@mbgower

This comment has been minimized.

Show comment
Hide comment
@mbgower

mbgower Feb 10, 2017

Contributor

So, I'm going to expand on a couple of points to see if we really can't capture all input questions under one SC.

Incorporating it into 2.1.1 will need to state that input should not rely on device sensor information

Exactly. I'd rephrase that and say all that is needed to incorporate this into 2.1.1 is to expand the definition of not relying on a single input modality. That seems like a good solution. Incidentally,, I believe the key word "input" is missing from this SC as it stands.

This one I think stands on its own.

My concern continues to be that if we create a new SC saying 'don't rely on this alone' for every form of input (be it speech or sensors or touch, etc) we end up creating bloat.

I believe that the intention of 2.1.1 was ultimately about ensuring multi-modal input. It focused on ensuring keyboard equivalency, since keyboard is demonstrably a vehicle on which lots of other modalities and ATs can ride.

It's tough to conclude this discussion without offering some suggested revisions to 2.1.1. When are we allowed to tackle that?

Contributor

mbgower commented Feb 10, 2017

So, I'm going to expand on a couple of points to see if we really can't capture all input questions under one SC.

Incorporating it into 2.1.1 will need to state that input should not rely on device sensor information

Exactly. I'd rephrase that and say all that is needed to incorporate this into 2.1.1 is to expand the definition of not relying on a single input modality. That seems like a good solution. Incidentally,, I believe the key word "input" is missing from this SC as it stands.

This one I think stands on its own.

My concern continues to be that if we create a new SC saying 'don't rely on this alone' for every form of input (be it speech or sensors or touch, etc) we end up creating bloat.

I believe that the intention of 2.1.1 was ultimately about ensuring multi-modal input. It focused on ensuring keyboard equivalency, since keyboard is demonstrably a vehicle on which lots of other modalities and ATs can ride.

It's tough to conclude this discussion without offering some suggested revisions to 2.1.1. When are we allowed to tackle that?

@patrickhlauke

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke Feb 10, 2017

Member

It's tough to conclude this discussion without offering some suggested revisions to 2.1.1. When are we allowed to tackle that?

Incidentally, to provide a bit of history (I'm sure I dropped this into some other thread/issue here before)...that's exactly what I originally proposed many months ago. When told that 2.1.1 was immutable, I embarked on adding a series of SCs for input mechanisms that we felt weren't adequately addressed/covered by 2.1.1

I agree that 2.1.1 itself could cover many of these proposed SCs. I'll find some time to dig out proposed changes to 2.1.1.

Member

patrickhlauke commented Feb 10, 2017

It's tough to conclude this discussion without offering some suggested revisions to 2.1.1. When are we allowed to tackle that?

Incidentally, to provide a bit of history (I'm sure I dropped this into some other thread/issue here before)...that's exactly what I originally proposed many months ago. When told that 2.1.1 was immutable, I embarked on adding a series of SCs for input mechanisms that we felt weren't adequately addressed/covered by 2.1.1

I agree that 2.1.1 itself could cover many of these proposed SCs. I'll find some time to dig out proposed changes to 2.1.1.

@mbgower

This comment has been minimized.

Show comment
Hide comment
@mbgower

mbgower Feb 10, 2017

Contributor

I'll find some time to dig out proposed changes to 2.1.1.

I'd be happy to bash around stuff offline with you, if that would makes for a less messy Issue thread.

Contributor

mbgower commented Feb 10, 2017

I'll find some time to dig out proposed changes to 2.1.1.

I'd be happy to bash around stuff offline with you, if that would makes for a less messy Issue thread.

@mraccess77

This comment has been minimized.

Show comment
Hide comment
@mraccess77

mraccess77 Feb 10, 2017

Contributor

Any updates to SC 2.1.1 would have to allow for exceptions when providing a keyboard alternative would invalidate the input. For example, spoofing GPS in a game might provide unfair advantage. Spoofing steps taken would invalidate health or fitness information. Spoofing heartrate or other sensors would invalidate health information. etc. It would have been helpful to receive feedback from the wider WG several years ago when these SC were planned so we could have been prepared for significant updates to SC 2.1.1.

Contributor

mraccess77 commented Feb 10, 2017

Any updates to SC 2.1.1 would have to allow for exceptions when providing a keyboard alternative would invalidate the input. For example, spoofing GPS in a game might provide unfair advantage. Spoofing steps taken would invalidate health or fitness information. Spoofing heartrate or other sensors would invalidate health information. etc. It would have been helpful to receive feedback from the wider WG several years ago when these SC were planned so we could have been prepared for significant updates to SC 2.1.1.

@mbgower

This comment has been minimized.

Show comment
Hide comment
@mbgower

mbgower Feb 10, 2017

Contributor

2.1.1 exception:

except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints. (Level A)
Note 1: This exception relates to the underlying function, not the input technique. For example, if using handwriting to enter text, the input technique (handwriting) requires path-dependent input but the underlying function (text input) does not.

From the Understanding doc:

The phrase "except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints" is included to separate those things that cannot reasonably be controlled from a keyboard.

Proposed Sensor exception:

unless the device sensor is essential for the function and not using it would invalidate the activity.

As a starting point for 2.1.1 (additions in bold):
In addition to its predominant mode of operation, all functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where either the underlying function requires input that cannot reasonably be controlled or approximated by a keyboard, or providing a keyboard alternative would invalidate the input.

Contributor

mbgower commented Feb 10, 2017

2.1.1 exception:

except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints. (Level A)
Note 1: This exception relates to the underlying function, not the input technique. For example, if using handwriting to enter text, the input technique (handwriting) requires path-dependent input but the underlying function (text input) does not.

From the Understanding doc:

The phrase "except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints" is included to separate those things that cannot reasonably be controlled from a keyboard.

Proposed Sensor exception:

unless the device sensor is essential for the function and not using it would invalidate the activity.

As a starting point for 2.1.1 (additions in bold):
In addition to its predominant mode of operation, all functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where either the underlying function requires input that cannot reasonably be controlled or approximated by a keyboard, or providing a keyboard alternative would invalidate the input.

@patrickhlauke

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke Feb 10, 2017

Member

+1 to both things @mbgower said (about extending the exception in 2.1.1 and bashing out something separately)

Member

patrickhlauke commented Feb 10, 2017

+1 to both things @mbgower said (about extending the exception in 2.1.1 and bashing out something separately)

@mraccess77

This comment has been minimized.

Show comment
Hide comment
@mraccess77

mraccess77 Feb 10, 2017

Contributor

Thanks @mbgower Those two exceptions: 1) cannot be approximated via the keyboard and 2) would invalidate the activity -- seem to cover the situations and sensors that I have thought about. Some sensors register things not based on user action -- those wouldn't apply to this but would also not pose a barrier to operation by nature of not requiring user action. But the exception does raise a question about the exceptions and requiring biological characteristics such as a fingerprint to login. Some legislation does allow non-keyboard access if more than 2 different biological characteristics are available. Similarly, one could argue that finger print access can't be approximated to a keyboard and allows for greater security from a typed in password and thus could pass SC 2.1.1. Should we attempt to address this in SC 2.1.1 as well?

Contributor

mraccess77 commented Feb 10, 2017

Thanks @mbgower Those two exceptions: 1) cannot be approximated via the keyboard and 2) would invalidate the activity -- seem to cover the situations and sensors that I have thought about. Some sensors register things not based on user action -- those wouldn't apply to this but would also not pose a barrier to operation by nature of not requiring user action. But the exception does raise a question about the exceptions and requiring biological characteristics such as a fingerprint to login. Some legislation does allow non-keyboard access if more than 2 different biological characteristics are available. Similarly, one could argue that finger print access can't be approximated to a keyboard and allows for greater security from a typed in password and thus could pass SC 2.1.1. Should we attempt to address this in SC 2.1.1 as well?

@mbgower

This comment has been minimized.

Show comment
Hide comment
@mbgower

mbgower Feb 10, 2017

Contributor

I'm having trouble thinking how a biometric reader factors into web authoring guidance. I would call that a hardware feature of the OS which is used for OS level authentication, and so is at best a user agent consideration, not an AGWG consideration. Maybe I'm missing something? Incidentally, a fingerprint is arguably less secure.

Contributor

mbgower commented Feb 10, 2017

I'm having trouble thinking how a biometric reader factors into web authoring guidance. I would call that a hardware feature of the OS which is used for OS level authentication, and so is at best a user agent consideration, not an AGWG consideration. Maybe I'm missing something? Incidentally, a fingerprint is arguably less secure.

@mraccess77

This comment has been minimized.

Show comment
Hide comment
@mraccess77

mraccess77 Feb 11, 2017

Contributor

To @mbgower others -- I have created a new issues #123 to update SC 2.1.1 to address the needs of this issue. I did not include anything on biometrics for authentication -- I'm retracting my discussion on that topic. If we all agree that updating SC 2.1.1 is the best approach we should close this issue and then label #123 appropriately an update to an existing SC.

Contributor

mraccess77 commented Feb 11, 2017

To @mbgower others -- I have created a new issues #123 to update SC 2.1.1 to address the needs of this issue. I did not include anything on biometrics for authentication -- I'm retracting my discussion on that topic. If we all agree that updating SC 2.1.1 is the best approach we should close this issue and then label #123 appropriately an update to an existing SC.

@kwahlbin

This comment has been minimized.

Show comment
Hide comment
@kwahlbin

kwahlbin Feb 13, 2017

Contributor

I think this should be a separate SC for 2.1 and should be revisited for the work done on Silver.

Contributor

kwahlbin commented Feb 13, 2017

I think this should be a separate SC for 2.1 and should be revisited for the work done on Silver.

@DavidMacDonald

This comment has been minimized.

Show comment
Hide comment
@DavidMacDonald

DavidMacDonald Feb 14, 2017

Contributor

I think if someone meets SC 2.1.1 this will also be covered... but I think what the MATF was getting at was that on a mobile device without lugging around an external keyboard. So how about this.

Functionality of the content requiring specific device sensor information, can also be operated with a simple pointer, unless the device sensor is essential for the function and not using it would invalidate the activity.

Contributor

DavidMacDonald commented Feb 14, 2017

I think if someone meets SC 2.1.1 this will also be covered... but I think what the MATF was getting at was that on a mobile device without lugging around an external keyboard. So how about this.

Functionality of the content requiring specific device sensor information, can also be operated with a simple pointer, unless the device sensor is essential for the function and not using it would invalidate the activity.

@mraccess77

This comment has been minimized.

Show comment
Hide comment
@mraccess77

mraccess77 Feb 14, 2017

Contributor

@DavidMacDonald making the change to simple pointer would drastically change the intent. It seems more appropriate for the pointer gestures SC. There doesn't seem to be consensus on this issue as some on this thread have made objections to block this.

Contributor

mraccess77 commented Feb 14, 2017

@DavidMacDonald making the change to simple pointer would drastically change the intent. It seems more appropriate for the pointer gestures SC. There doesn't seem to be consensus on this issue as some on this thread have made objections to block this.

@DavidMacDonald

This comment has been minimized.

Show comment
Hide comment
@DavidMacDonald

DavidMacDonald Feb 14, 2017

Contributor

That's fine on my end, no strong feelings.

Contributor

DavidMacDonald commented Feb 14, 2017

That's fine on my end, no strong feelings.

@mbgower

This comment has been minimized.

Show comment
Hide comment
@mbgower

mbgower Feb 14, 2017

Contributor

@DavidMacDonald

I think what the MATF was getting at was...on a mobile device without lugging around an external keyboard.

To make the tactical point clear, the 2.1.1 requirement on a keyboard method leads to a requirement for an "independent" method of control and input, since so many things can take advantage of the keyboard hooks. So it's not that I have to lug around a keyboard; it's that we counter the potential bias for the primary modality to be the only means of interacting.

Contributor

mbgower commented Feb 14, 2017

@DavidMacDonald

I think what the MATF was getting at was...on a mobile device without lugging around an external keyboard.

To make the tactical point clear, the 2.1.1 requirement on a keyboard method leads to a requirement for an "independent" method of control and input, since so many things can take advantage of the keyboard hooks. So it's not that I have to lug around a keyboard; it's that we counter the potential bias for the primary modality to be the only means of interacting.

@mraccess77

This comment has been minimized.

Show comment
Hide comment
@mraccess77

mraccess77 Feb 14, 2017

Contributor

@mbgower On the desktop a keyboard interface allows for hooking with all sorts of technology -- however on platforms like iOS you couldn't even open a custom on-screen keyboard on non-input web content and even if you could send keystrokes -- they are eaten by Safari and not even sent to the web content (tested with an external keyboard). So in practical sense this breaks down on one of the most popular mobile platforms.

Contributor

mraccess77 commented Feb 14, 2017

@mbgower On the desktop a keyboard interface allows for hooking with all sorts of technology -- however on platforms like iOS you couldn't even open a custom on-screen keyboard on non-input web content and even if you could send keystrokes -- they are eaten by Safari and not even sent to the web content (tested with an external keyboard). So in practical sense this breaks down on one of the most popular mobile platforms.

@jasonjgw

This comment has been minimized.

Show comment
Hide comment
@jasonjgw

jasonjgw Feb 14, 2017

That's why it says "keyboard interface" - the intention was never to require a physical keyboard, but to support assistive technologies that could emulate keyboard functionality. We searched hard for more general language that would work, as I recall, but found none.

That's why it says "keyboard interface" - the intention was never to require a physical keyboard, but to support assistive technologies that could emulate keyboard functionality. We searched hard for more general language that would work, as I recall, but found none.

@mraccess77

This comment has been minimized.

Show comment
Hide comment
@mraccess77

mraccess77 Feb 14, 2017

Contributor

@jasonjgw As I mentioned some mobile platforms don't allow for an on-screen keyboard to be opened in many situations. Some mobile browsers don't pass through keystrokes to the web content. The keyboard interface which is so well supported on desktop is not fully built on some mobile platforms and can';t be relied upon. Please show me an example of an assistive technology on iOS where I can send arrow keys to web content such as an ARIA combobox. No one has been able to produce one where the keystrokes actually make it to the web content.

Contributor

mraccess77 commented Feb 14, 2017

@jasonjgw As I mentioned some mobile platforms don't allow for an on-screen keyboard to be opened in many situations. Some mobile browsers don't pass through keystrokes to the web content. The keyboard interface which is so well supported on desktop is not fully built on some mobile platforms and can';t be relied upon. Please show me an example of an assistive technology on iOS where I can send arrow keys to web content such as an ARIA combobox. No one has been able to produce one where the keystrokes actually make it to the web content.

@alexswli

This comment has been minimized.

Show comment
Hide comment
@alexswli

alexswli May 5, 2017

alexswli commented May 5, 2017

@DavidMacDonald

This comment has been minimized.

Show comment
Hide comment
@DavidMacDonald

DavidMacDonald May 15, 2017

Contributor

Following up on @mraccess77 and having been on the mobile task force I can confirm that this is the intention of the SC, that the functionality would work with a simple pointer, because requiring users to stop and pull their keyboard out of a pack sack while using a mobile device is not really a mobile solution. I'm OK with the following wording for review by the wider group which I think is the original intention of the SC, and therefore no need to retire, unless we think the requirement is beyond the scope of 2.1.

All functionality requiring specific device sensor information can be operated with pointer, unless the device sensor is essential for the function and not using it would invalidate the activity.

Although, then both Keyboard 2.1.1 and this one would have to be met... that is 2 custom outlets for the functionality.

I think given the lack of momentum on this, and the overlap with 2.1.1, and the subsequent requiring authors to provide double fallback functionality (keyboard, and pointer) if we reword it as above, we could retire this SC and reconsider in a later version.

Contributor

DavidMacDonald commented May 15, 2017

Following up on @mraccess77 and having been on the mobile task force I can confirm that this is the intention of the SC, that the functionality would work with a simple pointer, because requiring users to stop and pull their keyboard out of a pack sack while using a mobile device is not really a mobile solution. I'm OK with the following wording for review by the wider group which I think is the original intention of the SC, and therefore no need to retire, unless we think the requirement is beyond the scope of 2.1.

All functionality requiring specific device sensor information can be operated with pointer, unless the device sensor is essential for the function and not using it would invalidate the activity.

Although, then both Keyboard 2.1.1 and this one would have to be met... that is 2 custom outlets for the functionality.

I think given the lack of momentum on this, and the overlap with 2.1.1, and the subsequent requiring authors to provide double fallback functionality (keyboard, and pointer) if we reword it as above, we could retire this SC and reconsider in a later version.

@mraccess77

This comment has been minimized.

Show comment
Hide comment
@mraccess77

mraccess77 Jun 12, 2017

Contributor

I'm happy to make edits to the proposed SC even if it ends up under 2.1.1 -- but from the discussion I don't see consensus on what edits I should make to this proposal.

Contributor

mraccess77 commented Jun 12, 2017

I'm happy to make edits to the proposed SC even if it ends up under 2.1.1 -- but from the discussion I don't see consensus on what edits I should make to this proposal.

@greg-lowney

This comment has been minimized.

Show comment
Hide comment
@greg-lowney

greg-lowney Jun 15, 2017

Contributor

@alexswli, just to set the record straight, 2.1.1 was not "written with the assumption that the only non-keyboard input device is a pointing device". We were very clear that it should address any input device that could emulate keyboard input as characters, keystrokes, or individual key up and down events--the most basic form of input, the one easiest to emulate, and the one that was already assumed to be baseline functionality. Such devices include standard or alternative keyboards, on-screen keyboards used through pointing devices or switches, as well as speech recognition, keyboard macros, and numerous other assistive technology techniques. We put in the exception for path-specific inputs because that was the one form of pointer input that cannot be emulated using a discrete input device ("keyboard interface") without a prohibitive amount of work on the user's part.

In the main 2.1.1 still applies in full, but does need an a broader or additional exception: (on mobile devices and elsewhere) software should (still) support full operation via attached keyboards and keyboard emulators, and therefore should not require other forms of input except where they are fundamental to the purpose of the application (e.g. an electronic level, a biometric key, or a GPS-focused application).

Contributor

greg-lowney commented Jun 15, 2017

@alexswli, just to set the record straight, 2.1.1 was not "written with the assumption that the only non-keyboard input device is a pointing device". We were very clear that it should address any input device that could emulate keyboard input as characters, keystrokes, or individual key up and down events--the most basic form of input, the one easiest to emulate, and the one that was already assumed to be baseline functionality. Such devices include standard or alternative keyboards, on-screen keyboards used through pointing devices or switches, as well as speech recognition, keyboard macros, and numerous other assistive technology techniques. We put in the exception for path-specific inputs because that was the one form of pointer input that cannot be emulated using a discrete input device ("keyboard interface") without a prohibitive amount of work on the user's part.

In the main 2.1.1 still applies in full, but does need an a broader or additional exception: (on mobile devices and elsewhere) software should (still) support full operation via attached keyboards and keyboard emulators, and therefore should not require other forms of input except where they are fundamental to the purpose of the application (e.g. an electronic level, a biometric key, or a GPS-focused application).

@alexswli

This comment has been minimized.

Show comment
Hide comment
@alexswli

alexswli Jun 20, 2017

@jasonjgw

This comment has been minimized.

Show comment
Hide comment
@jasonjgw

jasonjgw Jun 21, 2017

@mbgower

This comment has been minimized.

Show comment
Hide comment
@mbgower

mbgower Jun 21, 2017

Contributor

We need to decide whether to address biometric authentication devices here as well

Let's keep in mind that we're doing web authoring requirements. So there are two pretty obvious reasons why I think this is out of scope:

  1. In what scenario would a web author assume all devices being targetted would have biometric functions? And if someone did so, it's not just an accessibility issue since it will make the app unusable by a much larger user base. Seems out of scope.
  2. In what sense would a web page would make use of a such a function even if it were exposed by the OS to the user agent? It certainly won't be for web authentication.
Contributor

mbgower commented Jun 21, 2017

We need to decide whether to address biometric authentication devices here as well

Let's keep in mind that we're doing web authoring requirements. So there are two pretty obvious reasons why I think this is out of scope:

  1. In what scenario would a web author assume all devices being targetted would have biometric functions? And if someone did so, it's not just an accessibility issue since it will make the app unusable by a much larger user base. Seems out of scope.
  2. In what sense would a web page would make use of a such a function even if it were exposed by the OS to the user agent? It certainly won't be for web authentication.
@jasonjgw

This comment has been minimized.

Show comment
Hide comment
@jasonjgw

jasonjgw Jun 21, 2017

@KimPatch

This comment has been minimized.

Show comment
Hide comment
@KimPatch

KimPatch Aug 28, 2017

Contributor

Adding the key portions of the comments I put on the list 8/24/2017 3:08 PM and 8/26/2017 3:03 PM to keep everything in one place:

Addressing scope:
This SC is supposed to be about device sensors not working as a developer may expect for a person who has a disability because that person may not be able to manipulate a device – at all, precisely enough, or quickly enough.

The device sensor definition defines examples that are based on using sensors to take environmental measurements. These examples are an attempt to make it clear that "physical environment" refers to something apart from communication through an input device, and that environmental measurements include the location, motion and orientation of the device as a whole.

Device sensor: A device sensor is a device component that detects and responds to some type of input from the physical environment. Examples on mobile devices are the measurement of motion, orientation, and various environmental conditions.

If I'm reading your comments correctly, you may also have concerns with the last part of the definition "and various environmental conditions". I think we have work to do in making sure this is scoped to what a person with a disability is or is not able to do versus what is expected, and I think we can do that in the understanding document going forward.

Addressing request for additional use cases
Here are a couple more beyond the classic shake to undo mentioned in the current understanding text:

  • Tilt to advance to the next page
  • Pan to change the view in an interactive photo
  • Turn the phone to change map orientation
    (this may have implications for COGA as well). This includes the growing area of augmented reality, for example, star maps.

And here are a couple more that bear looking into:

  • GPS - someone providing remote eyes or interpretation for blind or map challenged folks may need a non-environmental way to control the GPS system on a remote phone
  • Microphone - having to make a noise or give an audio- based answer

In a world where the communications paths to a computer are becoming more varied, it's inevitable that some communications paths won't be appropriate for all users. Folks who find it difficult or impossible to interact with sensors that measure the effects of the environment on a mobile device need practical, mobile-appropriate alternatives.

Contributor

KimPatch commented Aug 28, 2017

Adding the key portions of the comments I put on the list 8/24/2017 3:08 PM and 8/26/2017 3:03 PM to keep everything in one place:

Addressing scope:
This SC is supposed to be about device sensors not working as a developer may expect for a person who has a disability because that person may not be able to manipulate a device – at all, precisely enough, or quickly enough.

The device sensor definition defines examples that are based on using sensors to take environmental measurements. These examples are an attempt to make it clear that "physical environment" refers to something apart from communication through an input device, and that environmental measurements include the location, motion and orientation of the device as a whole.

Device sensor: A device sensor is a device component that detects and responds to some type of input from the physical environment. Examples on mobile devices are the measurement of motion, orientation, and various environmental conditions.

If I'm reading your comments correctly, you may also have concerns with the last part of the definition "and various environmental conditions". I think we have work to do in making sure this is scoped to what a person with a disability is or is not able to do versus what is expected, and I think we can do that in the understanding document going forward.

Addressing request for additional use cases
Here are a couple more beyond the classic shake to undo mentioned in the current understanding text:

  • Tilt to advance to the next page
  • Pan to change the view in an interactive photo
  • Turn the phone to change map orientation
    (this may have implications for COGA as well). This includes the growing area of augmented reality, for example, star maps.

And here are a couple more that bear looking into:

  • GPS - someone providing remote eyes or interpretation for blind or map challenged folks may need a non-environmental way to control the GPS system on a remote phone
  • Microphone - having to make a noise or give an audio- based answer

In a world where the communications paths to a computer are becoming more varied, it's inevitable that some communications paths won't be appropriate for all users. Folks who find it difficult or impossible to interact with sensors that measure the effects of the environment on a mobile device need practical, mobile-appropriate alternatives.

@KimPatch

This comment has been minimized.

Show comment
Hide comment
@KimPatch

KimPatch Aug 28, 2017

Contributor

Also adding Patrick Lauke's explanation addressing why this SC is needed in addition to 2.1.1:

Phones/tablets have no keyboard interface - while they offer on-screen keyboards, these appear only in specific situations (generally, when the user is focused on an editable field), so they don't allow the user to arbitrarily press a key. For this reason, something that nominally passes 2.1.1 may still not work on these devices. This is the gap that the proposed SC Pointer was going to try and address (#59)

Also on screen keyboards are often only a subset of the full keyboard

Contributor

KimPatch commented Aug 28, 2017

Also adding Patrick Lauke's explanation addressing why this SC is needed in addition to 2.1.1:

Phones/tablets have no keyboard interface - while they offer on-screen keyboards, these appear only in specific situations (generally, when the user is focused on an editable field), so they don't allow the user to arbitrarily press a key. For this reason, something that nominally passes 2.1.1 may still not work on these devices. This is the gap that the proposed SC Pointer was going to try and address (#59)

Also on screen keyboards are often only a subset of the full keyboard

@patrickhlauke

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke Aug 28, 2017

Member

In fairness, I'd prefer an SC Pointer over this particular SC (as SC Pointer in combination with current SC 2.1.1 Keyboard would cover scenarios that this SC tries to address, as no matter what additional sensor a site/app uses, the same functionality would then need to be operable with keyboard AND a pointer - touchscreen, mouse, stylus...).

Member

patrickhlauke commented Aug 28, 2017

In fairness, I'd prefer an SC Pointer over this particular SC (as SC Pointer in combination with current SC 2.1.1 Keyboard would cover scenarios that this SC tries to address, as no matter what additional sensor a site/app uses, the same functionality would then need to be operable with keyboard AND a pointer - touchscreen, mouse, stylus...).

@mbgower

This comment has been minimized.

Show comment
Hide comment
@mbgower

mbgower Aug 28, 2017

Contributor

@awkawk, back in mid February you indicated we were initially going to tackle these as separate SCs. When does that phase stop, and we get to discuss the feasability of altering 2.1.1?

Just want to flag that #123 has the updated text for 2.1.1 to address this in the exception language more clearly.

Contributor

mbgower commented Aug 28, 2017

@awkawk, back in mid February you indicated we were initially going to tackle these as separate SCs. When does that phase stop, and we get to discuss the feasability of altering 2.1.1?

Just want to flag that #123 has the updated text for 2.1.1 to address this in the exception language more clearly.

@steverep

This comment has been minimized.

Show comment
Hide comment
@steverep

steverep Aug 28, 2017

Member

Reading through the mailing list thread which followed from the CFC and especially @patrickhlauke's responses, it's becoming readily apparent to me that the proposal doesn't actually state what is truly desired, and that has created much confusion. Whether or not it's too late for 2.1 I'll leave up to the chairs, but I would propose making the following changes to remove objections:

  1. Per many comments, the value is currently zero because the functionality must already be keyboard operable per 2.1.1, but what's really desired is not to have to plug in a keyboard. So why not just require a user interface component path to perform the same function? Then there's a clear distinction since the UI component should be pointer operable on screen.
  2. Objections based on scope, at least for me, could be cleared by talking about motion actuated functions rather than generically including all possible sensors.
  3. Not an objection, but I personally see much value in also making sure that such functions cannot be accidentally actuated by users with poor motor control.

So, here's the transformation I would propose with a note to clarify direct vs. indirect motion:

Motion Actuation: Functionality which can be operated by device or user motion can also be operated by user interface components and can be disabled to prevent accidental actuation, unless the motion is essential for the function and doing so would invalidate the activity.

Note: This criterion concerns input through sensors which respond directly to motions such as tilting, shaking, or panning. It is not intended to cover indirect motion associated with operating a keyboard, pointer, or assistive technology.

Not perfect I'm sure, but I could certainly live with it in the draft.

Member

steverep commented Aug 28, 2017

Reading through the mailing list thread which followed from the CFC and especially @patrickhlauke's responses, it's becoming readily apparent to me that the proposal doesn't actually state what is truly desired, and that has created much confusion. Whether or not it's too late for 2.1 I'll leave up to the chairs, but I would propose making the following changes to remove objections:

  1. Per many comments, the value is currently zero because the functionality must already be keyboard operable per 2.1.1, but what's really desired is not to have to plug in a keyboard. So why not just require a user interface component path to perform the same function? Then there's a clear distinction since the UI component should be pointer operable on screen.
  2. Objections based on scope, at least for me, could be cleared by talking about motion actuated functions rather than generically including all possible sensors.
  3. Not an objection, but I personally see much value in also making sure that such functions cannot be accidentally actuated by users with poor motor control.

So, here's the transformation I would propose with a note to clarify direct vs. indirect motion:

Motion Actuation: Functionality which can be operated by device or user motion can also be operated by user interface components and can be disabled to prevent accidental actuation, unless the motion is essential for the function and doing so would invalidate the activity.

Note: This criterion concerns input through sensors which respond directly to motions such as tilting, shaking, or panning. It is not intended to cover indirect motion associated with operating a keyboard, pointer, or assistive technology.

Not perfect I'm sure, but I could certainly live with it in the draft.

@patrickhlauke

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke Aug 28, 2017

Member

Point 1 really sounds like ... well ... SC Pointer (so I'd agree with it, but then would wonder if it's not better to see if SC Pointer can be revived or not).

On the additional suggestion on motion actuation, and in particular accidental activation, this would possibly gel with a generalisation of the new proposed SC Accidental Activation #330 (which currently is very focused on pointers/down-event activation, but should perhaps be generalised, which would then allow it to cover that scenario)

Member

patrickhlauke commented Aug 28, 2017

Point 1 really sounds like ... well ... SC Pointer (so I'd agree with it, but then would wonder if it's not better to see if SC Pointer can be revived or not).

On the additional suggestion on motion actuation, and in particular accidental activation, this would possibly gel with a generalisation of the new proposed SC Accidental Activation #330 (which currently is very focused on pointers/down-event activation, but should perhaps be generalised, which would then allow it to cover that scenario)

@DavidMacDonald

This comment has been minimized.

Show comment
Hide comment
@DavidMacDonald

DavidMacDonald Aug 29, 2017

Contributor

@steverep

So why not just require a user interface component path to perform the same function?

That's fundamentally what I proposed May 14 to deal with the redundancy.

@patrickhlauke

but then would wonder if it's not better to see if SC Pointer can be revived or not

That would require ALL functionality with Pointer. Steve's suggestion would only require fallbacks for Sensor activities, so it's not as wide.

this would possibly gel with a generalisation of the new proposed SC Accidental Activation #330

Perhaps, it's a considerable widening but if i got consensus ... ???

I could live with Steve's amendment. And think it's realistic to think it could get in, given that the SC is "still warm"
@awkawk @joshueoconnor

Contributor

DavidMacDonald commented Aug 29, 2017

@steverep

So why not just require a user interface component path to perform the same function?

That's fundamentally what I proposed May 14 to deal with the redundancy.

@patrickhlauke

but then would wonder if it's not better to see if SC Pointer can be revived or not

That would require ALL functionality with Pointer. Steve's suggestion would only require fallbacks for Sensor activities, so it's not as wide.

this would possibly gel with a generalisation of the new proposed SC Accidental Activation #330

Perhaps, it's a considerable widening but if i got consensus ... ???

I could live with Steve's amendment. And think it's realistic to think it could get in, given that the SC is "still warm"
@awkawk @joshueoconnor

@steverep

This comment has been minimized.

Show comment
Hide comment
@steverep

steverep Aug 29, 2017

Member

@DavidMacDonald, yes it appears you did propose that so I wonder why it was not followed up... the discussion got too wrapped up in the exception unfortunately. In any case, IMHO requiring user interface components is clearer than trying to mess around with defining "pointer input".

@patrickhlauke, I concur that Pointer #59 is similar with wider scope, but agree with @DavidMacDonald that the limited scope is much safer here with known problems for PWDs.

Member

steverep commented Aug 29, 2017

@DavidMacDonald, yes it appears you did propose that so I wonder why it was not followed up... the discussion got too wrapped up in the exception unfortunately. In any case, IMHO requiring user interface components is clearer than trying to mess around with defining "pointer input".

@patrickhlauke, I concur that Pointer #59 is similar with wider scope, but agree with @DavidMacDonald that the limited scope is much safer here with known problems for PWDs.

@jasonjgw

This comment has been minimized.

Show comment
Hide comment
@jasonjgw

jasonjgw Aug 29, 2017

Requiring a user interface component doesn't guarantee that it responds to pointer input - it might only satisfy 2.1.1. One could require a user interface component that is operable by pointer input instead. The concept of pointer input is required by other proposals, hence would not be new here.

I could certainly live with this proposal for purposes of a working draft.

Requiring a user interface component doesn't guarantee that it responds to pointer input - it might only satisfy 2.1.1. One could require a user interface component that is operable by pointer input instead. The concept of pointer input is required by other proposals, hence would not be new here.

I could certainly live with this proposal for purposes of a working draft.

@steverep

This comment has been minimized.

Show comment
Hide comment
@steverep

steverep Aug 29, 2017

Member

@jasonjgw, what types of UI components are designed to be operated via keyboard only?

Member

steverep commented Aug 29, 2017

@jasonjgw, what types of UI components are designed to be operated via keyboard only?

@jasonjgw

This comment has been minimized.

Show comment
Hide comment
@jasonjgw

jasonjgw Aug 29, 2017

@mbgower

This comment has been minimized.

Show comment
Hide comment
@mbgower

mbgower Aug 29, 2017

Contributor

what types of UI components are designed to be operated via keyboard only?

How about an text input field?

Contributor

mbgower commented Aug 29, 2017

what types of UI components are designed to be operated via keyboard only?

How about an text input field?

@patrickhlauke

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke Aug 29, 2017

Member

what types of UI components are designed to be operated via keyboard only?

you can easily create something, like a focusable <div>, which instead of a click JS handler listens for ENTER or SPACE keypresses. passes 2.1.1, can't be operated with a mouse/touch/stylus.

likely that developers would build such a thing? no. but if they do, that'd be exactly that gap that the SC Pointer wanted to plug.

Member

patrickhlauke commented Aug 29, 2017

what types of UI components are designed to be operated via keyboard only?

you can easily create something, like a focusable <div>, which instead of a click JS handler listens for ENTER or SPACE keypresses. passes 2.1.1, can't be operated with a mouse/touch/stylus.

likely that developers would build such a thing? no. but if they do, that'd be exactly that gap that the SC Pointer wanted to plug.

@patrickhlauke

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke Aug 29, 2017

Member

How about an text input field?

operating systems provide pointer-operable on-screen keyboards (either by default, or on request by user). but again, if it's not been coded in a way that is not a standard text entry field (e.g. <input type="text">) but something custom (a <div> and lots of custom keypress JS handlers), those would fail being operable by those OSKs

Member

patrickhlauke commented Aug 29, 2017

How about an text input field?

operating systems provide pointer-operable on-screen keyboards (either by default, or on request by user). but again, if it's not been coded in a way that is not a standard text entry field (e.g. <input type="text">) but something custom (a <div> and lots of custom keypress JS handlers), those would fail being operable by those OSKs

@mbgower

This comment has been minimized.

Show comment
Hide comment
@mbgower

mbgower Aug 29, 2017

Contributor

you can easily create something, like a focusable

, which instead of a click JS handler instead listens for ENTER or SPACE keypresses. passes 2.1.1, can't be operated with a mouse/touch/stylus.

But that is not restricted to accessibility. That is a 'feature' that affects all users. I question us needing to include an SC that will fail for every mobile user in the world. It's a basic usability issue. It sounds like the SC would become a rubber stamp, taking up space with no demonstrable value.
And, BTW, would it not be usable by pointer with any onscreen keyboard emulator, just like the text input?

Contributor

mbgower commented Aug 29, 2017

you can easily create something, like a focusable

, which instead of a click JS handler instead listens for ENTER or SPACE keypresses. passes 2.1.1, can't be operated with a mouse/touch/stylus.

But that is not restricted to accessibility. That is a 'feature' that affects all users. I question us needing to include an SC that will fail for every mobile user in the world. It's a basic usability issue. It sounds like the SC would become a rubber stamp, taking up space with no demonstrable value.
And, BTW, would it not be usable by pointer with any onscreen keyboard emulator, just like the text input?

@patrickhlauke

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke Aug 29, 2017

Member

And, BTW, would it not be usable by pointer with any onscreen keyboard emulator, just like the text input?

not on platforms where you cannot arbitrarily summon an on-screen keyboard. like phones and tablets.

Member

patrickhlauke commented Aug 29, 2017

And, BTW, would it not be usable by pointer with any onscreen keyboard emulator, just like the text input?

not on platforms where you cannot arbitrarily summon an on-screen keyboard. like phones and tablets.

@steverep

This comment has been minimized.

Show comment
Hide comment
@steverep

steverep Aug 29, 2017

Member

How about an text input field?

you can easily create something, like a focusable  

 , which instead of a  click  JS handler listens for  ENTER  or  SPACE  keypresses. passes 2.1.1, can't be operated with a mouse/touch/stylus.

Alright, my mistake for asking too vague a question... What UI components, meant to be an equivalent for a tilting or shaking function typically on a mobile device with no physical keyboard, are likely to be created by a non-devious developer to not be pointer operable? Yes, of course it leaves a hole, but not worth opening up defining what it means to be pointer operable for 2.1 at least. I'd live with it either way though.

Member

steverep commented Aug 29, 2017

How about an text input field?

you can easily create something, like a focusable  

 , which instead of a  click  JS handler listens for  ENTER  or  SPACE  keypresses. passes 2.1.1, can't be operated with a mouse/touch/stylus.

Alright, my mistake for asking too vague a question... What UI components, meant to be an equivalent for a tilting or shaking function typically on a mobile device with no physical keyboard, are likely to be created by a non-devious developer to not be pointer operable? Yes, of course it leaves a hole, but not worth opening up defining what it means to be pointer operable for 2.1 at least. I'd live with it either way though.

@patrickhlauke

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke Aug 29, 2017

Member

But that is not restricted to accessibility. That is a 'feature' that affects all users

except where the functionality is tied to something else (like motion sensor) and the assumption is that "normal" users will activate it this way, and that to make it accessible it's enough to provide something that just passes 2.1.1

Member

patrickhlauke commented Aug 29, 2017

But that is not restricted to accessibility. That is a 'feature' that affects all users

except where the functionality is tied to something else (like motion sensor) and the assumption is that "normal" users will activate it this way, and that to make it accessible it's enough to provide something that just passes 2.1.1

@patrickhlauke

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke Aug 29, 2017

Member

defining what it means to be pointer operable

if i recall the main pain point in that original discussion was about having to appropriately exclude situations where actual text entry is essential (and allowing developers to rely on on-screen keyboards rather than requiring them to code their own). so instead now we're wrangling with this other one, trying to make sure the wording has sufficient exclusions/limits in scope too. there doesn't seem to be an easy out either way. an SC Pointer would likely be cleaner of the two options, or we lose both that and this one.

Member

patrickhlauke commented Aug 29, 2017

defining what it means to be pointer operable

if i recall the main pain point in that original discussion was about having to appropriately exclude situations where actual text entry is essential (and allowing developers to rely on on-screen keyboards rather than requiring them to code their own). so instead now we're wrangling with this other one, trying to make sure the wording has sufficient exclusions/limits in scope too. there doesn't seem to be an easy out either way. an SC Pointer would likely be cleaner of the two options, or we lose both that and this one.

@steverep

This comment has been minimized.

Show comment
Hide comment
@steverep

steverep Aug 29, 2017

Member

@patrickhlauke, I guess I'm mainly thinking about things like touch gestures. In the context of this SC, if we said pointer input instead of UI component, then a passing grade would be given to, for example, turning a page by either tilting, a custom gesture, and a custom keyboard shortcut. But does that end up satisfying the user need?

Member

steverep commented Aug 29, 2017

@patrickhlauke, I guess I'm mainly thinking about things like touch gestures. In the context of this SC, if we said pointer input instead of UI component, then a passing grade would be given to, for example, turning a page by either tilting, a custom gesture, and a custom keyboard shortcut. But does that end up satisfying the user need?

@patrickhlauke

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke Aug 29, 2017

Member

Hmmm, I was going to say that the SC Pointer also includes something about being pointer accessible without requiring a specific "path of the user's movement" (similar to 2.1.1's wording), but I see it originally actually didn't. But no, movements/paths/swipes/gestures would also need to be not deemed appropriate as they can't necessarily be executed by all pointer users.

In any case, it seems there was no appetite for SC Pointer and it's too late now to try and reanimate that SC, sadly.

Member

patrickhlauke commented Aug 29, 2017

Hmmm, I was going to say that the SC Pointer also includes something about being pointer accessible without requiring a specific "path of the user's movement" (similar to 2.1.1's wording), but I see it originally actually didn't. But no, movements/paths/swipes/gestures would also need to be not deemed appropriate as they can't necessarily be executed by all pointer users.

In any case, it seems there was no appetite for SC Pointer and it's too late now to try and reanimate that SC, sadly.

@steverep

This comment has been minimized.

Show comment
Hide comment
@steverep

steverep Aug 29, 2017

Member

@kwahlbin, @KimPatch, and @mraccess77,

It seems my proposal has cleared all objections. Does this new wording work for you? It would be nice if we could get full consensus and perhaps another CFC to be closed by end of the week. Here's the wording repeated and I can make the GitHub changes if you'd like:

Motion Actuation: Functionality which can be operated by device or user motion can also be operated by user interface components and can be disabled to prevent accidental actuation, unless the motion is essential for the function and doing so would invalidate the activity.

Note: This criterion concerns input through sensors which respond directly to motions such as tilting, shaking, or panning. It is not intended to cover indirect motion associated with operating a keyboard, pointer, or assistive technology.

Member

steverep commented Aug 29, 2017

@kwahlbin, @KimPatch, and @mraccess77,

It seems my proposal has cleared all objections. Does this new wording work for you? It would be nice if we could get full consensus and perhaps another CFC to be closed by end of the week. Here's the wording repeated and I can make the GitHub changes if you'd like:

Motion Actuation: Functionality which can be operated by device or user motion can also be operated by user interface components and can be disabled to prevent accidental actuation, unless the motion is essential for the function and doing so would invalidate the activity.

Note: This criterion concerns input through sensors which respond directly to motions such as tilting, shaking, or panning. It is not intended to cover indirect motion associated with operating a keyboard, pointer, or assistive technology.

@mhakkinen

This comment has been minimized.

Show comment
Hide comment
@mhakkinen

mhakkinen Aug 29, 2017

Jumping in late (been out of office). Have been thinking about this for some time (given past research on mobile device sensors) and discussed this with Jason in the past week. I like Stephen's approach but wanted to offer something a little bit different.

SC Sensor-Based Input and Control

Applications that utilize sensors to detect user motion for input or to control functionality must provide (AA):

  • An alternate mechanism that allows an equivalent input or control action to be made in an accessible manner (for example, by exposing available motion-based actions to assistive technologies and/or providing a menu of available motion-based actions that can be invoked.)

  • A mechanism to disable the motion-based input to prevent accidental activation

Adjustment of motion-based input and control parameters (AAA):

  • A mechanism to adjust the range, intensity, or frequency of the motion required to invoke or
    register the user input.

Exceptions:

When providing an alternate input mechanism or disabling the motion-based input would invalidate the activity.

Background:

Web applications can today make use of device-based and externally connected sensors, such as accelerometers, magnetic compass, standard and depth (3D) cameras, proximity sensors, etc. These devices can be used to detect, for example, if a mobile device is in motion (including the direction and intensity of motion), or use a camera and motion detection algorithms to identify whether a user is waving their hand as a form of gesture input. While these capabilities offer a variety of usability benefits, they can also pose barriers for users with disabilities, which can include accidental activation of application input or functions by an individual with tremor, or the inability to input or control application features due to dexterity limitations.

Jumping in late (been out of office). Have been thinking about this for some time (given past research on mobile device sensors) and discussed this with Jason in the past week. I like Stephen's approach but wanted to offer something a little bit different.

SC Sensor-Based Input and Control

Applications that utilize sensors to detect user motion for input or to control functionality must provide (AA):

  • An alternate mechanism that allows an equivalent input or control action to be made in an accessible manner (for example, by exposing available motion-based actions to assistive technologies and/or providing a menu of available motion-based actions that can be invoked.)

  • A mechanism to disable the motion-based input to prevent accidental activation

Adjustment of motion-based input and control parameters (AAA):

  • A mechanism to adjust the range, intensity, or frequency of the motion required to invoke or
    register the user input.

Exceptions:

When providing an alternate input mechanism or disabling the motion-based input would invalidate the activity.

Background:

Web applications can today make use of device-based and externally connected sensors, such as accelerometers, magnetic compass, standard and depth (3D) cameras, proximity sensors, etc. These devices can be used to detect, for example, if a mobile device is in motion (including the direction and intensity of motion), or use a camera and motion detection algorithms to identify whether a user is waving their hand as a form of gesture input. While these capabilities offer a variety of usability benefits, they can also pose barriers for users with disabilities, which can include accidental activation of application input or functions by an individual with tremor, or the inability to input or control application features due to dexterity limitations.

@mbgower

This comment has been minimized.

Show comment
Hide comment
@mbgower

mbgower Aug 29, 2017

Contributor

@steverep 's latest addresses my concerns, and I can support that to CFC. @mhakkinen I think Steve's language covers what you have. Anything you add additionally can be a technique or in the understanding doc.

Contributor

mbgower commented Aug 29, 2017

@steverep 's latest addresses my concerns, and I can support that to CFC. @mhakkinen I think Steve's language covers what you have. Anything you add additionally can be a technique or in the understanding doc.

@patrickhlauke

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke Aug 31, 2017

Member

Regarding the motion actuation part, I'd once again point to #330 - seems more appropriate to generalise the normative SC language there to cover this too, rather than crowbarring this in here?

Member

patrickhlauke commented Aug 31, 2017

Regarding the motion actuation part, I'd once again point to #330 - seems more appropriate to generalise the normative SC language there to cover this too, rather than crowbarring this in here?

@steverep

This comment has been minimized.

Show comment
Hide comment
@steverep

steverep Aug 31, 2017

Member

Regarding the motion actuation part, I'd once again point to #330 - seems more appropriate to generalise the normative SC language there to cover this too, rather than crowbarring this in here?

I'm all for trying to make the accidental activation SC coverage more generic, but I certainly don't think a crowbar is needed to fit it in here. The new language is about motion actuation of functions, and the criterion would require being able to turn that off. Seems like a perfectly matching nut and bolt to me.

Member

steverep commented Aug 31, 2017

Regarding the motion actuation part, I'd once again point to #330 - seems more appropriate to generalise the normative SC language there to cover this too, rather than crowbarring this in here?

I'm all for trying to make the accidental activation SC coverage more generic, but I certainly don't think a crowbar is needed to fit it in here. The new language is about motion actuation of functions, and the criterion would require being able to turn that off. Seems like a perfectly matching nut and bolt to me.

@patrickhlauke

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke Aug 31, 2017

Member

IF the SC accidental activation was made more generic, you'd then have two places where the same problem would fail. which i'm sure happens in other situations even in current WCAG 2.0, but is nonetheless a bit awkward.

Member

patrickhlauke commented Aug 31, 2017

IF the SC accidental activation was made more generic, you'd then have two places where the same problem would fail. which i'm sure happens in other situations even in current WCAG 2.0, but is nonetheless a bit awkward.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.