Thank you for sharing this proposal. This proposal poses some interesting challenges for accessibility. The existing models for conveying information about tables to assistive technologies - retrieving the row & column header of a given cell - do not map well to these diagonal headers.
Excerpted image from proposal: sheet with a diagonal/kite cell in upper-left of a table
with multiple, tiered row & column headers
- Keyboard navigation - how does a keyboard user navigate to the portion of the cell containing a particular label?
- How does a screen reader retrieve the portion of the sell containing a specific label in order to speak / Braille it?
- What changes do we need to make in the accessibility API in order to accommodate this kind of labeling of row/column headers & subheaders?
Excerpted image from proposal: "Insert Diagonal Tableheader" dialog box
This is perhaps reasonable for insertion, since that operation is done rarely. But for viewing it, a user could easily get lost trying to remember that we are in "Style 5" which means the cell is divided into three ways and that "Label 1" is labeling the column headers, "Label 2" the content of the cells, and "Label 3" the row headers. As there are "14 diagonal header styles", this puts a very significant cognitive burden on the user.
The second challenge above could come out of the the third in some senses - tell the user what this is not because they have navigated to it, but because they are on a cell labeled in this fashion by simply reading them the associated label. But I'm concerned that this wouldn't be sufficient. Especially because today we don't have encoded information about the span to which a label applies, if I'm on cell G10 in the first image above - e.g. first row but beyond the end of the filled-in table - then how does my screen reader know the diagonal/kite header/label no longer applies?
I've cc-ed the rest of the ODF Accessibility TC, to get their thoughts/feedback as well.
Regards,
Peter Korn
Accessibility Architect & Principal Engineer,
Sun Microsystems, Inc.
Dear TC members, as announced earlier this week, Redflag 2000 would like to submit a proposal about Diagonal (or Kite or Asian) Table Headers. The proposal is quite substantial, as we have been trying to take a semantic approach to the feature. ISO29500 keeps very brief on it (Part I - 17.4.74 tl2br), while UOF adds some graphical lines with text to a table cell (range), which means IMHO emulating the feature with a 'borrowed' object type. RF2000 has been proposing this feature at OOo almost two years ago with a similar approach to UOF, see: http://wiki.services.openoffice.org/wiki/Image:Diagonal_Table_Header_Specification.odt Todays proposal is significantly different. The basic idea is to overcome the concept, that a table cell has to be rectangular. Hence, we copied most features of a 'cell as yet known', leaving away all the stuff, that is only reasonable to be used in a box concept. As a result, it is possible to calculate the content of diagonal table header cells in the same way, as used in rectangular cells. A feature we have been avoiding so far is to go the opposite way. Contents of diagonal table header cells cannot be used for calculations etc. in rectangular cells. We have been starting to think about this feature, but this would have blown up the proposal by multiple times. We think this extension can be added in a later step. To draft our proposal, we have been basing our work on ODF 1.2 CD01rev5. You will also find a modified schema attached, that has about 200 lines added. One concern I'd like to raise here. To illustrate the use cases, we have been scanning samples from a reference book about corporate forms and tables. Our draft is citing the source in a way, that would be legal to use in Germany, but I do not know, how this kind of use of copyrighted work is handled in the US. Hence, I would like to clarify this, before I copy the proposal to the wiki. Can anyone give me a hint? As mentioned in an earlier posting this week, Redflag 2000 would really appreciate feedback about this proposal, although review of new features should be intermitted during the current state of ODF 1.2. We want to design several more features during the next couple of months and need some feedback to learn, as we are an unexperienced team. Best regards, Peter
--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php