This is a great summary of a thread that should have moved to this list
long ago; it does not belong in the RSWG.
It would help the entire IETF community if there was a definitive RFC
covering this topic. Each RFC stream could decide if they agree with the
contents of the eventual RFC for their own stream.
--Paul Hoffman
On 13 May 2025, at 15:00, Alexis Rossi wrote:
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/
* 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/
[2] 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]
