Accessibility considerations of WoT architecture

[mlagally]

The current WoT Architecture draft does not contain an explicit section on accessibility,
since accessibility aspects were considered use case specific and are documented in the "Use Cases and Requirements" document.

See https://github.com/w3c/wot-usecases and specifically https://github.com/w3c/wot-usecases/labels/Accessibility

The APA group should provide feedback if they suggest to also add accessibility considerations also to the architecture document.

[mlagally]

APA minutes:

https://www.w3.org/2021/01/27-rqtf-minutes.html

[mlagally]

Arch call on Nov 2nd.: Agree to close

[matatk]

Some of APA's members (@niklasegger and @gozimmermann) conducted a review of various WoT specs. This is one of several issues I'm filing based on those reviews. If you'd rather I open a new issue for this one (rather than continuing on this thread), I'd be happy to.

We would like to see an Accessibility Considerations section in the WoT Architecture spec; here are the reaasons, and a suggested outline (we'd be happy to work with you on the contnet)...

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 (for web-based user interfaces)
  • EN 301 549 (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 (we'll file a separate issue on this).
• 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.

We used the term "middleware" to refer to any apps, web sites, or other services that must be used in order to set up, or maintain, the WoT device; we gather from our TPAC 2022 discussion that that term fits with you, but if you think we should use a different one, please let us know. Onboarding is definitely a part of this.

Our members' original review was in email; all the info from that email that's relevant to this issue is posted here; the link is just for completeness.

[mmccool]

@matatk We are very close to going to PR but have a short window to add an informative section on Accessibility Considerations. I have created a PR based on the above outline but it needs some work as noted in the PR. Can we please schedule a short meeting in the next week to discuss and edit the PR? I will reach out by email...