From: Paul Hoffman <phoffman@proper.com>
To: rfc-interest@rfc-editor.org
Date: Tue, 13 May 2025 15:40:03 -0700
Message-ID: <8B304289-B709-43F8-AB34-38CF2B5811EF@proper.com>
In-Reply-To: 
 <CALLfFGPtFPZh2onghyiiurH0QBOUmde7Xck66+0tv7-OF07QgA@mail.gmail.com>
References: 
 <CALLfFGPtFPZh2onghyiiurH0QBOUmde7Xck66+0tv7-OF07QgA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="=_MailMate_1611933A-2AD0-4558-9785-30C47DB3E3C0_="
Embedded-HTML: 
 [{"plain":[373,3916],"uuid":"D66F2D0F-6F63-4E69-A199-29B17387A994"}]
Message-ID-Hash: GCXNC66RYJHIQZP6KV3AQIABUFJT54FQ
Precedence: list
Subject: =?utf-8?q?=5Brfc-i=5D_Re=3A_Normative_information_in_RFC_imagery?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/rfc-interest/oPkV-UiI9B4MJZeZPuv0NZLMd-o>


--=_MailMate_1611933A-2AD0-4558-9785-30C47DB3E3C0_=
Content-Type: text/plain; format=flowed

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


--=_MailMate_1611933A-2AD0-4558-9785-30C47DB3E3C0_=
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html>
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/xhtml; charset=3Dutf-8"=
>
</head>
<body><div style=3D"font-family: sans-serif;"><div class=3D"plaintext" st=
yle=3D"white-space: normal;"><p dir=3D"auto">This is a great summary of a=
 thread that should have moved to this list long ago; it does not belong =
in the RSWG.</p>
<p dir=3D"auto">It would help the entire IETF community if there was a de=
finitive RFC covering this topic. Each RFC stream could decide if they ag=
ree with the contents of the eventual RFC for their own stream.</p>
<p dir=3D"auto">--Paul Hoffman</p>
<p dir=3D"auto">On 13 May 2025, at 15:00, Alexis Rossi wrote:</p>
</div><blockquote class=3D"embedded" style=3D"margin: 0 0 5px; padding-le=
ft: 5px; border-left: 2px solid #777777; color: #777777;"><div id=3D"D66F=
2D0F-6F63-4E69-A199-29B17387A994">

<div dir=3D"ltr">Hello,<br>
<br>
This is a long one, so let me state my goal up front. I am trying to asce=
rtain whether there is community interest in trying to make sure future R=
FCs can be fully read and understood without relying on information in im=
agery (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 talkin=
g about trying to address this in older RFCs, just new ones.<br>
<br>
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.<br>
<br>
* Background<br>
<br>
The RSWG is currently working on replacing RFC 7996, which allowed the us=
e of SVGs in RFCs. (We would like to make creating SVGs easier for the co=
mmunity.)<br>
<br>
RFC 7996 contains the following language in the introduction:<br>
<br>
"Note that in RFCs, the text provides normative descriptions of protocols=
, systems, etc. Diagrams may be used to help explain concepts more clearl=
y, but they provide supporting details and should not be considered to be=
 complete specifications in themselves."<br>
<br>
The RSWG draft [1] that has been adopted for the replacement of 7996 curr=
ently has similar but stronger language (though softer language has been =
suggested in thread), and this has lead to a discussion about normative i=
nfo in imagery: <a href=3D"https://mailarchive.ietf.org/arch/msg/rswg/E4e=
BJEmlTo5nX7ITYFvIvjKa2ec/">https://mailarchive.ietf.org/arch/msg/rswg/E4e=
BJEmlTo5nX7ITYFvIvjKa2ec/</a><br>
<br>
* Thread Discussion Summary<br>
<br>
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 i=
llustration of the text. (So you could have normative info in an image, b=
ut that shouldn't be the ONLY place where it exists.) Other than the abov=
e text in RFC7996, this seems to be "folklore" or a generally accepted bu=
t not documented norm. Additionally, the point has been made that 7996 is=
 an Informational IAB document (so does not have IETF consensus), and sho=
uldn't govern how the IETF uses imagery.<br>
<br>
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 79=
96). 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 ASC=
II art.<br>
<br>
Additionally, in discussing whether it is even possible to have all norma=
tive information in the text, some have asserted (and others have refuted=
) that some types of information may be too difficult/onerous to represen=
t fully in text, thus making a diagram/image the most reasonable place fo=
r the information.<br>
<br>
* Accessibility<br>
<br>
ASCII art is not accessible to people using screen readers. It is read as=
 gobbledygook, essentially. ZSo generally there are three ways to make im=
agery accessible:<br>
<br>
1) provide adequate alt/desc text within the code to fully describe the c=
ontent of a diagram/image to someone using a screen reader (SVG only)<br>=

2) use aria labels appropriately to allow a screenreader user to navigate=
 the diagram (SVG only)<br>
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)<=
br>
<br>
A fourth path has been suggested: using a formal language to describe dia=
grams. UML was suggested as a possibility. I have not yet found convincin=
g evidence that UML alone is sufficiently accessible to people with visua=
l disabilities.<br>
<br>
So I think this leads me back to my goal for posting here. Is the communi=
ty interested in supporting accessibility by trying to make sure future R=
FCs can be fully read and understood without relying on information in im=
agery? And thank you for reading this far!<br>
<br>
Alexis<br>
<br>
<br>
[1] <a href=3D"https://datatracker.ietf.org/doc/draft-editorial-rswg-svgs=
inrfcs/">https://datatracker.ietf.org/doc/draft-editorial-rswg-svgsinrfcs=
/</a><br>
[2] <a href=3D"https://www.rfc-editor.org/rfc/rfc2360.html#section-3.1">h=
ttps://www.rfc-editor.org/rfc/rfc2360.html#section-3.1</a></div></div></b=
lockquote>
<div class=3D"plaintext" style=3D"white-space: normal;">
</div>

</div>
</body>

</html>

--=_MailMate_1611933A-2AD0-4558-9785-30C47DB3E3C0_=--