W3C home > Mailing lists > Public > public-apa-admin@w3.org > August 2022

Re: Call for Consensus (CfC): APA Comment on CSS Color Module Level 5

From: Lionel Wolberger <lionel@userway.org>
Date: Thu, 18 Aug 2022 17:38:06 +0300
Message-ID: <CAHOHNHcKP+k=CQeM2uNsnc7Zp68PeYq1vQ=ckg45LuXNO=wz0Q@mail.gmail.com>
To: "public-apa-admin@w3.org" <public-apa-admin@w3.org>

On Wed, Aug 17, 2022 at 2:40 PM Matthew Atkinson <matkinson@tpgi.com> wrote:

> Colleagues: This is a Call for Consensus (CfC) to the Accessible Platform
> Architectures (APA) Working Group testing for agreement on a formal comment
> on the CSS Color Module Level 5 specification (
> https://www.w3.org/TR/2022/WD-css-color-5-20220628/).
> An accessibility review was requested of the APA as part of our role in
> performing horizontal review of W3C documents for accessibility concerns.
> It was reviewed by APA member Matthew who proposed the comments you can
> find below. I have made some minor edits for clarity, and to reflect it's a
> group comment. Please note that these take into account the discussion we
> had about noting trigger warnings in color names, should a specific palette
> be used as the basis for creating descriptive color names:
> https://www.w3.org/2022/08/10-apa-minutes.html#t10
> If the group agrees, the main review comment will be posted on the thread
> where the review was requested (
> https://github.com/w3c/a11y-request/issues/29) and the rest of the
> comments, about the document's accessibility, will be posted on the CSS
> Working Group's issue tracker, as a series of separate, specific issues
> (which will all be noted as being on the behalf of APA). Non-substantive
> edits will be made in order to allow the issues to stand alone. (
> https://github.com/w3c/csswg-drafts/issues/)
> *** Action to Take ***
> This CfC is now open for objection, comment, as well as statements of
> support via email. Silence will be interpreted as support, though messages
> of support are certainly welcome.
> If you object to this proposed action, or have comments concerning this
> proposal, please respond by replying on list to this message no later than
> 23:59 (Midnight) Boston Time, Wednesday 24 August.
> NOTE: This Call for Consensus is being conducted in accordance with the
> APA Decision Policy published at:
> http://www.w3.org/WAI/APA/decision-policy
> <APA Comments>
> # Overall accessibility review comment
> APA has no accessibility concerns regarding the substance of [CSS Color
> Module Level 5](https://www.w3.org/TR/2022/WD-css-color-5-20220628/) (we
> reviewed the 2022-06-28 WD).
> It's clear that a lot of effort has gone into making the document readable
> and understandable. However, we did notice some accessibility barriers,
> particularly from the perspective of readers who may struggle with color
> perception. These concerns, with suggestions, are being filed as issues on
> the CSSWG tracker.
> We're aware that `color-contrast()` has been pushed back to Level 6.
> However, we were wondering what are the use cases for this function? The
> function selects from a pre-determined list of colours; are there
> situations in which the answer could not have been determined at design
> time? We don't feel that this function is required in order to further
> accessibility, but we're happy to provide any needed support in adding it,
> if you wish to add it or something similar in future.
> # Accessibility suggestions on the document's presentation
> ## General: color previews
> ### Naming colors
> Adding "alternative text" to the visual color preview feature could be
> very helpful for people with vision impairments who currently have to rely
> on the colors' coordinates alone. Whilst coordinates are provided for every
> color mentioned in the examples, they may not give the reader much of a
> sense of what the color might look like, making the examples hard to follow
> (e.g. it's much easier to understand the effects of certain types of mixing
> by glancing at the previews and noting the similarities or differences from
> the input colors, rather than parsing through the coordinates). The
> document describes some of the colors that have previews, but not all.
> There are some tools that gives you the closest color name to a given
> (usually hex-encoded) color, from an extensive palette of predefined
> colors. This sort of tool would give a good enough idea for most people who
> may be unable to perceive the colors directly. The color names could be
> generated as part of the document build process, and placed in
> visually-hidden text in the document. The text should also indicate if the
> colours are transparent.
> One such tool is "color-to-name" (<
> https://github.com/stanleyfok/color-to-name>)—however, a small number of
> the color names in the palette may be considered vulgar, so they would
> either have to be filtered out, or a different tool selected. The same
> applies for color names that may be triggering for some people. We can do
> more research on tools of this nature, if you like.
> It's noted that out-of-gamut colors are indicated by a red border on their
> previews, and they're always described in accompanying text as being out of
> gamut, which is helpful.
> ### Keyboard operability for the previews
> The color previews can be hovered with the mouse. When this happens, they
> enlarge, covering some of the text behind. This is particularly useful if
> the preview is of a transparent color, as the text behind shows through the
> preview window. It is not possible to activate the preview with the
> keyboard, so keyboard-only users would likely miss out on this helpful
> feature.
> ### Previews in `<pre>` blocks—rendering bug
> The previews inside code example blocks can't expand outside of those
> blocks, so aren't drawn fully in those cases.
> ## General: Test result indication
> _This is quite possibly a bug in a library you're using, though I couldn't
> find any pointers after a brief search relating to WPT._
> There's a low contrast difference between the two sections of the pie
> charts. This is particularly apparent in §4.
> Suggestion: use techniques similar to those from [Figure 21 in the
> Understanding WCAG SC 1.4.11 document](
> https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html#figure-passing-pie-chart),
> i.e. (1) separating the segments; (2) using more contrasting colours;
> and/or (3) using hollow and solid segments to ease differentiation.
> ## §2.2
> ### Example 2
> * This example has a figure with a descriptive caption. The `<img>`
> element lacks an `alt` attribute. The `alt` text should mention that the
> image shows three colours (the two inputs, and the mixed output) on a plane
> with two axes. The axes are labelled "a" and "b" and cross at the origin,
> which is in the centre of the plot. We are looking down the L axis onto an
> ab plane.
> * An `<img>` that has `alt` text in Example 22 (in §3.6) refers to this
> plane as the CH plane. This seems to be conventional, but it may be helpful
> for people who are not familiar with color spaces to mention it in the
> document's text.
> * For someone who struggles to see the color, or low-contrast colors, it
> would be helpful to label the colors on the chart ("peru", "palegoldenrod"
> and "mixed" for the mixed color, in this case). (You could perhaps do this
> with numbers, to save space, and keep the layout simple, in the diagram, as
> long as they match up to numbers, color previews, and coordinates in the
> text below.)
> ### Example 3
> The above three issues apply here too.
> ## §3.6
> ### Example 22
> In the spirit of the issue reported above, we don't feel this needs
> extensive `alt` text (though describing the axes and general situation
> would be helpful). However, it would be particularly helpful to ensure that
> the different colors can be identified on the plot, e.g. via labelling.
> ## §4.4
> ### Figure 5
> * The `<img>` needs `alt` text such as "A color swatch, in a grid layout".
> * The second part is marked up as a `<table>` but doesn't seem to be one
> semantically (it's just placing the text to match the layout of the color
> swatch above). Suggest applying `role="presentation"` to the table, to
> remove the tabular structure semantics (or you could re-code it using
> `<div>`s and `<span>`s). That would have the effect of linearizing the
> table from a screen reader perspective, but that would likely be less
> confusing than encountering a "table" without headers.
> ### Example 33
> Color previews are missing.
> ## §5
> ### Figure 6
> * The `<img>` needs an `alt` attribute that explains this is a color
> swatch in a grid formation (as per figure 5) but that circles are imposed
> on each grid square. The `<figcaption>` does a great job of explaining the
> rest.
> * As with figure 5, this table should have the table semantics removed (or
> be re-coded using `<div>`s and `<span>`s).
> </APA Comments>
> --
> Matthew Tylee Atkinson (he/him)
> --
> Principal Accessibility Engineer
> TPG Interactive
> https://www.tpgi.com
> A Vispero Company
> https://www.vispero.com
> --
> This message is intended to be confidential and may be legally privileged.
> It is intended solely for the addressee. If you are not the intended
> recipient, please delete this message from your system and notify us
> immediately.
> Any disclosure, copying, distribution or action taken or omitted to be
> taken by an unintended recipient in reliance on this message is prohibited
> and may be unlawful.
Received on Thursday, 18 August 2022 14:38:55 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 18 August 2022 14:38:56 UTC