Re: Feedback on Web of Things Specs

Hello Matthew,

First of all, thank you for the detailed answer and of course for creating the Github issues.

Regarding your questions:

1. In retrospect, the word "coding" was perhaps a bit confusing. We actually mean the existing "approved vocabulary" from https://schema.org/CreativeWork. So if you want to warn users about flickering content, you could add the key " accessibilityHazard https://www.w3.org/community/reports/a11y-discov-vocab/CG-FINAL-vocabulary-20230306/#accessibilityHazard " to the manifest and then add "flashingHazard" as a value, for example. And only the predefined words in the „approved Vocabulary“ can be set as values. The basic idea was that you don't always have to reinvent the wheel, but that was just a suggestion.

2. Gottfried and I also talked about this again. As far as we understand it, it is possible to link https://www.w3.org/TR/wot-thing-description11/#link a web app manifest within a Thing Description. Of course, this will not be the case for every WoT device, so it probably makes sense for these accessibility properties to be in both the manifest and the Thing Description. But we can talk about it again during the APA meeting.

Hopefully I could help you a little bit with these answers. If you have any further questions, please feel free to contact us.

Kind regards,
Niklas und Gottfried



>     Matthew Atkinson < matkinson@tpgi.com mailto:matkinson@tpgi.com > hat am 27. März 2023 um 21:48 geschrieben:
> 
> 
>     Hi Niklas, Gottfried, all,
> 
>     I'm cross-posting to RQTF, as I think you may be interested to be kept updated on these WoT developments.
> 
>     Thanks again for your detailed and constructive review. As Michael McCool mentioned, there is some ongoing work that I think we should contribute to and discuss, regarding "onboarding", as WoT terms it. You can find the relevant PR at https://github.com/w3c/wot-charter-drafts/pull/77
> 
>     In relation to your review comments, I have now—at last; sorry it's taken a while!—filed the majority of them as separate issues/comments on GitHub, for the WoT group. Here's a list:
> 
>     * WoT Architectures: Accessibility considerations: https://github.com/w3c/wot-architecture/issues/578#issuecomment-1485762269
>     * WoT Usecases: Application domain: Public devices in public spaces: https://github.com/w3c/wot-usecases/issues/221
>     * WoT Thing Description: Locator function: https://github.com/w3c/wot-thing-description/issues/1787
>     * WoT Thing Description: Information on timeout behavior of Actions: https://github.com/w3c/wot-thing-description/issues/1788
> 
>     I have _not_ yet filed the very important one about the web-app manifest, because I am not 100% clear as to where I should file it.
> 
>     1. For the first part of your feedback on the manifest — that the spec should say how it's to be coded — are you referring to encoding (like JSON)? That sounds like feedback for the web-apps WG.
> 
>     2. For the second part of your feedback - that the Thing Description could include accessibility properties, such as those from https://schema.org/CreativeWork — that sounds like feedback that should go into the WoT Thing Description repo, rather than the general web-app manifest repo.
> 
>     Niklas, Gottfried: if you could confirm/clarify the above two points, I'll file those issues too.
> 
>     Thanks again for all of your valuable feedback on this.
> 
>     best regards,
> 
> 
>     Matthew
>     --
>     Matthew Tylee Atkinson (he/him)
>     --
>     Principal Accessibility Engineer
>     TPG Interactive
>     https://www.tpgi.com
>     A Vispero Company
>     https://www.vispero.com
>     --
>     This message is intended to be confidential and may be legally privileged. It is intended solely for the addressee. If you are not the intended recipient, please delete this message from your system and notify us immediately.
>     Any disclosure, copying, distribution or action taken or omitted to be taken by an unintended recipient in reliance on this message is prohibited and may be unlawful.
> 
> 
> 
> 
>     On 02/01/2023, 07:22, "Niklas Egger" < egger@hdm-stuttgart.de mailto:egger@hdm-stuttgart.de <mailto: egger@hdm-stuttgart.de mailto:egger@hdm-stuttgart.de >> wrote:
> 
> 
>     CAUTION: This email originated outside Vispero. Do not click links, open attachments or forward unless you recognize the sender.
> 
> 
>     Hello everyone,
> 
> 
> 
> 
>     first of all we wish you a good start into the new year.
> 
> 
> 
> 
>     Gottfried and I took a look at Web of Things (WoT) Architecture 1.1 as well as other WoT specs and summarized our feedback and our additional ideas in the following sections. We are looking forward to your opinion and of course to your suggestions for improvement.
> 
> 
> 
> 
> 
> 
>     Feedback on Web of Things Specs W3C Web of Things (WoT) has the fundamental goal of extending the Internet of Things (IoT) to make it more open, flexible and scalable, while also enhancing the interoperability of different platforms and application domains.
> 
> 
> 
> 
>     For this, the W3C has defined a set of specifications, with WoT Architecture 1.1 < https://www.w3.org/TR/wot-architecture11/> < " rel="noopener" target="_blank" data-mce-href="https://www.w3.org/TR/wot-architecture11/>">https://www.w3.org/TR/wot-architecture11/> https://www.w3.org/TR/wot-architecture11/ > as the foundation. The other specifications represent the so-called Building Blocks:
> 
> 
> 
> 
> 
> 
>     * WoT Thing Description 1.1 < https://www.w3.org/TR/wot-thing-description11/> < " rel="noopener" target="_blank" data-mce-href="https://www.w3.org/TR/wot-thing-description11/>">https://www.w3.org/TR/wot-thing-description11/> https://www.w3.org/TR/wot-thing-description11/ >
>     * WoT Binding Templates < https://www.w3.org/TR/wot-binding-templates/> < " rel="noopener" target="_blank" data-mce-href="https://www.w3.org/TR/wot-binding-templates/>">https://www.w3.org/TR/wot-binding-templates/> https://www.w3.org/TR/wot-binding-templates/ >
>     * WoT Security and Privacy Guidelines < https://w3c.github.io/wot-security/> < " rel="noopener" target="_blank" data-mce-href="https://w3c.github.io/wot-security/>">https://w3c.github.io/wot-security/> https://w3c.github.io/wot-security/ >
>     * WoT Scripting API < https://www.w3.org/TR/wot-scripting-api/> < " rel="noopener" target="_blank" data-mce-href="https://www.w3.org/TR/wot-scripting-api/>">https://www.w3.org/TR/wot-scripting-api/> https://www.w3.org/TR/wot-scripting-api/ >
>     * WoT Use Cases and Requirements < https://w3c.github.io/wot-usecases/> < " rel="noopener" target="_blank" data-mce-href="https://w3c.github.io/wot-usecases/>">https://w3c.github.io/wot-usecases/> https://w3c.github.io/wot-usecases/ >
> 
> 
>     APA provides the following feedback on WoT, structured by specs.
> 
> 
> 
> 
>     WoT Architecture The initial question in the context of the APA work was posed by Michael Lagally and included whether WoT Architecture 1.1 should have an accessibility section.
> 
> 
> 
> 
>     The authors of WoT argue:
> 
> 
> 
> 
> 
> 
>     * The WoT Use Cases and Requirements < https://w3c.github.io/wot-usecases/> < " rel="noopener" target="_blank" data-mce-href="https://w3c.github.io/wot-usecases/>">https://w3c.github.io/wot-usecases/> https://w3c.github.io/wot-usecases/ > has an accessibility section < https://w3c.github.io/wot-usecases/#accessibility-0> < " rel="noopener" target="_blank" data-mce-href="https://w3c.github.io/wot-usecases/#accessibility-0>">https://w3c.github.io/wot-usecases/#accessibility-0> https://w3c.github.io/wot-usecases/#accessibility-0 > under “Technical Requirements”. In this section, it is stated that WoT is mainly about machine-to-machine interaction, and that software and hardware front-ends are out of scope for the WoT specs.
>     * Since accessibility is covered in the use case document, the WoT Architecture spec may not need an accessibility statement (See related Github entry by Michael Lagally < https://github.com/w3c/wot-architecture/issues/578> < >)" rel="noopener" target="_blank" data-mce-href="https://github.com/w3c/wot-architecture/issues/578>>)">https://github.com/w3c/wot-architecture/issues/578>>) https://github.com/w3c/wot-architecture/issues/578 .
>     APA would like to reconsider this, for the following reason: The Architecture spec is the central document and will be for many readers the entry point for Web of Things. It therefore also provides the opportunity to address the most important points, such as that middleware must support and any IoT user interface must comply with accessibility according to the current standards (WCAG, EN 301 549).
> 
> 
> 
> 
>     APA proposes to address the following issues in an accessibility section of the WoT architecture spec:
> 
> 
> 
> 
> 
> 
>     * Accessibility should be thought of from the beginning of the development of a component in any WoT environment. If the component has a user interface, this must be accessible. If it is for machine-to-machine interaction only, it must support user interfaces to be accessible.
>     * For user interfaces, relevant guidance on accessibility can be found in the following documents:
>     * W3C Web Content Accessibility Guidelines < https://www.w3.org/TR/WCAG/> < " rel="noopener" target="_blank" data-mce-href="https://www.w3.org/TR/WCAG/>">https://www.w3.org/TR/WCAG/> https://www.w3.org/TR/WCAG/ > (for web-based user interfaces)
>     * EN 301 549 < https://www.etsi.org/deliver/etsi_en/301500_301599/301549/03.02.01_60/en_301549v030201p.pdf> < " rel="noopener" target="_blank" data-mce-href="https://www.etsi.org/deliver/etsi_en/301500_301599/301549/03.02.01_60/en_301549v030201p.pdf>">https://www.etsi.org/deliver/etsi_en/301500_301599/301549/03.02.01_60/en_301549v030201p.pdf> https://www.etsi.org/deliver/etsi_en/301500_301599/301549/03.02.01_60/en_301549v030201p.pdf > (for hardware and any other user interfaces, especially for software/firmware running on “closed functionality” devices)
>     * In general, a Thing should always have at least one user interface that is fully accessible according to WCAG and EN 301 549.
>     * Accessibility must be applied to the interfaces for all types of users: manufacturers, installers, device owners, end users.
>     * The accessibility status of a user interface for a Thing should be declared in the Thing’s manifest, so that users can pick the user interface that is most appropriate for them (see section “Web Application Manifest” below).
>     * Components that do not offer a user interface, must still support accessible user interfaces by providing suitable data and functions that can be employed by accessible user interfaces. For example, developers of public Things (e.g. a ticket machine or an ATM) should consider a locator function by which a user can physically identify and locate the Thing by auditory, visual or other signaling.
>     WoT Use Cases and Requirements APA suggests adding an additional application domain that could have important accessibility benefits: “Public devices in public spaces”. These include, for example:
> 
> 
> 
> 
> 
> 
>     * ATMs
>     * Ticket machines at bus, metro and train stations
>     * Electronic directories and registration terminals at office buildings
>     * Food order terminals at fast food restaurants
>     Oftentimes, these public devices are not fully accessible to all users with disabilities. By providing a way to remotely control them, e.g., from a tablet mounted to a wheelchair, they may be usable by persons who would not otherwise be able to use them.
> 
> 
> 
> 
>     WoT Thing Description Regarding the TD, APA has two suggestions: Support for a locator function, and information on timeout behavior of Actions.
> 
> 
> 
> 
>     Locator function As part of the Thing Description, information about a Thing’s location in a room, and its ability to signal the user its location could be useful. For example, an ATM could send a beep on request, so that a blind user can locate it auditorily. Or/and it could have a visual locator, such as a blinking LED, to signal a seeing (but possibly hard-of-hearing user) where it is (if there are multiple ATMs in a room).
> 
> 
> 
> 
>     As for your consideration, here is the definition of the locator’s ‘type’ attribute from the (outdated) ISO/IEC 24752-4 standard on Target Description:
> 
> 
> 
> 
>     The meaning of the ‘type’ value shall be as follows:
> 
> 
> 
> 
> 
> 
>     * “audio”: Audible locator, i.e. the target emits an audible signal (such as a beep or bell) when invoked from the console;
>     * “visual”: Visual locator, i.e. the target emits a visual signal (such as a flash) when invoked from the console;
>     * “other”: Other means for localizing a target, e.g. IR pulse.
>     Information on timeout behavior of Actions For Actions, information about the timeout behavior would be valuable for the sake of accessibility (cf. WCAG 2.1 Success Criterion 2.2.1 Timing Adjustable < https://www.w3.org/TR/WCAG21/#timing-adjustable> < >)" rel="noopener" target="_blank" data-mce-href="https://www.w3.org/TR/WCAG21/#timing-adjustable>>)">https://www.w3.org/TR/WCAG21/#timing-adjustable>>) https://www.w3.org/TR/WCAG21/#timing-adjustable .
> 
> 
> 
> 
>     As for your consideration, here is the description of the ‘timeout’ attribute in the (outdated) ISO/IEC 24752-2 standard on Socket Description:
> 
> 
> 
> 
>     A <notify> element may have a ‘timeout’ attribute to indicate that the notification will deliberately time out when active. If present, the ‘timeout’ attribute shall have a value of type xsd:duration, specifying the default timeout for the notification.
> 
> 
> 
> 
>     EXAMPLE The following code represents a notification with a default timeout of 1 min and 15 s.
> 
> 
> 
> 
>     <notify id=”timeoutNotification” type=”yesNo” timeout=”PT1M15S” />
> 
> 
> 
> 
>     All <notify> elements that have a user response timeout shall represent the default timeout with such an attribute. This attribute indicates the time allowed for the user to respond to the notification before the target will dismiss it. The attribute value shall be at least 10 s, and should be significantly longer for complex notification dialogues.
> 
> 
> 
> 
>     NOTE 1 It is recommended that targets offer an option for the user to extend the timeout of a notification. This could be by notifying the user before a timeout occurs, and letting the user extend the timeout via a dialogue. Alternatively, the target could adjust its timeouts automatically based on user preferences (but this is out of scope for this standard).
> 
> 
> 
> 
>     NOTE 2 For notifications with a ‘timeout’ attribute, a target can continually send updated count-down values for the remaining time while it is active (“ttc” field). Also, the remaining time can be used as part of a dependency.
> 
> 
> 
> 
>     WoT Security and Privacy Guidelines While security and privacy is important for all users, persons with disabilities are generally more vulnerable to security and privacy threats. It is important to inform users of a Thing in an understandable language about such threats, how the system prepares for them, and what the user can do to avoid them.
> 
> 
> 
> 
>     Web Application Manifest The Web Application Manifest spec < https://www.w3.org/TR/appmanifest/> < " rel="noopener" target="_blank" data-mce-href="https://www.w3.org/TR/appmanifest/>">https://www.w3.org/TR/appmanifest/> https://www.w3.org/TR/appmanifest/ > is currently in working draft status. It should be revised in order to specify how such declaration is coded.
> 
> 
> 
> 
>     As a suggestion, schema.org could be employed, with its CreativeWork < https://schema.org/CreativeWork> < " rel="noopener" target="_blank" data-mce-href="https://schema.org/CreativeWork>">https://schema.org/CreativeWork> https://schema.org/CreativeWork > properties accessibility*. For example, the Thing Description could warn about hazardous flashing which would be a health risk for persons with photosensitive epilepsy.
> 
> 
> 
> 
>     Note: Such marking of user interfaces should not be restricted to Web Application Manifests, but should also be applied to other technologies (cf. Binding Templates).
> 
> 
> 
> 
>     Private Note (not part of the feedback to WoT) While researching, we also came across this article written by Graeme Coleman during his time on the Web of Things Interest and Working Group.
> 
> 
> 
> 
>     Accessibility and the Web of Things (WoT) – part 2 < https://www.tpgi.com/accessibility-and-the-web-of-things-wot-part-2/> < " rel="noopener" target="_blank" data-mce-href="https://www.tpgi.com/accessibility-and-the-web-of-things-wot-part-2/>">https://www.tpgi.com/accessibility-and-the-web-of-things-wot-part-2/> https://www.tpgi.com/accessibility-and-the-web-of-things-wot-part-2/ >
> 
> 
> 
> 
> 
> 
>     He also mentions several implications for accessibility. These are mostly abstract and not sufficient as feedback to the developers of the WoT specs. However, we drew from this content in devising this feedback document.
> 
> 
> 
> 
>     ... and that's it with our feedback. Thank you for taking the time to read through it.
> 
> 
> 
> 
> 
> 
>     Kind regards
>     Gottfried and Niklas
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>