Re: CFC Add Device Sensors to Editors Draft

Hi Steve,

I agree that the decision to put this in the next draft might have been a bit hasty.
I will comment between the lines below.

> -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,

DF: I don't think this is what the SC says. I think it says that if *web content* chooses to activate particular functions based on device sensor information, there should also be a different way to activate those functions.
This may be provided by the OS (e.g. locking orientation so an orientation sensor will have no effect) or by explicit controls (e.g. providing an undo function when detecting shake to undo.)
Another example: If an app should detect ambient light to switch to a night mode, that might be a welcome feature, but it should not be the only way to set presentation mode.

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

DF: I agree we should be clearer in separating addtional sensors from "basic pointer and keyboard". Admittedly this is not easy to formulate in a future-proof way but perhaps doable, Touch has dimensions (pressure, tilt) that would count as additional sensor input. So would sensor(s) that detect the hand hovering over a device. 

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

DF: I do not see a problem in the fact whether sensor data are used raw or processed. If the source of processed information contains ioput from sensors that go beyond keyboard and basic touch, then it would fall under this SC.
> 
> 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.

DF: I think this is not the intention of the SC and I don't read it as a disincentive to use advanced sensor input that might benefit users with disabilities. The requirement isd opnly that there must be other ways to do the same thing. Note that for many common uses on the OS level, alternatives exist (e.g. for unlocking a device there is a fallback of pin key input). The same would be required should advanced web apps draw on fingerprint readers, face detection, voise detection etc (I have not seen any that do that but it seems feasible / likely to happen). So when a web author would want to include authorisation in an app, this SC might basically tell authors: Do not rely soley on fingerprint / face recognition etc - there must be an alternative to authenticate.
> 
> 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.
> 
DF: You may be right here - I would not be against discussing this again in one of the next telcos following your objection - what is the WG protocol in these cases?
>  
> 
> 
> 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 <https://www.w3.org/2002/09/wbs/35422/Top3_18Apr2017/results> 
> GIT Hub: https://github.com/w3c/wcag21/issues/67 <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 <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
> 
>

Received on Friday, 23 June 2017 10:08:20 UTC