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 assess.
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 committee.
>>
>> 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>btusdin@xxxxxxxxxxxxxxxx
>> Mulberry Technologies, Inc.
<https://www.mulberrytech.com>https://www.mulberrytech.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.htm
l
>>>
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/ |
> 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 |
>
>
--
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
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.
--~----------------------------------------------------------------
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
--~--