furthermore, let's keep in mind that a table container as a UI structural element has many uses, not just as a spreadsheet view, so imposing the behavior of a particular use seems over-restrictive.
________________________________ From: Andres Gonzalez Sent: Monday, July 13, 2009 9:17 AM To: '[email protected]'; IA2 List Subject: RE: [Accessibility-ia2] What to do when GUI behavior is different than the IA2 spec for un/selectRow/Column? absolutely, the app should be ultimately responsible for deciding what to select and what not. it is not too difficult to imagine a situation where selecting a row or column does not make sense for the app, in which case returning S_FALSE, or even "not implemented" should be legal. Best regards, --Andres. ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Pete Brunet Sent: Monday, July 13, 2009 9:08 AM To: IA2 List Subject: [Accessibility-ia2] What to do when GUI behavior is different than the IA2 spec for un/selectRow/Column? Although we have decided to specify the behavior of un/selectRow/Column (4 methods) to be the same as that of Excel. In the cases where the GUI behavior is different, e.g. MS Word, OOo, and Symphony, should the behavior be allow to divert from the specification to match that of the GUI? We do need to specify behavior for those cases such as a browser where there is no GUI to select/unselect rows/columns. -- Pete Brunet a11ysoft - Accessibility Architecture and Development (512) 238-6967 pete @ a11ysoft.com http://www.a11ysoft.com/about/ http://www.linkedin.com/in/petebrunet Ionosphere: WS4G
_______________________________________________ Accessibility-ia2 mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
