Re: Comparison of Smart Headers and HTML5 (ACTION-85)

Joshue O Connor wrote:
> Ben Millard wrote:
>> 1. The current algorithm runs through the <table> once to find all the
>> associations.
>> 2. The UA stores them in the relevant accessibility API properties.
>> 3. A user interacts with a cell via an AT.
>> 4. The AT uses what has been stored in the API for that cell.
>> 5. The AT may apply verbosity control, announcements, re-ordering and
>> other adaptations to improve the user experience.
>>
>> In this way, the relationships are stored rather than queried on-demand.
>> Do you think that's a good thing? Avoiding repetitive queries between AT
>> and UA seems like a good thing to me, since a user can move between
>> table cells rapidly.
> 
> I am not sure I understand this part.

This is the revised and simplified process that Ben was trying to explain:

1. The UA runs through the <table> using the algorithm to find and store
    all of the associations between cells.
    - The way it stores the associations in memory is implementation
      specific and doesn't really matter that much.
2. The AT queries the UA for the information about each cell, as
    required, via the accessibility APIs.
3. The UA responds with the requested associations.

In this model, the AT doesn't need to have direct access to the DOM.  It 
should be able to obtain all the information it needs via the 
accessibility APIs.  Although if it did get access to the DOM, then it 
would be possible for the AT to implement the algorithm for itself.

But the benefit of having the browser implement the algorithm and report 
the associations via the APIs is that given the low cost and relatively 
fast pace of the browser upgrade cycle compared with that of assistive 
technology, browsers can adapt more quickly to changes and improvements 
can be deployed faster.

-- 
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

Received on Sunday, 7 December 2008 10:37:36 UTC