Paul, others,I'm entirely in favor of an approach to image use that appropriately addresses accessibility requirements. As I wrote elsewhere, images and text should match. If they don't it's an erratum. After all, nobody creates a picture (SVG or ASCII) that is intentionally inconsistent with text, although some might have forgotten or omitted fully descriptive text. What is "normative" at that point is going to be what has been implemented, and if there are differences, then the erratum or an update must settle those differences. That is the practical reality.
That leads us to another point: any "policy" around this must be consistent across streams. Those of us who have been around for a while *might* be able to glean the differences between streams, but even for us, imagine dealing with normative references between streams: do we expect people to keep a rule book at their side to determine which is normative in what circumstances? Let's not do that.
Eliot On 14.05.2025 00:40, Paul Hoffman wrote:
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 [email protected]
OpenPGP_0x87B66B46D9D27A33.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ rfc-interest mailing list -- [email protected] To unsubscribe send an email to [email protected]
