RE: CFC Add Device Sensors to Editors Draft

-1

Sorry folks.  Albeit in fewer words than I’ll do here, I feel I brought up a very significant issue with the normative text of this SC both on the survey and call, and it was neither addressed in the text nor discussed and explained why my concerns might be invalid.

Since in its simplest form the SC says don’t use device sensors unless you really need them, the linchpin really is the definition of “device sensor”, which now only says: “additional input values such as tilt, orientation, proximity”.  This is extremely ambiguous because it only provides a few examples rather than an actual definition, which then falls back to the dictionary definition for sensor which is extremely broad.  It also says “additional” but what this is exactly in addition to is left up to the reader.  If this is supposed to mean in addition to standard input methods like a keyboard, mouse, and/or touchscreen, then that needs to be stated clearly in the normative guidelines, especially considering all of those are devices that confusingly use sensors themselves (e.g. optical sensing on a mouse, capacitive or resistive sensing on a touchscreen, and various depression sensing on keys).  Furthermore, the examples are of processed data that may be calculated using one or more sensors and not examples of the actual sensors used.  Ironically, the sensor data used to create the single example problem in the proposal, shaking to undo, is not even given as an example here, i.e. accelerometer analysis.

As written now, the criterion also seems to take the valid problem case of requiring physical motion that may be very difficult or impossible, and generalize it to presuming that using device sensors is somehow always going to have accessibility issues.  Devices are being packed with more and more sensors, and for most scalar ones not based on motion, I don’t think we have any examples of where they create a problem for users with disabilities (e.g. GPS, thermometer, microphone, light brightness, barometer, or the myriad of external device sensors which can be purchased).  In fact, many of these can be used to create accessibility where none existed before, but the criterion would make most such apps pass via exception which seems backwards and detracts from the true problem.  The scope is simply too wide.

I fail to see how due diligence is being done here compared to other proposals which have gone through many painstaking iterations to fully or partially address all working group concerns.

Steve

From: Joshue O Connor [mailto:josh@interaccess.ie]
Sent: Tuesday, June 20, 2017 1:04 PM
To: WCAG <w3c-wai-gl@w3.org>
Subject: CFC Add Device Sensors to Editors Draft

Call For Consensus — ends Friday June 23rd at 1:00pm Boston time.

The Working Group has reviewed and approved a Success Criterion for inclusion in the Editor’s Draft: "Device Sensors" with the goal of obtaining additional input external to the working group.

NOTE: The resolution  was to Accept this SC into editors draft and include a note to say that the preference of the group is to alter an existing SC rather than add a new one.

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


Survey results:
https://www.w3.org/2002/09/wbs/35422/Top3_18Apr2017/results

GIT Hub: https://github.com/w3c/wcag21/issues/67

The new SC can be reviewed here:
https://rawgit.com/w3c/wcag21/device-sensors_ISSUE-67/guidelines/sc/21/device-sensors.html

If you have concerns about this proposed consensus position that have not been discussed already and feel that those concerns result in you “not being able to live with” this decision, please let the group know before the CfC deadline.

Thanks
--
Joshue O Connor
Director | InterAccess.ie