Re: CFC Add Device Sensors to Editors Draft

I have to agree, Steve.

Cheers,
David MacDonald



*Can**Adapt* *Solutions Inc.*

Tel:  613.235.4902

LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>

twitter.com/davidmacd

GitHub <https://github.com/DavidMacDonald>

www.Can-Adapt.com <http://www.can-adapt.com/>



*  Adapting the web to all users*
*            Including those with disabilities*

If you are not the intended recipient, please review our privacy policy
<http://www.davidmacd.com/disclaimer.html>

On Fri, Jun 23, 2017 at 6:58 AM, Repsher, Stephen J <
stephen.j.repsher@boeing.com> wrote:

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