Re: Templateid seems dangerous to innovation and competition

Another option is to provide domain-specific properties that can be used 
for customization.

We do this for aria-live and the other live properties, which are hints. 
If the user chooses to customize how "polite" or "assertive" interacts 
with their screen reader, they get the change of behavior in all apps that 
use that.

So I'd like to know what the major use cases of aria-templateid are that 
we can think of now. Maybe those are cases where hints like aria-live 
would be useful.

- Aaron






David Bolter <david.bolter@utoronto.ca> 
Sent by: wai-xtech-request@w3.org
03/25/2008 10:03 AM

To
Henri Sivonen <hsivonen@iki.fi>
cc
public-pfwg-comments@w3.org, Ian Hickson <ian@hixie.ch>, Maciej Stachowiak 
<mjs@apple.com>, david.bolter@gmail.com, wai-xtech@w3.org
Subject
Re: Templateid seems dangerous to innovation and competition







Hi Henri,

Thanks for expanding on your points. The "black box" argument is
worrisome and I understand your point much better now. My mind is stuck
in the open source world and I tend to think in that realm. The
incremental innovation argument also makes a lot of sense.

Given the potential import of keeping or removing this aria property I'm
cc'ing wai-xtech in case we are missing something.

cheers,
David

Henri Sivonen wrote:
> Hi,
>
> On Mar 24, 2008, at 21:35, David Bolter wrote:
>> Henri Sivonen wrote:
>>> According to 
>>> http://mindforks.blogspot.com/2008/03/aria-templateid-explained.html :
>>>> Whenever an assistive technology (AT) sees this template ID it can 
>>>> provide customization to improve the UX. For example, a screen 
>>>> reader like JAWS or Orca could load a script for adding keystrokes 
>>>> to open the Gmail inbox etc. If another web product embeds Gmail 
>>>> the AT can still pick up the the template id and apply some 
>>>> customization.
>>>
>>>
>>> I think this is a problem for innovation and for competition.
>>>
>>> It is a problem for competition, because if JAWS or Orca give magic 
>>> preferential treatment to Gmail, a competing Webmail service cannot 
>>> get the same accessibility advantage by writing to an open spec. The 
>>> playing field is not level in that case. The only way for the 
>>> competing service to gain the same advantage is to reverse engineer 
>>> what the template ID causes JAWS or Orca to do and then carefully 
>>> craft their own UI to match the structure that the magic behavior 
>>> expects. What's the point of an open spec like ARIA in that case? 
>>> Moreover, such crafting might be too impractical for entire UIs like 
>>> a Webmail UI. The reverse engineering scenario could be a realistic 
>>> recourse for an Ajax library when the template ID is associated with 
>>> a specific widget of a competing Ajax library as opposed to the 
>>> whole UI of an app. In either case, the anti-competitive effect is 
>>> not good.
>>>
>> I think you are suggesting that anti-competitive practice is a 
>> potential abuse of this ARIA property?
>
> I'm suggesting that aria-templateid inherently has anti-competitive 
> consequences.
>
> If site/library A gets preferential treatment triggered on its 
> template ID, site/library B cannot get the same treatment by writing 
> to any public spec/API. Worse, since the preferential treatment isn't 
> even a private API but arbitrarily complex behavior triggered 
> potentially inside a black box, it may not even be feasible for 
> site/library B to reverse engineer what is going on and copy the 
> template ID.
>
>> I think it is good to consider such things. I do think that the 
>> ability for someone to better customize his/her AT is empowering and 
>> perhaps worth the gamble? Consider if we already had the ability to 
>> do this in the web or desktop space, would you want to take it away? 
>> JAWS scripters have clearly felt the need to do this on a per URL or 
>> per desktop application basis.
>
> We do have Greasemonkey scripts already. They are different though. If 
> there's a Greasemonkey script in circulation for site A, site B can 
> see which APIs that script calls and even make site B use those APIs 
> by default. Also, I'm not really that worried about users circulating 
> AT scripts that others can read like they can read Greasemonkey 
> scripts. I'm concerned about special behavior inside the AT black box 
> triggered by a magic key.
>
> As for desktop apps, building app-specific knowledge/hacks into AT 
> would be anti-competitive there, too. Suppose popular AT has private 
> magic enhancements for office suite A. Office suite B cannot gain the 
> same functionality by writing to a pre-existing public API and may 
> have to work closely with AT providers to get their app supported.
>
>>> It is a problem for innovation, because Gmail is getting 
>>> preferential treatment for a particular version of its UI, updating 
>>> the UI in an innovative way would regress accessibility. With the 
>>> glacial update cycle of AT, it isn't reasonable to expect new AT 
>>> versions to be shipped instantaneously. Hence, aria-templateid would 
>>> cause a disincentive to change anything that has once gained 
>>> preferential treatment from AT.
>>>
>> I would hope that the UI is accessible/useable with or without the 
>> customization provided by the AT based on the templateid; that the 
>> templateid is the way to provide the "icing on the cake". In this 
>> scenario the UI authors should feel free to innovate and change the 
>> templateid (eg. "foo.com/gadget1.0" becomes "foo.com/gadget1.1"), 
>> effectively removing the icing until someone reapplies it.
>
> Having to remove the icing in order to innovate is a barrier to 
> innovation. You then can't innovate in small increments whose value 
> (per each increment) is smaller than the value of the magic icing.
>
> Consider the upgrade barrier caused by AT working with one version of 
> an office suite but not the next on desktop. The problem becomes worse 
> with the Web 2.0 release cycle.
>