|
Subject: Re: [niso-sts] Question regarding alternative and description text From: "G. Ken Holman g.ken.holman@xxxxxxxxx" <niso-sts-list-service@xxxxxxxxxxxxxxxxxxxxxx> Date: Tue, 14 Nov 2023 01:14:53 -0000 |
Good questions to ask, Gareth, regarding the supplemental declaration regarding the normative status. I think answers to them would support my suggestion in my contribution that a recommended convention be documented without such a need.
Hi all,assess.
I think this is actually a very interesting thread because I expect we will see a continued rise in prominence of digital-first delivery of standards content and, moreover, the participation of standards content (and fragments of such content) in a "content supply chain". (Example: architectural and design software that automatically incorporates requirements and constraints from relevant building codes)
From the perspective of codes & standards with legal effect: it is obviously crucial to correctly identify fragments of the content, their meaning, and their relationship(s) to other fragments. If legislation cites specific clauses of such, then both the declared and implied relationships must be represented such that the fragmented content may reference or incorporate all necessary related information. The archetype in my mind up to this point was for sections or clauses of a publication but now, as per Ken's inquiry, consideration must extend to what might we might term secondary, ancillary, or derived information artifacts.
Gerrit's summary seems reasonable, although I feel like the underlying requirement might point to a more nuanced need to model or capture additional semantics? It seems to me that it could get tricky, for example the meta-note suggestion: who would add the tagging, how could it be assured to be correct at point of publication, and how could that process be made efficient or automated?
I hope my perspectives add something to the discussion.
// Gareth Oakes
// Chief Project Officer, GPSL
// www.gpsl.co
---------- From: Imsieke, Gerrit, le-tex gerrit.imsieke@xxxxxxxxx <niso-sts-list-service@xxxxxxxxxxxxxxxxxxxxxx> Sent: Tuesday, 14 November 2023 8:40 AM To: niso-sts-list@xxxxxxxxxxxxxxxxxxxxxx <niso-sts-list@xxxxxxxxxxxxxxxxxxxxxx> Subject: Re: [niso-sts] Question regarding alternative and description text
Hi Ken,
A stance that people may take is: If the described content, a figure, an equation, etc., is normative, then the describing text is normative, too, and must be authored with this normativeness in mind.
But I don't think there is consensus about it. It would place such an unrealistic onus on the descriptions -- they need to convey exactly the same normative information that the figures or equations convey.
This way, the descriptions might easily become very detailed, lengthy, and hard to author. Plus, their equivalence with the underlying object will be difficult to
committee.
But if, on the other hand, the descriptions are too superficial or generic ("a diagram that contains labeled boxes and lines", "an equation for determining the maximal tensile strain at a given temperature"), the standard might not meet accessibility requirements imposed by law.
This is certainly a thing that the standing committee should discuss, and they should get advice from a11y experts. I can imagine that some best practice recommendations will emerge in the NISO STS documentation, such as the recommendation to include a meta-note[@content-type='cautionary'] that states that alt-text and long-desc descriptions, even when attached to normative content, are informative, despite best efforts to convey the underlying information as precisely as feasible.
Gerrit
On 13.11.2023 23:01, G. Ken Holman g.ken.holman@xxxxxxxxx wrote: > Thank you, Tommie! > > As I am trying to provide guidance to my clients, I would appreciate bringing the question of the normative/non-normative properties for <alt-text> and <long-desc> to the committee. > > Would you please point me to a procedures page where I can learn more regarding how to pose my question to them? > > I have ideas for the PDF rendering, and I like Liam's comment regarding a helpful annex. So I'm feeling more comfortable now regarding what I might offer clients in regards to the rendering. > > I'm left with the question of guidance regarding what information clients should and should not be putting into these "non-visual" constructs. > > Thank you, again. > > . . . . . . Ken > > At 2023-11-13 21:19 +0000, Tommie Usdin btusdin@xxxxxxxxxxxxxxxx wrote: >> Ken -- >> >> I think you are asking two questions: >> * in STS, is the content of the <alt-text> and <long-desc> normative? and >> * how should this content be handled when rendering STS documents in PDF? >> I do not remember any conversations in the STS committees or in the ISO work that preceded it about <alt-text> and <long-desc>. To my recollection, these elements were adopted from JATS without discussion. Since journal articles do not have normative and non-normative content, JATS provides no guidance on the normative status of <alt-text> and <long-desc>. This might be an interesting question to pose to the STS standing
>> >> As for how <alt-text> and <long-desc> should be handled in PDF. I see no reason standards documents should be different in this respect from any other document. (I am told that including the information needed for screen readers in PDF documents is fiddly but possible. I have no first hand experience doing this.) >> >> -- Tommie >> ====================================================================== >> B. Tommie Usdin mailto:
<<mailto:btusdin@xxxxxxxxxxxxxxxx>mailto:btusdin@xxxxxxxxxxxxxxxx>btusdin@mul berrytech.com
>> Mulberry Technologies, Inc.
<<https://www.mulberrytech.com>https://www.mulberrytech.com>https://www.mulbe rrytech.com
>> Mulberry Technologies, Inc.: A Consultancy Specializing in XML for Prose Documents >> ====================================================================== >> On Nov 13, 2023, 3:21 PM -0500, G. Ken Holman g.ken.holman@xxxxxxxxx <niso-sts-list-service@xxxxxxxxxxxxxxxxxxxxxx>, wrote: >>> Rereading the documentation, I think I found the key phrase I was looking for: >>> >>> "non-visual element" >>> >>> ... found for both elements. So, I guess that is definitive that I >>> have no rendering obligations outside of those used for assistive >>> access, and so I conclude it must not contain normative content. >>> >>> Although I am a bit worried when I read for <long-desc>: >>> >>> "... explains both the visual form of the chart >>> and significance of its findings." >>> >>> ... because I would think "significance" borders on being normative. >>> If the long description is to be assistive regarding an impairment >>> preventing the visualization of a graphic or table or formula, any >>> accompanying general text would/should already have normative >>> significance for all readers and, therefore, should not be in >>> assistive content that not all readers access. >>> >>> Anyway ... I have my direction. >>> >>> So I withdraw my question ... sorry for taking up the bandwidth. >>> >>> . . . . . . . . Ken >>> >>>
<https://www.niso-sts.org/TagLibrary/niso-sts-TL-1-0-html/element/alt-text.ht ml>https://www.niso-sts.org/TagLibrary/niso-sts-TL-1-0-html/element/alt-text. html
>>>
https://www.niso-sts.org/TagLibrary/niso-sts-TL-1-0-html/element/long-desc.ht ml
>>> >>> At 2023-11-13 19:59 +0000, G. Ken Holman g.ken.holman@xxxxxxxxx wrote: >>>> Fellow NISO STS list members, >>>> >>>> May I consider content found in <alt-text> and <long-description> as >>>> informative and not normative? I see nothing in the documentation >>>> that states one way or the other. >>>> >>>> My thought is that a PDF or paper rendering would (typically) hide >>>> this content from the reader. As a publisher of said content, do I >>>> have any obligation to render these elements visibly due to them >>>> possibly being normative? >>>> >>>> I can't think of why they would be normative. Important, yes, but >>>> authoring STS I wouldn't expect something normative to be stated in >>>> these elements, so I can make some assumptions when rendering. >>>> >>>> Thank you for your thoughts. >>>> >>>> . . . . . Ken > > > -- > Contact info, blog, articles, etc. <http://www.CraneSoftwrights.com/j/>http://www.CraneSoftwrights.com/j/ | > Check our site for free XML, XSLT, XSL-FO and UBL developer resources | > Streaming hands-on XSLT/XPath 2 training class @US$125 (5 hours free) | > Essays (UBL, XML, etc.)
<http://www.linkedin.com/today/author/gkholman>http://www.linkedin.com/today/ author/gkholman
| > >
-- Gerrit Imsieke Geschdftsf|hrer / Managing Director le-tex publishing services GmbH Weissenfelser Str. 84, 04229 Leipzig, Germany Phone +49 341 355356 110, Fax +49 341 355356 510 gerrit.imsieke@xxxxxxxxx, <http://www.le-tex.de>http://www.le-tex.de
Registergericht / Commercial Register: Amtsgericht Leipzig Registernummer / Registration Number: HRB 24930
Geschdftsf|hrer / Managing Directors: Gerrit Imsieke, Svea Jelonek, Thomas Schmidt
---------- DISCLAIMER - This email and any attachments are confidential and contain proprietary and commercially valuable information and intended solely for the use of the individual or entity to whom they are addressed. If you are not the named addressee you should not disclose, distribute or copy this e-mail and any attachments, or take any action in reliance on the contents. If you have received this message by mistake, please notify the sender immediately, so that we can make sure such a mistake does not happen again. GPSL is the trading name of Global Publishing Solutions Limited and its subsidiaries, registered as a limited company in England and Wales under company number 06379381. Its registered address is Chargrove House Main Road, Shurdington, Cheltenham, England, GL51 4GA.
-- Contact info, blog, articles, etc. http://www.CraneSoftwrights.com/j/ | Check our site for free XML, XSLT, XSL-FO and UBL developer resources | Streaming hands-on XSLT/XPath 2 training class @US$125 (5 hours free) | Essays (UBL, XML, etc.) http://www.linkedin.com/today/author/gkholman | --~---------------------------------------------------------------- NISO STS Discussion Mailing list by Mulberry Technologies, Inc. EasyUnsubscribe: https://lists.mulberrytech.com/unsub/niso-sts-list/archive-lists.mulberrytech .com-niso-sts-list@xxxxxxxxxxx or by email: niso-sts-list-unsub@xxxxxxxxxxxxxxxxxxxxxx --~--
| Current Thread |
|---|
|
| <- Previous | Index | Next -> |
|---|---|---|
| Re: [niso-sts] Question regarding a, Gareth Oakes goakes@ | Thread | Re: [niso-sts] Question regarding a, Imsieke, Gerrit, le- |
| Re: [niso-sts] Question regarding a, G. Ken Holman g.ken. | Date | Re: [niso-sts] Question regarding a, G. Ken Holman g.ken. |
| Month |