| Hi Robert, et al,
I've embedded my comments below [SH].
Thanks and best regards,
--Scott
Scott Hudson | PELCO by Schneider Electric | United States | Standards Lead
Phone: +1 970 282 1952 | Mobile: +1 720 369 2433 | Email: scott.hudson@schneider-electric.com
Hi Scott,
When reading the proposal it seems hard to distinguish between what is
possible today and what is new. Can you fill out the "Proposed changes"
section of the template with an overview of the actual changes to DITA?
[SH] I'll update the Proposed Changes section.
More generally, I think people unfamiliar with DITA tables would read this
proposal and get the impression that tables cannot be made accessible
today. I'd like to note that using the DITA-OT today, almost all of the
tables in your examples would generate HTML with all required headers/id
associations. The only exception is table 3, which uses multiple header
rows, because DITA doesn't yet provide a way to identify that. I think it
would be good if the "use case" section was updated to provide samples of
what cannot be done today.
[SH] I can update the examples as well, but wanted to provide examples of how to use the proposed markup changes?
Apart from those issues, I have several more specific comments / questions:
1. Minor item - though I like to focus on the DITA-OT myself, the
processing impacts should really be more general, as the toolkit is just
one of many DITA tools out there
[SH] agree. It was in the template, so thought it was required to be specific. I recommend updating the template. I will generalize the sections in the proposal.
2. I'm not sure I understand why we would create "summary" as an attribute
- in DITA 1.1, we deprecated all attributes with translatable text and
created elements instead. So, I would expect that the table summary should
follow that pattern. This shouldn't be an issue for HTML, as any DITA
content rendered as HTML already has to undergo some sort of
transformation.
[SH] I thought about this as well, but was wary of adding a new element. I agree with the move to use elements for translation purposes, so will update the proposal to use a new element. Question: should we follow the HTML5 approach and put it in caption/detail/summary?
3. Are you suggesting that we add the @xml:id attribute in addition to the
existing @id attribute? If so, is there a reason that @id does not work?
[SH] xml:id would be more appropriate IMO, but I don't see that using id would be a problem.
4. It looks like the code samples use DocBook rather than DITA
[SH] apologies. Copy/paste error since I'm asking for this in both standards... will update.
5. In the "processing impact" section, I think it would be good to point
out that tools which already automate the id/headers association will need
to be updated to change that automation - presumably respecting the
author's manual selection instead of the automated one.
[SH] Good point. I'll add this clarification.
Thanks,
Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit (http://dita-ot.sourceforge.net/)
From: Scott Hudson <scott.hudson@schneider-electric.com>
To: dita@lists.oasis-open.org,
Date: 06/24/2013 13:53
Subject: [dita] Groups - Proposal 62, Table Accessibility (DITA Source)
modified
Sent by: <dita@lists.oasis-open.org>
Submitter's message
fixed typo
-- Mr. Scott Hudson
|------------------------------------------------|
|Document Name: Proposal 62, Table Accessibility |
|(DITA Source) |
|Description |
|Add attributes and elements to the table model |
|to enhance accessibility for |
|screen readers. |
|Download Latest Revision |
|Public Download Link |
|Submitter: Mr. Scott Hudson |
|Group: OASIS Darwin Information Typing |
|Architecture (DITA) TC |
|Folder: Drafts |
|Date submitted: 2013-06-24 10:52:16 |
|Revision: 0 |
| |
|------------------------------------------------|
______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
______________________________________________________________________
|