Answers to accessibility (FAST) review checklist (from here) for the Web of Things (WoT). These answers are generally written to be applicable to all WoT deliverables, including:
- Web of Things (WoT) Architecture 1.1 (update)
- Web of Things (WoT) Thing Description 1.1 (update)
- Web of Things (WoT) Discovery (new)
- Web of Things (WoT) Profile (new)
- Web of Things (WoT) Scripting API (update, informative)
Where a response is specifically relevant to a particular deliverable that
will be identified.
"WoT TD" will be used as a short form for "WoT Thing Description".
In general, WoT is concerned with enabling access to IoT devices at the protocol and network interaction level. The deliverables currently do not directly address aspects of user interfaces such as visual display or physical I/O devices. However, the purpose of WoT is to integrate physical devices with network controls, and in fact these physical devices will have physical inputs and outputs that are relevant to accessibility, especially when integrated with other systems, including web browsers, to provide data and control.
WoT has the potential to enable enhanced accessiblity by permitting, for example, the integration of custom input devices into web technology, or the ability to control devices such as locks or switches by alternative controls, or remapping of sensor outputs into different sensory modes (for example, remapping an indicator light on a device into an audible alert), or the mapping of data from web services into alternative output devices. Unfortunately fully enabling many of these use cases will require additional standards work and implementation effort not in the scope of the current charter. However, the current specifications have laid the technical foundations that allow for these use cases to be addressed in the future.
Many of the following questions are designed to be interpreted in the context of
web browser rendering of content.
We have re-interpreted these questions in the context
of user interfaces supported by WoT-enabled IoT devices.
The WoT architecture does not directly support visual rendering of content. Some devices adhering to WoT standards may have visual display aspects, for example light bulbs that can be turned on or off, or small displays. However, WoT in general has no provision to constrain visual displays, as this (and other controls limiting the behavior of devices) was not in the scope of our current charter.
No, there is no defined way. However, it is certainly possible to do so. It is even possible to use WoT to access IoT device states, such as the hue of a light bulb, in an existing system, and map them to audible outputs. There is not a defined mechanism, but it is possible to build IoT systems that support it.
No specified mechanism, although it would be possible for a WoT Thing implementation supporting a display function to provide this capability.
No specified mechanism, although WoT TDs for lights usually have such controls, and WoT supports them, so it would be possible to built systems using WoT with luminosity and hue that can be adapted to user needs.
No specified mechanism, although WoT TDs for WoT Things with visual displays may support controls that allow attributes of text, such as font and boldness, to be modified.
No specified mechanism, although WoT TDs may support such controls.
No specified mechanism for changing content presentation, and in particular there are no controls preventing unreadability.
[no] Technology does not allow blinking or flashing of content, or provides a feature for users to quickly turn it off or permanently disable it.
WoT does not constrain device behaviour and in particular does not prevent devices from flashing. The way to handle this (which was not in the scope of our current charter) would be to define a standard model for lights (and other devices with visual output) that included this feature. This could take the form of a set of WoT Thing Models and a set of accessibility design guidelines for IoT devices, and is something we could consider for future work.
Not applicable.
Generally, WoT does not mandate mechanisms for control of color, although some devices adhering to WoT may be able to display color. As stated above, WoT in general has no provision to constrain visual displays, as this (and other controls limiting the behavior of devices) was not in the scope of our current charter.
Not supported; or rather, there is no specified mechanism. In general, though, it would be possible to use intermediate WoT Things (aka Servients, which act as both server and client, and in this case would be a kind of proxy) to generally modify commands sent to Things, and in particular cases this could be used to modify parameters like color choices. What is still needed, however, and which is not in the current specification, is a standard way to identify which properties of an WoT thing correspond to a particular UI element on the physical device.
[no] There is a feature for authors to define semantically available "color classes" that users can easily map to custom colors, and give preference to this vs. coloring objects individually.
Not directly supported. It could, however, be implemented on top of the current specification.
Not directly supported. It could, however, be implemented on top of the current specification.
Not directly supported.
Not directly supported.
Not directly supported.
Devices adhering to WoT may in fact provide various forms of user input, such as buttons, dials, touch panels, etc. In general, WoT does not constrain the behavior of such devices but does make information available which can be used to enhance their accessibility.
WoT TDs have a "title" attribute for interactions which can be used to label an associated input control (but only if the device with the input control is capable of displaying text in association with the control, which is often not the case).
WoT TDs, in addition to "title", also have a "description" field which can contain extended text. In addition, a "link" can be used to hyperlink external documentation.
[partial] If there is an input error, it is possible to associate the error message clearly with the specific control that is in error.
To the extent that interactions in TDs are associated with input controls, then an error on an interaction can be associated with that control.
This is possible but not explictly required by WoT. A Thing representing an input device usually is designed to report the actual state of that device. However, a WoT system can use a "shadow" to intercept and override the states reported by other Things.
[yes] Authors can address multiple types of input hardware (keyboard, pointing device, touch screen, voice recognition, etc.), or the technology supports hardware-agnostic input methods.
Definite yes. WoT can be used to describe and enable network interfaces to a wide variety of input devices and make this data available for any purpose.
[partial] User input does not require specific physical characteristics (e.g., fingerprint readers).
WoT itself does not require any specific physical characteristic, but a specific WoT Thing may. However, it is the nature of WoT that one Thing can be substituted for another, so in this case a problematic device could be replace with another one with the same network interface but with different physical controls.
Orders of interactions with WoT Things are not generally constrained.
[yes] For every user interface object type, the "type" of object can be exposed as a role to accessibility APIs.
WoT exposes a powerful mechanism, based on RDF and JSON-LD, to add semantic types to Things and interactions.
[yes] For every user interface object type, there is a clearly defined mechanism for authors to provide and / or user agents determines the "accessible name" for accessibility APIs.
As mentioned above, textual information can be associated with all Things and interactions on Things.
[yes] For user interface objects that can have states, properties, or values, authors can set these and these can be exposed to accessibility APIs.
This is the general purpose and goal of WoT.
[yes] When providing imperative mechanisms to implement technology features (e.g., scripts), authors can expose accessibility information to accessibility APIs.
The WoT system includes an (informative) document describing a scripting API for programmatically interacting with WoT Things and exposing WoT network interfaces and Thing Descriptions. Thing Descriptions can then be read and interpreted by other systems, including accessibility API implementations. Even though the scripts are imperative, the necessary information to talk to a Thing is given in a declarative fashion in the Thing Description.
There are no "widgets" per se, but help information about a Thing can either be embedded in a Thing Description or be made available via a link.
WoT does not define "documents" per se, but declarative descriptions called Thing Descriptions (TDs). TDs in some cases fill the role of the "index.html" file on the regular Web, and they are considered the access point to the network API for a Thing.
There are mechanisms to add "titles" (and "descriptions") to an entire Thing Description.
There are mechanisms to add "titles" (and "descriptions") to individual interactions described in a Thing Description.
Hyperlinks in WoT TDs include the target URL and a relation type (specifying the function).
There is a mechanism to define a default language, and also for textual content to be provided in multiple languages clearly identified with language tags.
[no] Authors can support understanding of abbreviations / acronyms / initialisms, idioms, jargon, etc.
There is no built-in mechanism to support definitions or expansion of specialized terms. Authors, however, can of course expand acronyms in the text they provide.
[no] Authors can support correct machine pronunciation of ambiguously spelled terms (e.g., in the phrase "I am content with this content" there are different correct pronunciations of the lexeme "content").
WoT TDs have a prescribed structure that limit where content can be placed, and there is one top-level such location.
[yes] Declarative mechanisms (that have accessibility semantics pre-defined in the spec) are used to implement technology features whenever possible.
WoT TDs, which the WoT architecture is based on, are declarative in nature.
[yes] There are unambiguous ways to express relationships between units of content, such as object nesting, ID referencing, etc.
Linking through URIs is the supported mechanism for relating different documents. Within a single WoT TD, JSON Pointers and named objects are also used. WoT TDs also have a mandatory nesting structure which is validated.
WoT TDs are structural in nature.
[not applicable] When providing presentational semantics, they can be easily mapped to structural semantics, e.g., to support restyling or meaningful exposure to accessibility APIs.
WoT TDs have no presentational semantics.
[no] Support a comprehensive set of authoring use cases to minimize the need for alternative content. (e.g., don't make authors resort to text in images to get the style they want).
Where text is required, it can only be text, not images, and vice-versa. However, images are only supported in the specific case of icons for Things and interactions, and there is always associated textual elements in these cases also.
Referencing a specific location within a WoT TDs can be done with a JSON Pointer, which is included as the fragment identifier in the IANA Consideration.
WoT TDs are structural and declarative in nature, not presentational.
WoT itself does not directly provide support for time-based visual media,
although some applications can do so or can be associated
with visual media display devices.
In such cases, however, WoT does not provide a means to annotate
or manipulate the content itself, but only the means to
describe controls for the devices that produce or display
the content.
[n/a] It is possible for authors to provide detailed text descriptions, audio descriptions, or both of the important content in the media.
WoT does not constrain or affect the media content itself.
WoT does not constrain or affect synchronization of the media playback.
WoT does not constrain the display of media.
WoT Things controlling media playback can and usually do have such controls, although they are not enforced by WoT. Defining interfaces for specific device classes was considered out of scope of the current WoT charter.
It would be possible to use a WoT TD to describe a device with such functionality, but it is not mandatory.
WoT itself does not directly provide support for audio, although some applications can do so or can be associated with audio input or output. In such cases, however, WoT does not provide a means to annotate or manipulate the content itself, but only the means to describe controls for the devices that produce or record the content.
[n/a] It is possible for authors to provide synchronized captions, either open (on by default for all users).
WoT Things controlling audio playback can and usually do have such controls, although they are not enforced by WoT. Defining interfaces for specific device classes was considered out of scope of the current WoT charter.
WoT does not directly control or constrain this aspect of audio.
It would be possible to use a WoT TD to describe a device with such functionality, but it is not mandatory.
[n/a] Technology does not include triggers for audiosensitive seizures or allows those triggers to be disabled.
WoT does not include a mechanism to prohibit such triggers from devices adhering to WoT standards.
WoT does not generally include time limits, but individual devices may have such time limits, for example, to detect multiple presses on a button.
There is no general feature in WoT to extend time limits, although a given Thing can implement such features (e.g. IoT devices often have controls allowing users to specify the maximum delay between button presses to consider them as a single "multi-press" input event).
[possible] Time limits for different parts of a task, such as reading instructions vs providing input, can be set separately.
If time limits are supported by a particular WoT Thing, it is up to the implementor of the Thing to provide time limit controls at a suitable level of granularity.
While both icons and text can be defined in some cases, in general only text is supported.
The only non-text content allowed are icons, and these are always associated with textual information (titles) that can be used as a replacement.
WoT TDs allow the embedding of textual titles and descriptions for interaction and Things.
Both short and long text (title and descriptions) are supported. In addition, links to external documentation can be referenced for the entire Thing.
[no] Text alternatives can be semantically "rich" e.g., with page structure, text style, hyperlinks, etc.
Unfortunately, HTML markup is forbidden in embedded text to avoid an XSS security risk. Titles and descriptions, for example, might be used to generate an HTML dashboard but embedding text from a Thing Description into the HTML for such a dashboard would allow an attacker to also embed undesirable scripts and other malicious content. If rich formatting is desired it can, however, be included in linked documentation.
[no] Authors can explicitly mark content as not needing alternative content because it does not perform an important role.
[no] Content can explicitly indicate that authoring tool is unable to generate or obtain alternative content.
[yes] Authors can associate multiple types and instances of alternative content with primary content.
All titles and descriptions can be given in multiple languages.
No alternative content, per se.
This is a developing area, being explored by the SVG Accessibility Task Force.
There are, however, no features exclusively targetting accessiblity.
No special features exclusively targetting accessiblity are provided.
Content is generally either text or JSON. Text can be rendered into speech if necessary, and JSON provides structured data that can be transformed into an accessible output.
The WoT Scripting API is defined in an associated informative document but its use is not mandatory. In general, the WoT Scripting API is defined to read and produce declarative content: the WoT Thing Description (TD), and to allow programmatic interaction with the network affordances described by these TDs. TDs, in turn, are actually describing network APIs.
The WoT Discovery mechanism also provides a network API which, however, does not modify TDs except for adding a new annotations (timestamps, etc).
[yes] If the API can be used for structured content, it provides features to represent all aspects of the content including hidden accessibility features.
The WoT Scripting API provides access to all aspects of a WoT TD relevant for accessibility. Exceptions are security metadata, which is provided out-of-band, but is functional.
[n/a] If the API relies on user agents to generate a user interface, the specification provides guidance about accessibility requirements needed to enable full interaction with the API.
Not applicable.
The
WoT Discovery
specification defines a network API for a directory and guidance on how to
use existing
discovery mechanisms such as DNS-SD.
WoT Protocol Bindings describe how to use WoT with existing protocols such
as MTTP or MQTT to define Things which use these protocols.
[yes] Use of the protocol does not cause any aspect of the content, including metadata which could contain important accessibility information, to be removed.
In general WoT does not remove information from existing protocols.
There are cases, however, where
information might be removed from a TD after negotiation
if it is not required by the Consumer.
For example, title and descriptions in languages not
requested by the Consumer or interactions that are not accessible with
the access rights of the Consumer might be removed from the TD to
save bandwidth.
[yes] It is possible to use third-party accessibility enhancement services while using the protocol.
The whole purpose of the WoT TD is to allow IoT devices to be more accessible to third-party applications by providing additional metadata in a standardized format.