Device sensors

[kwahlbin]

Current versions of SC and Definitions

• SC for viewing | SC for editing
• Device Sensor definition for viewing | Device Sensor definition for editing
• SC in full draft guideline

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 https://github.com/w3c/wcag21/issues/67#issuecomment-325716721

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]

Signing up as SC manager.

[mbgower]

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]

@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]

@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]

@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]

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]

@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]

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]

@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 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]

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

[jasonjgw]

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]

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]

Yes, fundamentally, if satisfying an SC makes a second SC pass automatically, then one of them is redundant and should not be included. Explaining the nuances is the purpose of the Understanding docuemnts, techniques, etc., so we don’t add success criteria just because the application of an existing requirement might not be obvious in certain cases.

---

This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.

Thank you for your compliance.

---

[DavidMacDonald]

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]

I think this entire proposal should be rewritten as a non-normative example of how to apply 2.1.1, unless it can be reworked in a way that eliminates the redundancy by clearly specifying what it requires that 2.1.1 doesn’t.

---

This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.

Thank you for your compliance.

---

[goodwitch]

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]

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]

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]

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]

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]

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]

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]

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

[mraccess77]

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]

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]

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]

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

[DavidMacDonald]

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]

@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]

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

[mbgower]

@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]

@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]

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]

@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.

[mbgower]

So in practical sense this breaks down on one of the most popular mobile platforms.

While I can enable VoiceOver and have keyboard control through a keyboard equivalent of VoiceOver gesture commands, I've always felt that was a pretty borderline way of meeting this requirement. But I'm not sure the shortcomings of the OS or user agent nullify the validity of the SC. In some ways, they make a stronger argument for its existence.

[mbgower]

BTW, should we be ending discussion in this thread and moving it to #123?

[kwahlbin]

This SC is saying that you cannot rely on specific device sensor information. What is in #123 is not addressing this. I strongly disagree with incorporating this into 2.1.1.

[jasonjgw]

I would move it to #123.

---

This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.

Thank you for your compliance.

---

[mbgower]

This SC is saying that you cannot rely on specific device sensor information. What is in #123 is not addressing this. I strongly disagree with incorporating this into 2.1.1.

@kwahlbin, maybe you can elaborate on what your concerns are? I'd like a better understanding beyond the fact you object. Earlier, you said:

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?

so I'm assuming that you believe it can potentially be addressed through language changes to 2.1.1.

What part of this Sensor candidate do you feel isn't being covered by the proposed language. I realize we are now straddling two issues with what is essentially the same topic, but I'm keeping this sensor-specific dialogue here, in the belief that #123 is going to end up addressing updates for more than just sensors.

BTW, I've avoided saying it until now so as not to make this topic messier, but I'll mention that unless one is talking strictly about creating a hybrid mobile application, any web page is going to have to avoid relying on sensors simply to avoid being unusable on the desktop.

[kwahlbin]

@mbgower We are adding even more confusion into 2.1.1 where most people already do not understand it. Without re-writing this to cover this and also the other related SCs that the mobile accessibility taskforce proposed, this really needs to be a separate SC. At this stage, I want to see this in the first draft and then we can look at incorporating the whole group of SCs into 2.1.1 but looking at this in isolation of all the other ones is a mistake.

[mraccess77]

Based on the request of the MATF co-chair I have created a pull request for this SC as is https://github.com/w3c/wcag21/pull/138

[mbgower]

@kwahlbin

where most people already do not understand it

What don't they understand, the wording or the principle? The principle is pretty easy: you have to be able to do everything with a keyboard. I agree that some of the additional wording around timing and path of movement tends to make it harder to understand, but we lose a bit of that confusion by making the exemptions less specifically about creating movement with a mouse. I don't see that the proposed changes make it more confusing.

looking at this in isolation of all the other ones is a mistake.

I would advocate that all of the items that can be addressed in 2.1.1 should have that done in this phase, before a public working draft. Otherwise, you are just unnecessarily creating churn for public reviewers.

Put another way -- what do you gain by breaking it out and forcing the public to look at each in isolation? What's the point of saying "Oh, we plan to incorporate this list of candidates into 2.1.1 later, BTW?" Why don't we take the list of items that have been ID'ed as potentially able to be addressed through 2.1.1 and do that work now?

[awkawk]

Just to clarify that for new criteria or criteria changes that could possibly be integrated into WCAG 2.1 via a change in existing language, we are still handling these the same way initially - as separate SC. https://lists.w3.org/Archives/Public/w3c-wai-gl/2017JanMar/0870.html

[awkawk]

Jon made a pull request, so closing the issue here. Discussion on the specifics of the pull request will take place at https://github.com/w3c/wcag21/pull/138

[awkawk]

Updated the issue description to reflect the FPWD text and reopening issue.

[DavidMacDonald]

Microsoft @alexswli commented #188 on this SC saying that it overlapped with 2.1.1. This is true, because the SC simply says that the functionality operated with device sensors can be operated without them, and 2.1.1 requires functionality to work with a keyboard.

So if we want to ensure device sensors functionality can be used in a way BESIDES keyboard then we would have to explicitly make that requirement. For instance,

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.

That makes it necessary for device sensor functionality to work with a pointer (in this SC) AND keyboard (in 2.1.1) Otherwise, we should retire this as it is covered in 2.1.1.

[jasonjgw]

David is right. If some functionality should always be available otherwise than using a keyboard (not always possible depending on the device), then that’s a worthy idea to discuss, and it’s a separate proposal. I think this one should be closed.

---

This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.

Thank you for your compliance.

---

[mraccess77]

David is right. If some functionality should always be available otherwise than using a keyboard (not always possible depending on the device), then that’s a worthy idea to discuss, and it’s a separate proposal. I think this one should be closed.

I thought that was always the intention of this SC to require operation of these inputs without a keyboard. Why couldn't we modify this SC to address that need? Also if we decide that SC 2.1.1 already covers sensor operations then we need to clearly communicate that as it's not obvious to the community today and the current exception is not sufficient for sensors as the wording of the current exception is not broad enough in my opinion so perhaps sensors for pedometer would currently fail SC 2.1.1

[jasonjgw]

I support adding a clarifying example to 2.1.1. I don’t know of a good reason why functionality involving device sensor information is the right class of functionality for which to require a method of operation other than a keyboard. It may be within the class, but making it the total class seems arbitrary.

---

This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.

Thank you for your compliance.

---