No. On 5/13/25 3:00 PM, 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]
-- Marc Petit-Huguenin Email: [email protected] Blog: https://medium.com/@petithug Profile: https://www.linkedin.com/in/petithug
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ rfc-interest mailing list -- [email protected] To unsubscribe send an email to [email protected]
