Just over a year ago, I wrote about TPGi joining the W3C Web of Things (WoT) Interest and Working Groups, so I thought it was about time I provided an update on some of the activities the group is involved in, particularly now that I am now more actively involved after spending my first several months keeping a watching brief.
Background
The Internet of Things (IoT) represents the networking of “things” (whether physical or digital) within the existing internet infrastructure. For example, consider a single device that controls the heating, lighting and security of your home. Each of these physical components represents a “thing” in the network, so can be controlled from elsewhere on the internet.
Until recently, however, ensuring smooth communication between diverse things without any form of human involvement was problematic. Early efforts were built on non-interoperable, occasionally proprietary, technologies and standards – thus making it extremely difficult (if not impossible) to combine things built by different vendors into a common network.
To resolve this issue, the Web of Things Interest Group (WoT IG) was launched in 2015 with the aim of investigating – through use cases, requirements, and proposals from a variety of stakeholders (such as developer communities, industry, academia, and so on) – how communication between things could be standardized via existing and emerging non-proprietary standards. The overall goal, therefore, is to allow vendors to concentrate purely on building the specific features of their thing without having to worry about how it might fit into the overall WoT network. Think of this concept in terms of HTML – we use a common set of elements and attributes to mark up Web content, all of which are widely supported by different browsers, assistive technologies, and operating systems. From a technological point of view, developers do not need to (or shouldn’t need to) concern themselves as to whether their website will work as expected when using a certain browser or operating system – they only need to concentrate on developing their website or web application itself. The same idea is being applied to the physical world of things.
The Web of Things Working Group (WoT WG) works closely with the WoT IG, and is specifically tasked with formally standardizing aspects of the IG that are deemed as mature enough to be considered potential W3C recommendations. One way this manifests itself is through semi-regular PlugFests, where both members and non-members come together to demonstrate proposals and prototype proofs-of-concept, all of which are based on the current draft specifications.
Currently, there are four specific areas, or building blocks, that the WoT WG are tasked with standardizing, each of which is represented by its own Task Force (TF) within the IG/WG. These building blocks are described in more detail in the Web of Things (WoT) Architecture document:
Thing Description (TD)
The TD is a semantic, machine understandable, formal specification that forms the central building block of a WoT device, independent of the actual implementation. It represents a mechanism for describing – among other things – what the thing is (for example, a light), what its properties are (such as its status, e.g. on or off), what actions can be performed (switching the light on or off), and any associated events (a warning that the bulb needs replacing). Web Linking is also included within the description to describe the relationship between things and to allow the thing to be exposed to other things within the network. TDs are often described as the “index.html of the thing”, and this is quite an apt metaphor. If you think of a standard web page, it has a title, various landmarks (header section, footer, navigation), headings, lists, buttons, links and so on. Each of these is marked up using the appropriate HTML elements (title, header, ul, h1, button etc.). The TD essentially follows the same premise – it represents a way of “marking up” the networking capabilities of the thing.
TDs are (currently) presented in JSON-LD format. A First Public Working Draft (FPWD) of the Thing Description specification was released in September 2017.
Scripting API
This building block is built on top of the TD to essentially allow for a common runtime environment (similar to a Web browser) to be built on the thing. This allows for things within a network to discover, consume, and expose data without having to delve into a particular device’s firmware to find this information. Again, having a standardized scripting API means that a vendor need not concern themselves with how content is rendered or exposed. Think of this issue in terms of websites – a developer need not build an entirely new, proprietary, browser for every Web product they produce.
An FPWD of the Scripting API specification was also released in September 2017.
Binding Templates
As previously mentioned, many standards and protocols have already been developed that are applied already across different devices. While many of these standards and protocols contain common elements, they also may include important data that is provided in a peculiar, non-standard, format that does not easily fit into an existing TD. Binding Templates are intended to act as a “go-between” between these early standards and protocols, and the standardized TD, and are included as an extended vocabulary within the TD. The idea behind binding templates is to ensure that older and/or non-standardized products can be adapted to fit into the newer standardized network.
For further information, refer to the Editors Draft of the Protocol Binding Templates specification.
Security and Privacy
From a lay person’s perspective, security and privacy is obviously a major concern when one thinks of the Internet of Things. This building block defines a set of security objectives for WoT devices based on common scenarios in different environments, such as the home, industry, and enterprise, as well as more general guidance on designing and deploying secure and privacy-respecting devices.
Further information is provided in the Web of Things Security and Privacy WG note.
Implications for accessibility
In my previous blog post on accessibility and the WoT, I argued that the WoT opens up many benefits for accessibility, opening up doors to people who otherwise may not have been able to operate particular physical devices or even to independently take part in certain activities.
It is important to note that the WoT IG and WG are both concerned primarily with machine-to-machine interaction, rather than specifically in terms of user interfaces. Yet, even at this low level, there are implications for accessibility. Even the smallest thing on the network may need some form of basic platform accessibility support to make information about the thing available to assistive technologies – for example, is this thing on or off? Is it overheating? Does the user need to change something (e.g. a bulb)?
Consequently, we need to consider accessibility support is provided at the API level, ensuring that information that is eventually exposed to user interfaces and assistive technologies is done so in an accessible manner, and with little to no extra effort required by vendors at this level. For many years, and along with our colleagues and peers in the overall accessibility environment, we have vigorously fought to ensure standards are developed in such a way to ensure that features are accessibility supported. We have thus far been successful in ensuring that the Web world is accessibly supported – now it’s time to move into the physical world.
My next steps are to produce detailed use cases which consider the potential opportunities and challenges for accessibility within the WoT. The following table provides a high level mapping between each of the above building blocks and the potential role of accessibility research.
| Building block | Accessibility considerations |
|---|---|
| Thing Description | Are things described in a way that will eventually allow vendors to recognize and support agnostic interfaces (i.e. do not rely on the eventual user being able to see/hear/operate by voice or touch)? If not, is it possible to provide alternatives? |
| Scripting API | Given that even the simplest of things will need to expose their state, how will an assistive technology user be able to get information about the current state in the absence of a runtime environment? Does the scripting API support the development of rudimentary runtime environments that allow external assistive technologies to query information about the thing? |
| Binding Templates | If a non-standardized device includes helpful accessibility metadata that isn’t necessarily part of the TD specification, can this easily be included in the new TD? Is it possible to retroactively provide helpful accessibility metadata to non-standard or legacy devices that don’t include it as part of their description? |
| Security and Privacy | Are privacy provisions provided in a way that a non-technical person, or even a person with a cognitive impairment, is likely to understand and act on? Can we make sure that devices don’t (explicitly or not) share accessibility information with third-party services? Within the healthcare sector, WoT devices have the potential to be life threatening if anything goes wrong; how do we consider this as part of the security of the device? |
This is an exciting area which poses a lot of challenges and opportunities to include disabled people. If you have suggested use case for accessibility within the WoT I’d be interested to hear about it!