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.
>

Received on Tuesday, 25 March 2008 14:04:40 UTC