Re: [rfc-i] Seeking community input: Issues with accessibility of artwork used in RFCs

Carsten Bormann <cabo@tzi.org> Thu, 06 July 2023 03:48 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: rfc-interest@ietfa.amsl.com
Delivered-To: rfc-interest@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F5C4C14F74E; Wed, 5 Jul 2023 20:48:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ll4i_n3WVyK0; Wed, 5 Jul 2023 20:48:27 -0700 (PDT)
Received: from smtp.zfn.uni-bremen.de (smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5F97C15199E; Wed, 5 Jul 2023 20:48:25 -0700 (PDT)
Received: from smtpclient.apple (p548dc15c.dip0.t-ipconnect.de [84.141.193.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4QxMvC21WFzDCcM; Thu, 6 Jul 2023 05:48:23 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <2700295F-EE85-44C1-9300-B6C1BAB6A8F8@rfc-editor.org>
Date: Thu, 06 Jul 2023 05:48:11 +0200
Cc: RFC Interest <rfc-interest@rfc-editor.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <16AA303E-82FE-4F09-ADCC-7807D5FA4EF1@tzi.org>
References: <2700295F-EE85-44C1-9300-B6C1BAB6A8F8@rfc-editor.org>
To: Alexis Rossi <rsce@rfc-editor.org>
X-Mailer: Apple Mail (2.3731.600.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfc-interest/bsgB6WTaUBvgwryDuUNyHq3oGyQ>
Subject: Re: [rfc-i] Seeking community input: Issues with accessibility of artwork used in RFCs
X-BeenThere: rfc-interest@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "A list for discussion of the RFC series and RFC Editor functions." <rfc-interest.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/rfc-interest>, <mailto:rfc-interest-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rfc-interest/>
List-Post: <mailto:rfc-interest@rfc-editor.org>
List-Help: <mailto:rfc-interest-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/rfc-interest>, <mailto:rfc-interest-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Jul 2023 03:48:31 -0000

On 5. Jul 2023, at 20:09, Alexis Rossi <rsce@rfc-editor.org> wrote:
> 
> * Greyscale and color are currently forbidden in SVGs. Do they need to be? If either are allowed, what guidance can we use to create a palette and ensure that it is used in an acceptable way?

Note that there is nothing wrong with using color (hues, lightness/grayscale, saturation) for additional illustrative value, as long as the document is still useful without this.

E.g., “the red items in the table MUST NOT be used” should not be acceptable if it is the only way a normative requirement is presented, but indicating such a requirement with an asterisk as well as red color is absolutely fine.

Also, information that is delivered in one way (e.g., ABNF) and then additionally illustrated in another, less accessible way (e.g., railroad diagrams [1]) should never be a problem.

These examples should make it obvious that striving for accessibility by enforcing some mechanic limitation on expressibility is a misguided approach.

Grüße, Carsten

[1]: https://www.ietf.org/archive/id/draft-ietf-core-href-12.html#section-5.1.2-1