W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > April to June 2017

RE: CFC Add Device Sensors to Editors Draft

From: Repsher, Stephen J <stephen.j.repsher@boeing.com>
Date: Fri, 23 Jun 2017 19:30:56 +0000
To: Detlev Fischer <detlev.fischer@testkreis.de>, "josh@interaccess.ie" <josh@interaccess.ie>, "w3c-wai-gl@w3.org" <w3c-wai-gl@w3.org>
Message-ID: <9c7eee5364b14f9a8d76ee6c401728fc@XCH15-08-08.nw.nos.boeing.com>
Hi Detlev

Thanks for continuing the dialogue here.  I added a few more comments below.  Have a great weekend.

Steve


-----Original Message-----
From: Detlev Fischer [mailto:detlev.fischer@testkreis.de] 
Sent: Friday, June 23, 2017 6:08 AM
To: josh@interaccess.ie; w3c-wai-gl@w3.org; Repsher, Stephen J <stephen.j.repsher@boeing.com>
Subject: 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.) 
[Steve] I agree that the criterion is limited to functionality (which has a WCAG 2.0 definition that ought to be linked) and I oversimplified to make the point about the deficiency in the glossary term.  However, the criterion certainly does not say anything about alternate mechanisms that can be relied upon for conformance.  If we're going to be mixing in conformant functions provided solely by the user agent (and I think we absolutely need to considering this is about a device's sensors), then that goes down the path of "a mechanism is available to..." language.

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.
[Steve] I think this is actually an example of the scope creep to which I referred.  The disability group this might affect would be users with low vision, and would belong in a "perceivable" guideline and not an "operable" one.  Besides, if I can control night mode via the OS, where's the violation?  I would consider it a pretty serious bug in the API if a device actually allowed content authors to lock in night 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. 
[Steve] Personally, I think keyboards and touchscreens are both sensors too, and there's really no way to future-proof this if we're focused on an SC based solely on the mere use of sensor data.  The user problem for people with disabilities is not the sensors or their data, it's the potential ways in which it might be used, such as requiring physical motion.

> 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.
[Steve] I think I mostly agree with you that raw vs. processed is not an issue, but it's certainly very confusing to me at least.  The examples of orientation and tilt are really the same data, both coming from the device's gyroscope.  Sensing a shake can come from an accelerometer and/or gyroscope.  Something like "sensor-derived" data would be a better description, but that's far from the biggest problem here.  Again, where is "beyond keyboard or basic touch" mentioned anywhere in this criterion?

> 
> 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.
[Steve] I agree that's not the intention.  My arguments are based on what the normative text proposal actually says and not its perfectly valid intention.

 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.
[Steve] Again, I think scope is a problem here.  That's a perfectly valid potential user problem, but it seems you're expecting this to be a catch all for all types of situations, many of which may have no real disadvantage to users with disabilities compared to other users, and thus go beyond the scope of WCAG.  We should either call out the specific problem situations to avoid or provide alternatives for, or better yet state the accessible way to do it.

> 
> 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/2

> 1/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 19:31:35 UTC

This archive was generated by hypermail 2.3.1 : Friday, 23 June 2017 19:31:36 UTC