[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Enhancements proposed for CALS / OASIS Exchange table model for accessibility
Folks, please see the thread below regarding the discussions I've been having with Nathalie on CALS/Exchange table enhancements. I'd appreciate your opinions on the matter. Thanks and best regards, --Scott Scott Hudson | Pelco by Schneider Electric | United States | Standards Lead Site: pdn.pelco.com | scott.hudson@schneider-electric.com ------ Forwarded Message From: Nathalie Sequeira <n@n-faktor.net> Reply-To: <n@n-faktor.net> Date: Thu, 21 Jun 2012 11:13:17 +0200 To: Scott Hudson <scott.hudson@schneider-electric.com> Subject: Re: [docbook-publishers] Schema, and version? Hello Scott, thanks for the quick update regarding the TC's support of these changes, which is quite excellent! As to sharing my thoughts on the docbook-tc list, please do not hesitate to use my contributions in any way you may find useful for advancing the matter. ------------ @rowheader Following your thoughts regarding this, my interpretation of this attribute as it stands now in docBook is that it fulfills the purpose of marking a (i.e., the first) column's entrys to have the functionality of row headers, kind of like <thead> does that for col headers in rows. I think this functionality per se is important to maintain separately, given that any element can sport a xml:id for the diversest of reasons - and therefore cannot be used to unmistakably mark an entry as a header cell. Thus, we will always need two things: 1. a mechanism to identify which entrys have the *function of headers* (thead for column headers and -- something similarly flexible for the row headers) 2. a mechanism to *express the semantic relationships *between headers and data (= xml:id + headers) HOW row headers are to be marked effectively IMO is definitely open to discussion, given its shortcomings (or even non-existence in the CALS specs!) as-is. I VERY much like your idea of having an attribute in the colspec that marks each col in lieu of the table@rowheader, since colspec@rowheader would give us a yesorno attribute that can be applied to whatever amount of cols is necessary on a case by case basis, making it much more flexible than at present. Also, it is a much more adequate place to define this, given the column-specific descriptive nature of <colspec>. So the only caveat about changing how header-function identification occurs could be backward compatibility? ------------ @headers thinking it over, I am becoming increasingly certain that ONLY the xml:id's should be able to be referenced here, leaving colspec@colname quite out of the equation. This because a column can have multiple headers (e.g. a 2-tiered column header structure) and just referring to the @colname could cause ambiguity. That also means that colspec@colname would continue to have the exclusive function of defining spans via @namest and @nameend (and assigning entrys to columns where necessary via entry@colname). ------- I will keep you updated on what I hear about the @scope question! Best regards, Nathalie Scott Hudson schrieb: > Nathalie, > > thanks again for the thorough response. > > I would agree with the usefulness of @scope. I'm not convinced it is useful > either. > > I'm also a bit concerned with the rowheader proposal, as it appears to be > hard-coded and thus not scalable. I thought the idea was to actually provide > the id of the col that was a header? Otherwise, there is the @cols in tgroup > that provides the number of columns? Perhaps it would be better to have some > attribute in the <colspec> that identifies it as a header? > > As you state, we do not want a semantic conflict. I would rather err on the > side of explicit references to IDs. > > If you don't mind, I'd like to forward this discussion to the docbook-tc > list? Please let me know if this is OK. > > Thanks and best regards, > > --Scott > > Scott Hudson | Pelco by Schneider Electric | United States | Standards Lead > Ph: +1-970-282-1952 | M: +1-720-663-7268 | Site: pdn.pelco.com | > scott.hudson@schneider-electric.com > > > > > On 6/20/12 9:08 AM, "Nathalie Sequeira" <n@n-faktor.net> wrote: > > >> Hello Scott, >> though it does take me to the outer edge of my knowledgeability, here is >> my take on your proposal (hoping none of it is foolishly ignorant): >> >> ------------ >> First off and on a more general note, I was a bit confused concerning >> the Exchange model : >> I have been using the docBook 5.0 reference for structural information >> on CALS, and it seems to base itself upon the 1995 CALS model >> (http://docbook.org/tdg5/en/html/cals.table.html) - given the Exchange >> model is the "newest" regarding CALS (but seems to exclude elements >> included in docBook such as tfoot), there may be some harmonizing to be >> done here...? >> >> Either way, what I found irritating is that rowheader does not seem to >> be included in either model - where, then, does docBook take its >> inclusion from? >> >> ------------ >> @ scope >> >> As I am personally not convinced of its real usefulness (and thus >> whether it should even be included into the CALS model), I have now >> posted a question regarding this to the Web2.0 accessibility forum on >> linkedIn, in which quite some top notch accessibility experts >> participate. I hope to get some feedback regarding this in the next few >> days. >> >> ----------- >> @rowheader >> >> As described in the docBook 5.0 documentation, rowheader has the >> shortcoming of only being able to mark the first column as containing >> headers. To make this truly useful, rowheader would need to be able to >> also name a second column as such (three-tiered row headers IMHO seem to >> be overkill, but I HAVE seen such in the wild.. not sure whether one >> should cater to these too). >> Since in cases of row headers in the second column there will most >> certainly also be row headers in the first (analogously this also hold >> true for the 3rd), I would thus suggest an expansion of the >> possibilities along the lines of >> >> rowheader (norowheader|firstcol|twocols|?threecols?) #IMPLIED >> >> whereby as mentioned above I'm not sure where the docBook values >> originate from in the first place. >> >> While this would establish a header infrastructure similar to that of >> <thead>, I am not 100% sure that this mechanism would satisfy real world >> requirements in terms of specificity since it marks the whole column >> (including rows that are in themselves also column headers) as header >> information. >> >> ----------- >> @ headers >> I think this is excellent and, together with xml:id, will provide a >> flexible infrastructure for all kinds of semantic relationships in >> complex tables. >> Unconditional YES here! >> >> -------------------------- >> @ "Perfect world" example >> >> well, maybe not perfect yet, but on its way, I've marked up the >> "complex" example how it could look with the revisions: >> >> <table frame='all' rowheader='twocols'> >> <title>'Shelly's Daughters' in CALS Markup</title> >> <tgroup cols='4'> >> <colspec colname='provenience'/> >> <colspec colname='name'/> >> <colspec colname='age'/> >> <colspec colname='birthday'/> >> <thead> >> <row> >> <entry> </entry> >> <entry xml:id="name">Name</entry> >> <entry xml:id="age">Age</entry> >> <entry xml:id="birthday">Birthday</entry> >> </row> >> </thead> >> <tbody> >> <row> >> <entry morerows="1" >> xml:id="natural">Daughters by birth</entry> >> <entry xml:id="Jackie" headers="natural >> name">Jackie</entry> >> <entry headers="natural Jackie age">5</entry> >> <entry headers="natural Jackie >> birthday">April 5</entry> >> </row> >> <row> >> <entry xml:id="Beth" headers="natural >> name">Beth</entry> >> <entry headers="natural Beth age">8</entry> >> <entry headers="natural Beth >> birthday">January 14</entry> >> </row> >> <row> >> <entry xml:id="step">Daughters by >> marriage</entry> >> <entry xml:id="Jenny" headers="step >> name">Jenny</entry> >> <entry headers="step Jenny name">12</entry> >> <entry headers="step Jenny birthday">Feb >> 12</entry> >> </row> >> </tbody> >> </tgroup> >> </table> >> >> What I'm not sure about here: >> - should @headers ALWAYS refer to xml:id? I tend towards yes, however, >> the existence of colspec@colname does open the door to thoughts of >> making use of that in simpler cases... >> As far as I understood, referencing the @colname from within an entry >> currently positions the entry in that column (IMO enabling the creation >> of malformed table structures? This makes the use of colname at all a >> bit iffy to my mind... so it may be preferable not to name the columns >> via colspec at all, only giving them colnums, and instead only use the >> xml:id for header attribution) >> >> - if we mark the second column as headers with a hypothetical "twocols" >> value, will that not also include the header "Name", making "Name" a row >> header for "Age" and "Birthday"... >> That would be nonsense...but kind of already holds true for firstcol >> cases. So I may be overthinking here --- if the potential semantic >> conflict is no problem in the first col, it won't be one in the second >> either? :) >> >> ------------ >> >> I hope this helps and wish you a very productive meeting today! >> Nathalie >> >> >> >> Scott Hudson schrieb: >> >>> Nathalie, >>> >>> thank you for your quick and thorough response! Based on your feedback, here >>> is what I'm planning to recommend, based on the model as listed here: >>> https://www.oasis-open.org/specs/tr9503.html >>> >>> <! ENTITY % tbl.entry.scope "scope (row|col) #IMPLIED"> >>> <! ENTITY % tbl.entry.headers "headers (#PCDATA) #IMPLIED"> >>> <! ENTITY % tbl.entry.att "(%tbl.entry.scope; %tbl.entry.headers;)"> >>> <!ENTITY % tbl.table.att " >>> pgwide %yesorno; #IMPLIED " >>> rowheader NMTOKEN #IMPLIED "> >>> >>> I think xml:id is allowed on every element, so not sure anything needs to be >>> changed to allow it explicitly? >>> >>> Any other additions/changes you would recommend? >>> >>> Can you provide a "perfect world" markup example using CALS/OASIS Exchange >>> (showing what the table would look like with the desired attributes added to >>> OASIS Exchange)? >>> >>> Thanks and best regards, >>> >>> --Scott >>> >>> Scott Hudson | Pelco by Schneider Electric | United States | Standards Lead >>> Ph: +1-970-282-1952 | M: +1-720-663-7268 | Site: pdn.pelco.com | >>> scott.hudson@schneider-electric.com >>> >>> >>> >>> >>> On 6/19/12 1:16 AM, "Nathalie Sequeira" <n@n-faktor.net> wrote: >>> >>> >>> >>>> Hello Scott, >>>> >>>> thank you for your continued pursual of this issue! >>>> >>>> >>>>> What about namest and nameend? Please see >>>>> http://www.docbook.org/tdg5/en/html/entry.html >>>>> >>>>> Do those provide enough of the semantics? >>>>> >>>>> >>>>> >>>> While I do see that namest and nameend could be used as attributive >>>> markers on col-spanned entries, they can ONLY be used for those and >>>> would reference columns only (possible row headers cannot be tied in via >>>> these). >>>> So I would say that no, these unfortunately do not fulfill the purpose >>>> of enabling the expression of multidimensional relationships of headers >>>> to the content of entry's. >>>> >>>> >>>> >>>>> Also, I'm wondering if we even >>>>> need to have scope, since the column headers should be in thead/row/entry >>>>> and the rows can be determined in tbody/row >>>>> >>>>> >>>>> >>>> Personally, I feel that "scope" (in HTML) has a certain redundancy, >>>> given that screen readers seem to understand simple table relationships >>>> by means of appropriate header markup, and the id+headers method is far >>>> more efficient when it comes to complex data. >>>> So IMHO this is not something that needs revision in the CALS model, >>>> given the existence of colspec/thead for column headers and the >>>> rowheader-attribute for first-tier row headers. These set up a sort of >>>> implicit relationship to the data cells and thus allow a corresponding >>>> transformation that is sufficient for guaranteeing the accessibility of >>>> simple, linear tabular data. (as always, I speak for HTML, not knowing >>>> enough of PDF or other formats to presume anything there). >>>> >>>> However, it does get tricky as soon as we have anything more complex. Of >>>> course, it is always recommended that table structures be simplified to >>>> increase accessibility, but when can we really do that in the real >>>> world, given that would mean editing the original text? And sometimes >>>> even if we could, data remains complex and its tables will unavoidably >>>> be so too. >>>> So: >>>> - yes, namest and nameend could - possibly & with a bit of XSL effort - >>>> cater to colspanned entry's >>>> - but what about row-spanned ones? (I just can't imagine how morerows >>>> could be used effectively... but then again, I'm no XSL guru and there >>>> just may be some erudite way of achieving this?) >>>> - and what about those seemingly "innocent" entry's that make up a >>>> simple table cell, which however may be semantically related to multiple >>>> headers? >>>> - not lastly, what about second-tier row headers, which seem to not be >>>> possible at all in CALS? >>>> >>>> I have gone ahead and marked up the more complex HTML example in CALS >>>> and have added it to my explanation: >>>> http://n-faktor.net/featured/docBook_tables.html#cals >>>> Perhaps my walk-through of the direct code comparison makes it more >>>> clear what CALS simply cannot achieve. >>>> >>>> As said, I think the crux of the issue is that CALS really seems not to >>>> have been designed to express semantic relationships, but rather is >>>> focussed on providing mechanisms to define visual presentation. Because >>>> of this, (mis-)using any existing options will always be prone to >>>> failure regarding semantics, not because they are badly designed but >>>> simply because they were conceived with something else in mind. >>>> >>>> Therefore, I would intuit that CALS needs a new mechanism to be able to >>>> effectively express the semantics of tabular data. >>>> Of course, it would be ideal to be able to melt BOTH functions - >>>> semantic and visual - into single bits of code capable of achieving >>>> both, instead of just sticking something new onto the CALS model as is. >>>> I'm guessing however that semantics would be the wiser place to start to >>>> achieve this. >>>> >>>> I hope this helps, otherwise please do ask back and I will do my humble >>>> best to answer. >>>> Best regards, >>>> Nathalie >>>> >>>> >>> >>> > > > -- Nathalie Sequeira ************************ webseiten mit *n-faktor robust*benutzbar*barrierefrei www.n-faktor.net Türingstr. 6 6020 Innsbruck Mobil: 0650 224 3336 n@n-faktor.net ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. ______________________________________________________________________ ------ End of Forwarded Message
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]