[rfc-i] Color/grayscale/monochrome (was: Re: Reasons for going beyond ASCII art)
fluffy at iii.ca
Wed Sep 26 22:59:29 PDT 2012
Imagine you have two version of a doc where the only difference was the color of some object in the draft had changed. I suspect we don't have diff tools that are \ capable of dealing with that very well.
And Accessibility for color blind people is also complicated
On Sep 25, 2012, at 19:16 , Martin J. Dürst wrote:
> On 2012/09/25 23:41, Heather Flanagan (RFC Series Editor) wrote:
>> On 9/21/12 4:40 PM, Brian E Carpenter wrote:
>>> A related point that is not mentioned is whether we have a requirement
>>> to support colour or greyscale, or whether we require that an RFC can
>>> be correctly printed in monochrome.
>> Very good point! Something about this needs to be in the doc. I think
>> opening up to color introduces a rather large set of complications.
>> Color blindness and screen calibration issues are the first concerns
>> that pop in to my head. I understand some people will find the diagrams
>> that much easier to read if color was involved, but I am not convinced
>> the benefit outweighs the difficulties this would introduce.
> In terms of technology, color doesn't introduce many complications. Graphics and image formats these days can handle color without problems. Same for displays even on quite limited devices (not if one wants to read an RFC on the display of a washing machine or a pocket calculator, but in that case, there will be more serious problems anyway). For printers, there are certainly still black-and-white or grayscale printers, but most printers these days can handle color, too.
> So the main problem are humans. We need to have a clear accessibility story for graphics/images anyway, which can probably be summarized in these two checkpoints:
> 1) Graphic/image needs to still be understandable when viewed in grayscale or monochrome mode.
> 2) Document needs to be understandable even without the graphics/images.
> Given that we need a checklist anyway, the fact that it has two entries doesn't change too much. And these points should go into ID-nits, too, so that authors are aware of them early on, and the RFC editor doesn't need to go back to the authors and tell them to submit conforming graphics/images. It should never be necessary that the RFC Editor on their own has to change the graphics/images, that should always be the responsibility of the authors/editors.
> Regards, Martin.
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
More information about the rfc-interest