[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [docbook-tc] Enhancements proposed for CALS / OASIS Exchange table model for accessibility
Hi Scott, I read through it all, and it seems the proposal is coming down to these changes:1. Add @rowheader to the colspec element, with possible values 'yes' or 'no'. There is no default value, but absence of the attribute implies 'no'.
2. Add @ headers to entry, with allowed content being id values from within the table.
Is that right? If these additions are sufficient to meet the accessibility requirements, then they seem fine to me.
We would need to clarify how certain cases are to be handled. I can think of two:a. If a table has rowheader="firstcol" and the colspec for column1 in that table has an explicit rowheader="no", I presume the colspec has precedence?
b. If an entry in a given row spans multiple columns, I presume the first column in the span determines whether the entry is a rowheader?
Bob Stayton Sagehill Enterprises bobs@sagehill.net----- Original Message ----- From: "Scott Hudson" <scott.hudson@schneider-electric.com>
To: "DocBook Committee" <docbook-tc@lists.oasis-open.org> Sent: Thursday, June 21, 2012 4:49 AMSubject: [docbook-tc] 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/rowPersonally, 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 --------------------------------------------------------------------- To unsubscribe, e-mail: docbook-tc-unsubscribe@lists.oasis-open.org For additional commands, e-mail: docbook-tc-help@lists.oasis-open.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]