Subject: [rfc-i] Re: Normative information in RFC imagery
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Date: Tue, 13 May 2025 15:40:03 -0700
List-Id: "A general discussion list about the RFC Series and its operational processes." <rfc-interest.rfc-editor.org>

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