W3C home > Mailing lists > Public > public-rqtf@w3.org > July 2019

Re: WoT Architecture Accessibility review notes

From: White, Jason J <jjwhite@ets.org>
Date: Wed, 10 Jul 2019 11:57:49 +0000
To: Joshue O Connor <joconnor@w3.org>, "public-apa@w3.org" <public-apa@w3.org>
CC: RQTF <public-rqtf@w3.org>
Message-ID: <095EDF61-8629-47AF-877D-F8EA17A53E17@ets.org>
Thank you, Josh.

An example of the problem might be as follows: a thermostat supports a WoT protocol, allowing monitoring and setting of the temperature in a building. The thermostat also supports configuration settings that automatically adjust the temperature based on various factors, such as time of day. The latter parameters are not accessible via the WoT protocols, but they are accessible via the UI of the device - which, however, is not accessible to a user with a disability, perhaps due to a physically unreachable location of the thermostat or due to accessibility limitations of the UI itself.

´╗┐On 7/10/19, 06:08, "Joshue O Connor" <joconnor@w3.org> wrote:

    Thanks Jason. Just some brief comments inline..

    On 09/07/2019 16:51, White, Jason J wrote:
    > Thank you, Josh, for these informative notes. I look forward to further discussion within the Research Questions Task force and the APA Working Group more broadly.
    > One question that comes to mind immediately is, in each case, how comprehensively the Web of Things protocols enable the use and operation of the device.

    That is a very good lens for our discovery phase questions but is even
    higher up in the stack that current thinking within the WoT group. As I
    understand it, much of WoT work is currently focussed on the network
    protocols etc, so a lower level. But a use case that comes to mind based
    on your question is, if user device needs to respond to node 'states' or
    device status in a network - such as in the navigation use case - then
    these nodes could drive or lead the user device in some way.

    The antithesis is that if there is an application that will handle this
    data, and just respond to what is coming from the network then thats
    fine, and arguable an application only problem - but in the future, as
    you mentioned, there may be cases where sensors do actually control a
    user device somehow. I hope this makes sense, and isn't too meta *grin.

    > Suppose a device has its own user interface that is not adequately accessible to the user. However, there is an accessible UI available for remote operation that depends on Web of Things protocols. Do the protocols sufficiently support the functionality of the device to enable the user to operate it remotely, or are there important (perhaps even essential) functions that can only be used via the "on device" UI, and which thus create barriers to access for the user due to missing features in the Web of Things implementation?
    Good question. What we need to do is to try to catch where we see
    potential gaps, even in the lower network layers that may bubble and
    become more complex abstractions that need to be mediated in a way that
    ultimately the user can understand (if it gets that far up the stack).
    My hunch is that at the very least if may be a case the AT needs to
    adapt to consume JSON-LD, which can extend a Thing Description to point
    to other suitable semantics, or languages that are supported by WoT
    > I would welcome comments on whether this statement of the problem makes good sense.
    Appreciated, thanks.


    Emerging Web Technology Specialist/A11y (WAI/W3C)


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.

Received on Wednesday, 10 July 2019 11:58:17 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 17 January 2023 20:26:46 UTC