Hi all,
Some general info on how ASCII art and SVG are currently handled by
tools below --
On 5/13/25 5:39 PM, Agent wrote:
I'm thinking about this one. My initial thoughts are that we should use
an alternatives mechanism so that ASCII art is always there but SVG
overlay exists - or maybe work on an ASCII/SVG gateway is called for.
[JM] RFCXML supports the inclusion of both ASCII art and SVG artwork
types in the artset element [1]. When xml2rfc is run on an RFCXML file
that contains both of these artwork types in an artset, it places the
ASCII art in the text output and the SVG in the HTML output.
If the artset element only includes SVG (that is, the diagram is too
complex and can only be drawn in SVG), then xml2rfc automatically
generates a message in the text output telling the reader to see the
HTML for the figure. For instance:
(Artwork only available as SVG: see
https://www.rfc-editor.org/rfc/rfc9633.html)
Figure 1: Case A-1: Application Flow Aggregation
So far, only RFCs 9633 and 9692 have these redirects.
As for ASCII/SVG gateways, there are tools that convert ASCII art into
SVG. For example, aasvg [2] can be run standalone on ASCII art files or
it can be invoked by kramdown-rfc to create SVG from the ASCII art in a
md file that is then placed in the RFCXML file. More info on how
kramdown-rfc handles SVG can be found on its wiki [3].
Not sure how the current generation of braille readers are impacted by
SVG
[JM] SVG is accessible to screen reader apps. The SVG desc element [4]
allows authors to provide a description of the diagram that is then read
to screen reader users.
There is an open issue [5] on xml2rfc to add this to the artset element
so that descriptive text can be made available to screen readers for any
artwork type.
and it is important not to risk trojans in the vectors.
[JM] Yes, and draft-editorial-rswg-svgsinrfcs states that SVGs must not
contain executable script.
Best regards,
Jean
[1] https://authors.ietf.org/en/rfcxml-vocabulary#artset
[2] https://github.com/martinthomson/aasvg
[3] https://github.com/cabo/kramdown-rfc/wiki/SVG
[4] https://www.w3.org/TR/SVG-access/#Equivalent
[5] https://github.com/ietf-tools/xml2rfc/issues/898
Probably
offended someone with that but I hope you know what I mean.
If you have received this message by common mistake, please contact the
sender as soon as possible - you may be committing an offence if you
copy it, or make use of any information contained in it for any purpose,
or disclose its contents to any other person. Messages sent and received
may not be private and may be the subject of monitoring.
Sent from Proton Mail Android
-------- Original Message --------
On 13/05/2025 23:18, Paul Duffy \(paduffy\) wrote:
"The RSWG is currently working on replacing RFC 7996, which allowed
the use of SVGs in RFCs. (We would like to make creating SVGs easier
for the community.)”
Long, long overdue good news. IMO SVG must be treated as a first-
class feature for RFC production and related IETF tooling. Meaning
IETF needs to adhere to the SVG format/tooling used by the rest of
the world.
*From:*Alexis Rossi <[email protected]>
*Sent:* Tuesday, May 13, 2025 6:01 PM
*To:* [email protected]
*Subject:* [rfc-i] Normative information in RFC imagery
Hello,
This is a long one, so let me state my goal up front. I am trying to
ascertain whether there is community interest in trying to make sure
future RFCs can be fully read and understood without relying on
information in imagery (SVG or ASCII). This is an accessibility
issue, but I think it also may be helpful for people who learn in
different ways. We are not talking about trying to address this in
older RFCs, just new ones.
If there is interest in this, I think the path we would take would
be to have an IETF working group attempt to address the issue.
* Background
The RSWG is currently working on replacing RFC 7996, which allowed
the use of SVGs in RFCs. (We would like to make creating SVGs easier
for the community.)
RFC 7996 contains the following language in the introduction:
"Note that in RFCs, the text provides normative descriptions of
protocols, systems, etc. Diagrams may be used to help explain
concepts more clearly, but they provide supporting details and
should not be considered to be complete specifications in themselves."
The RSWG draft [1] that has been adopted for the replacement of 7996
currently has similar but stronger language (though softer language
has been suggested in thread), and this has lead to a discussion
about normative info in imagery: https://mailarchive.ietf.org/arch/
msg/rswg/E4eBJEmlTo5nX7ITYFvIvjKa2ec/ <https://mailarchive.ietf.org/
arch/msg/rswg/E4eBJEmlTo5nX7ITYFvIvjKa2ec/>
* Thread Discussion Summary
Some people think that we already have the general idea in the
community that the text should be normative, and that imagery should
be a helpful illustration of the text. (So you could have normative
info in an image, but that shouldn't be the ONLY place where it
exists.) Other than the above text in RFC7996, this seems to be
"folklore" or a generally accepted but not documented norm.
Additionally, the point has been made that 7996 is an Informational
IAB document (so does not have IETF consensus), and shouldn't govern
how the IETF uses imagery.
Others have made the point that this has never been an accepted norm
for ASCII art. We haven't found a citation that says otherwise
(other than 7996). And it seems that in regards to packet diagrams
specifically, BCP 22/RFC2360 Section 3.1 [2] actually tells us to
put normative info into ASCII art.
Additionally, in discussing whether it is even possible to have all
normative information in the text, some have asserted (and others
have refuted) that some types of information may be too difficult/
onerous to represent fully in text, thus making a diagram/image the
most reasonable place for the information.
* Accessibility
ASCII art is not accessible to people using screen readers. It is
read as gobbledygook, essentially. ZSo generally there are three
ways to make imagery accessible:
1) provide adequate alt/desc text within the code to fully describe
the content of a diagram/image to someone using a screen reader (SVG
only)
2) use aria labels appropriately to allow a screenreader user to
navigate the diagram (SVG only)
3) fully describe the normative information in the text (TXT has all
the info needed outside of the ASCII art, and SVG points people to
the text)
A fourth path has been suggested: using a formal language to
describe diagrams. UML was suggested as a possibility. I have not
yet found convincing evidence that UML alone is sufficiently
accessible to people with visual disabilities.
So I think this leads me back to my goal for posting here. Is the
community interested in supporting accessibility by trying to make
sure future RFCs can be fully read and understood without relying on
information in imagery? And thank you for reading this far!
Alexis
[1] https://datatracker.ietf.org/doc/draft-editorial-rswg-
svgsinrfcs/ <https://datatracker.ietf.org/doc/draft-editorial-rswg-
svgsinrfcs/>
[2] https://www.rfc-editor.org/rfc/rfc2360.html#section-3.1
<https://www.rfc-editor.org/rfc/rfc2360.html#section-3.1>
_______________________________________________
rfc-interest mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
rfc-interest mailing list -- [email protected]
To unsubscribe send an email to [email protected]
