Need to pick an accessible drop-down...

[Steve Lee]

Thanks Colin, thats does help and highlights yet another facet of the
accessibility problem.

I do think the point you raise about the problems of being able to
adapt Web UIs on the fly using Web tooling is going to be important.
Especially for cognitive accessibility (coga11y). Thanks for raising
the potential issue with web components encapsulation here. I'd be
interested in hearing more about other patterns such as facade that
you use that might help mitigate.

It's interesting to note that browsers effectively use web components
internally for standard HTML controls. I'm largely guessing but I
expect <input type="date"> renders the picker element behind shadow
DOM. You have to accept this and don't fret about having no deep
access as the control is defined in the standard and the accessibility
has been careful designed in. Except coga11y or adaptation have not
really been thought about that much yet. We may see new requirements
arising to get inside the boxes to allow changes - eg add symbols.

As things stand the standard HTML controls have fixed semantics that
act as contracts for external AT that use the a11y APIs and also
provide a black box in the DOM. Providing a11y semantic extension
mechanisms for web components could help make web components
accessible to AT, both external and HTML, but I agree won't help with
adaptation of internal details.

One idea might be to provide a standard mechanism to "open the box" in
order to make changes to the UX that do not effect the semantics seen
in the APIs or DOM. You'd then separate the using code (the html app)
from the adaptation code (preferences control) as we do already. That
is more restricted than having full access to the internals so might
not cover all adaptation use cases and might not even be realistic -
but sometime restrictions are good.

to be discussed.....  :)

Steve Lee
OpenDirective http://opendirective.com


On 14 August 2014 20:41, colinbdclark at gmail.com <colinbdclark at gmail.com> wrote:
> To put a bit more of a pragmatic spin on Antranig's rather abstract or
> ideological response, it might help to consider a concrete example:
>
> Imagine you're writing a browser-based assistive technology. Something that,
> for example, restructures a page to make it easier to read, or makes it
> simpler. Or perhaps even a screenreader, where it needs to see and
> understand all the widgets, sections, and controls on a page.
>
> With Web Components, as they exist today, the rich semantics of a component
> are hidden away--encapsulated as you say, Steve. The browser itself has
> access to the "shadow DOM" used by the component, but other components and
> scripts in the page don't. The shadow DOM is completely inaccessible to
> JavaScript code outside the component. So while a desktop AT is able to
> break through the encapsulation of a Web Component's markup using the
> "composed tree" that is exposed by the browser to the platform assistive
> technology API, web-based tools can't.
>
> I think there is a really strong future for assistive technology and user
> interface adaption implemented entirely using Web technologies--HTML, CSS,
> and JavaScript. But if all the components that a web-based AT needs to
> represent or adapt are invisible to it, this whole possibility is
> foreclosed.
>
> One of the primary advantages to HTML and the DOM is that it provides a
> clear, standard, and open way for scripts to be able to traverse and
> understand the semantics of a page. That's why, at least in Infusion, we
> really encourage the use open, transparent markup and JSON configuration for
> all the presentational, behavioural, and compositional aspects of a web
> application--so that an assistive technology, built using web technologies,
> can fully understand how the application works and can adapt it according to
> the user's needs and preferences.
>
> Unfortunately, at least as they're implemented today, Web Components seem to
> work against that vision.
>
> The good news is that I don't think transparency and lack of
> hiding/encapsulation has to involve "exposing all the guts" of a component.
> There are plenty of great ways to provide a user-friendly facade for a
> component without hiding and encapsulating everything in such a way that it
> can't later be adapted.
>
> Colin
>
>
>
>
>
> On Thu, Aug 14, 2014 at 3:26 PM, Steve Lee <steve at opendirective.com> wrote:
>>
>> Ah, a slightly different angle. One I heard about at ICCHP when you where
>> mentioned.
>>
>> Would be good to discuss when we next meet.
>>
>> My stance, for now, is encapsulation is useful if carefully applied. Grey
>> or white boxes rather than black. If I use a tool I'm happy to learn how to
>> use it without all its guts exposed to confuse me. Unless I want to adapt
>> it, then I dig in and learn the glorious details within.
>>
>> Steve
>>
>> Autocomplete may have messed with my text
>>
>> On 14 Aug 2014 20:11, "Antranig Basman" <antranig.basman at colorado.edu>
>> wrote:
>>>
>>> There's modularisation, and there's balkanisation. Web components fight
>>> against the spirit and also the practice of the free and open web, by making
>>> it impossible to influence or even access the markup and UI material
>>> operated by another component. "black boxes" are exactly what we don't want.
>>> The aim of Infusion, for example, is to make even more parts of an
>>> implementation open for inspection and modification than were previously
>>> available - by taking material that used to be locked up in JS
>>> implementation files and exposing it publically as JSON configuration. Web
>>> Components take us decisively in the wrong direction, by taking what used to
>>> be exposed in a public DOM with public behaviour and locking it away.
>>>
>>> These issues take a while to talk around and to establish - since this
>>> terrain isn't easy or obvious. A lot of what is "established wisdom" in
>>> Computer Science - re, for example, modularisation, insulation,
>>> encapsulation, and abstraction, has grown up over the years as a
>>> self-reinforcing network of ideas - and may not well-founded. Such
>>> "insulation-based thinking" is certainly inappropriate and unhelpful for a
>>> community whose aim is to promote the development and use of accessible
>>> interfaces. As well as working in the open (open source), we need to promote
>>> the creation of open artifacts. Open artifacts are ones where the intention
>>> of the user can reach down right to the ground level in every area of the
>>> implementation - with no "black boxes".
>>>
>>> Cheers,
>>> Antranig
>>>
>>> On 14/08/2014 19:53, Steve Lee wrote:
>>>>
>>>> Hmm, I disagree. Web components are simply an architectural
>>>> modularisation technique. At least with custom elements, and largely
>>>> shadow DOM etc.
>>>>
>>>> You get all the advantages of ease of use of your new tags as a black
>>>> box (just like standard elements) but all code is part of your project.
>>>> If you use existing web components you just pick open source ones with
>>>> healthy community. Same as any thing else you will depend on.
>>>>
>>>> Or am I missing your point?
>>>>
>>>> I used XBL, a precursor W3C standard, in Maavis and found the approach
>>>> added much to what is otherwise architecturally easy in JS.
>>>>
>>>> Steve
>>>>
>>> _______________________________________________________
>>> fluid-work mailing list - fluid-work at fluidproject.org
>>> To unsubscribe, change settings or access archives,
>>> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
>>
>>
>> _______________________________________________________
>> fluid-work mailing list - fluid-work at fluidproject.org
>> To unsubscribe, change settings or access archives,
>> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
>
>