Need to pick an accessible drop-down...

Thu Aug 14 19:41:29 UTC 2014

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20140814/9dc30d5f/attachment.htm>