Re: Web Of Things Technical Accessibility Issues.

Interesting discussion. If I may add one additional thought, is that
"architecture" will play a critical role going forward.

As an example: yesterday I joined a W3C Community Group call
around Conversational Interfaces, where they are working on something
called Dialogue Manager Programming Language. (It was kinda cool).

As part of the call, they demo'ed a "chat bot", and in conversation with
the developer, he confirmed that the bot could also be involved in
programmed animations (as one form of a 'reply utterance'). I had the
opportunity to chat with him regarding the highest level of needs (input
and output) and the impact it has when one or more perception senses is
disabled. We talked about that animation, and I pointed out that for
non-sighed users, they would need a text (or more likely auditory)
alternative (aka audio descriptions), and so at a minimum, his architecture
and data-store would need to have those descriptions available, or at least
the architecture would need to support those additional "bits". He'd never
even considered it...

And so while the connection between a chat-bot that can direct animations
and the Web of Things may be tenuous, my experience in that interaction
suggests to me maybe not so much: that as the WoT infrastructure continues
to grow (and putting aside less reliance on AT) we need to ensure that the
architecture is such that it can support alternative inputs and support
alternative outputs.

(As a broad and un-researched question: can I connect a Bluetooth keyboard
directly to any of the home automation systems out there? Alexa, or Google
Home or... For users who are functionally non-verbal, how can they interact
with those systems today?)

JF

On Tue, Jun 18, 2019 at 10:48 AM Joshue O Connor <joconnor@w3.org> wrote:

> On 18/06/2019 15:24, Michael Cooper wrote:
>
> On 18/06/2019 5:31 a.m., Joshue O Connor wrote:
>
> One of the questions I've got is how can we insure that thing meta data -
> when needed, translates in a way that accessibility APIs can consume?  Do
> we need abstractions between RDF/JSON-LD and an accessibility API? Will it
> all be just parsed as text? Does this data need a semantics to present to a
> user (which I think will be the case)?
>
> [...] Rich enough "thing descriptions" so a user agent can construct an
> accessible experience without a priori knowledge, self-describing metadata
> ontologies that allow automated processing without reference to restricted
> vocabularies...
>
> Right, you've articulated a hunch I had there nicely. It seems that if we
> try not to fit the new into the old, in terms of rich thing descriptions
> and support for legacy networks - then I agree that we should face that
> brave new world and see if it can lift all boats. If AT disappears, and we
> just have UIs that support modality x, then that would be wonderful.
>
> One thing about restricted vocabularies, is that it can focus attention on
> what is semantically important. Knowledge (or lack of) has been the bread
> and butter of most accessibility peoples careers! So if we feel the ground
> is laid for really building on semantically aware communities in either
> WoT, or XR or whatever, then we do have so exciting opportunities.
>
> I am by nature a tech sceptic, as well as inherently cautious when it
> comes to potentially leaky abstractions. So for that kind of paradigm to
> work, there needs to be people on the ground who can support and guide the
> new infrastructure so it really will be fit for purpose.
>
> Some of those things have been dreams of the metadata community for a long
> time, but the present state of technology and the novel use cases of web of
> things might mean those things are realistic now, and a potentially
> important part of the accessibility puzzle.
>
> +1. Sounds good - but before we leave the world of accessibility APIs ;-)
> Seriously, I don't think we would move away from that model overnight, and
> there is need for AT vendor engagement  when it comes to support for any
> new metadata schema etc. For the short term, if its going on the web, there
> will be a DOM and an Accessibility API.
>
> As an aside, I'm seeing that there are also interesting suggestions in the
> accessibility API space, and new thinking such as in the Accessibility
> Object Model, for example using non-reflective (or getters and setters)
> accessibility properties and updating Web Components like that, along with
> doing this dynamically as needed for state changes etc via callbacks. Yes,
> this kind of thing can be done by an accessibility aware React developer
> but they are few and far between.
>
> So AOM is also talking about interesting things like setting default
> accessibility properties for components, and being able to support custom
> based semantics, and use of scripting to update elements and their various
> properties without globally assigning IDs. (if I am reading the spec
> correctly?) [1]
>
> This kind of thinking is very interesting to me and I see wide ranging
> applications in different domains. But finally, I have to leave the last
> word to Michael, as his point about novel use cases, and the potential for
> just 'rich' thing descriptions and their potential beyond accessibility
> APIs, is excellent.
>
> Josh
>
> [1]
>
> https://wicg.github.io/aom/explainer.html#introduction
>
> [2]
> <https://html.spec.whatwg.org/multipage/common-dom-interfaces.html#reflect>
>
> https://html.spec.whatwg.org/multipage/common-dom-interfaces.html#reflect
>
>
>
>
>
>
> Michael
>
>
> --
> Emerging Web Technology Specialist/A11y (WAI/W3C)
>
>

-- 
*​John Foliot* | Principal Accessibility Strategist | W3C AC Representative
Deque Systems - Accessibility for Good
deque.com