So, anything else we need to discuss before we sanction new interface? Concerning my previous notes I think most important one might be #3 because it can affect on table usage by AT. #1 and #2 is kind of syntax sugar and they can be missed actually if their consideration requires lot of time.
It would be nice to get new interface sooner. Thank you. Alex. On Thu, Jul 16, 2009 at 1:30 PM, Alexander Surkov<[email protected]> wrote: > Hi, James. > >>> 2. It's might be worth to keep cellIndex. >>> Cell index is unique numeric identifier of cell accessible.If AT >>> wants to navigate through all cells then it's easier to have one loop >>> to run through all cells, otherwise AT is forced to have nested loops >>> which can be not optimal if table has spanned cells or cell holes. >> I'm not sure I follow this. Do you mean you'd iterate starting at 0 and >> call a method on the table to retrieve each cell until it failed? Why >> not just iterate through the children of the table? In Gecko's case, >> you'd have to descend into text frames and rows, but that's what we have >> to do now anyway. > > Yes you can use accessible tree to iterate through all cells or > You can get rows/columns count and iterate through all cells by > accessibleAt(row, column) or > You can use indexes to iterate through cells. > > If 3d option looks useful then it's worth to save cell indexes but as > you noted we should add method nCells or something to get cells > number. > >>> 5. rowHeaders/columnHeader shouldn't be inherited from >>> IAccessibleTable interface. >> Sorry to bring this up again, but did we ever actually abandon the idea >> of using relations? If we use relations, we certainly need specific >> relations instead of using description for/described by. However, with a >> specific relation, it does seem that this might be a nicer fit. It'd >> also be nice to have a relation from a cell to its table so we don't >> have to crawl up the parent hierarchy in cases like Mozilla. We'd >> definitely need a better relation interface to do this, however, as the >> current interface is highly inefficient (fetch all relation names and >> then index, rather than direct relation fetch). > > I think yes, we didn't decide to use relations between header cells > and data cells. Instead we decided to introduce > getHeaderCells(cellAcc) if I get right. > > Alex. > > On Thu, Jul 16, 2009 at 12:58 PM, James Teh<[email protected]> wrote: >> On 16/07/2009 1:03 AM, Alexander Surkov wrote: >>> 2. It's might be worth to keep cellIndex. >>> Cell index is unique numeric identifier of cell accessible.If AT >>> wants to navigate through all cells then it's easier to have one loop >>> to run through all cells, otherwise AT is forced to have nested loops >>> which can be not optimal if table has spanned cells or cell holes. >> I'm not sure I follow this. Do you mean you'd iterate starting at 0 and >> call a method on the table to retrieve each cell until it failed? Why >> not just iterate through the children of the table? In Gecko's case, >> you'd have to descend into text frames and rows, but that's what we have >> to do now anyway. >> >>> 3. Consider to have reverse methods for row/columnHeaderCells. >>> Possibly AT may want to get data cells by header cell. >> ... >>> 5. rowHeaders/columnHeader shouldn't be inherited from >>> IAccessibleTable interface. >> Sorry to bring this up again, but did we ever actually abandon the idea >> of using relations? If we use relations, we certainly need specific >> relations instead of using description for/described by. However, with a >> specific relation, it does seem that this might be a nicer fit. It'd >> also be nice to have a relation from a cell to its table so we don't >> have to crawl up the parent hierarchy in cases like Mozilla. We'd >> definitely need a better relation interface to do this, however, as the >> current interface is highly inefficient (fetch all relation names and >> then index, rather than direct relation fetch). >> >> -- >> James Teh >> Email/MSN Messenger/Jabber: [email protected] >> Web site: http://www.jantrid.net/ >> _______________________________________________ >> Accessibility-ia2 mailing list >> [email protected] >> https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2 >> > _______________________________________________ Accessibility-ia2 mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
