Re: Templateid seems dangerous to innovation and competition

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.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Monday, 24 March 2008 20:24:23 UTC