RE: Should we drop the color bullet for now?

Laura & LVTF,

I've been thinking about this in the context of the list of things that can go wrong that Wayne provided on a recent AG WG email.  Taking these one by one:

1. The author uses sprite taken from the background image.
In my opinion, I think outlawing sprites would be met with harsh resistance.  This is yet another loophole where the versatility of CSS is used to create content, graying the lines with style.  The other major one getting attention being icon fonts.  Again, this goes back to the markup using role="img" so that user styles have a discriminating selector.

2. The author uses transparent images for controls that depend on the pages background color for visibility
I agree this is a highly annoying one, and for other reasons than just user styles (e.g.  viewing a graphic on its own in order to zoom and remove distractions).  I wonder if this couldn't just be covered in a very simple SC of its own or be incorporated in Graphics Contrast?  A simple statement saying that essential graphical objects should not depend on colors outside the containing graphic for contrast should suffice.

3. Items that are hidden with color become visible
My gut is telling me this would fail another SC, but maybe some examples would help.  I don't think I ran across this too often in my user style days.

4. Embedded color declarations that use important
Wayne, I think this thought is missing a word or two and I don't have any educated guesses to complete it.  Could you fill us in?

Steve

-----Original Message-----
From: Laura Carlson [mailto:laura.lee.carlson@gmail.com] 
Sent: Tuesday, April 25, 2017 9:35 AM
To: public-low-vision-a11y-tf <public-low-vision-a11y-tf@w3.org>; Wayne Dick <wayneedick@gmail.com>
Subject: Should we drop the color bullet for now?

Hi Wayne and all,

Since we are dropping the font bullet from the Adapting Text SC for the time being to allow time for more research, I wonder if we should do the same for the color bullet?

We have no consensus on this current bullet:

* text color and background color to a single different text color and a single different background color

Other language that allows more colors will very likely get push back.

We could expand Andrew's font note, so the whole thing could read:

<start draft text>
Except for images of text and captions, text styles of the page can be overridden as follows with no loss of essential content or functionality.

* line spacing (leading) to at least 1.5
* letter spacing (tracking) to at least 0.12 em
* word spacing to at least 0.16 em

Editor's note: The Working Group seeks to include changes in text color, background color, and font-family as part of the SC, but is not yet able to identify a way to do so that is sufficiently testable.

</end draft text>

Thoughts?

Kindest Regards,
Laura


On 4/15/17, Wayne Dick <wayneedick@gmail.com> wrote:
>  *Adaptation of Text: *
>
> Right now, AGWG does not have enough quantitative information to 
> formulate a success criterion regarding text adaptation that is 
> sufficient to satisfy
> the:
>
> 1.  Needs of people with low vision and
>
> 2.  Requirements of WCAG 2.1 success criteria
>
> This problem can be solved but careful quantitative analysis is needed 
> before we can proceed. This requires a smaller group. I suggest 
> freezing all SC language development now and returning the SC to LVTF 
> for reformulation. The LVTF has enough feedback to reformulate this 
> criterion in a form that meets the needs of the target population and 
> is tractable for authors and testers.
>
> The basic problem is to:
>
> 1.  Provide the widest possible range of typographic choice to support 
> legibility of text, and
>
> 2.  Create a framework that authors can implement and test.
> *Example (Font Family)*
>
> A construct like, “Users can pick any font family” is too wide for 
> implementers. A construct like, “Users can pick one of 10 font 
> families from the following list … ,” is probably too limiting for users.
>
> This can be addressed statistically. We need to study the 
> distributions of actual font dimensions within the set of font 
> families. Namely, if we fix font size to 16 pixels then how do the 
> following parameters vary across font families:  height, width, 
> ascending stroke size and descending stroke size? With a clear 
> understanding of these distributions we could identify outliers that 
> are in wide use or appear to be applicable for a specific user need. 
> These outliers would be very wide, high or have extreme ascending or descending strokes.
> *Solving the User Need Problem*
>
> The W3C could maintain a list of permissible font families for changes.
> This could be a long list, maybe 500 font families.  This would 
> provide adequate choice. As part of WCAG Techniques update, this list 
> could be updated with new fonts as typographers create them.
> *Solving the Implementer and Tester Problem:*
>
> The primary issue for implementers is fitting an unplanned font family 
> into a non-responsive design.
>
> The font metric distribution could be maintained as part of the 
> permissible font families list.  A small set of outlier fonts could be 
> identified and all the author would need to do is test against this 
> list of outliers.  For this we probably need only four exemplars.  
> That is: the author tests the widest, highest, and most extreme 
> ascending and descending strokes. This would do what we wanted to do 
> with Verdana alone at the beginning. It would provide a true or false 
> test of whether the font change will disrupt layout.
>
> Once we establish the font size metric distribution, we can make very 
> exact sets of choices and testable limits. We may make a choice to set 
> limits to the extreme metrics. The difference between what we are 
> doing now is that we will know the actual dimensions of the data space.
> *Other Limits*
>
>  Our discussion lists have identified several limits imposed by web 
> platforms, technologies and practices. These include:
>
> 1.  Partial or no support from platforms and / or technologies
>
> 2.  Limited semantics necessary to support choice. Examples: 
> Identification of Icon fonts. If we change all font families to one 
> target, icons will disappear. Fonts used for special purposes as in 
> variables from science, technology, engineering and mathematics would 
> be changed without MathML markup. For example, the symbol font for 
> epsilon zero, in physics could change to e0. That would change the 
> meaning. Another example could be the use of Arial-Black for Matrix 
> names, *M*n,m. The symbol Mn,m would denote the (n, m) entry in 
> *M*n,m. These latter examples would be discipline specific font conventions.
>
> 3.  Programming practices that limit the ability to change font family.
> This
> can be as simple as using “important” in line or as complex runtime 
> font substitutions by third party vendors. These will need to be 
> collected and identified within techniques.
> *Conclusions*
>
> I think we have gotten as much feedback as we need to construct the SC 
> our users need with enough limitation to enable testability and 
> implementer tractability.  There will be gaps in the current 
> platforms, technologies and programming practices that we may not be 
> able to address now, however we can address then and use them to 
> construct reasonable procedures for authors and testers.

--
Laura L. Carlson


-- 
Laura L. Carlson

Received on Tuesday, 25 April 2017 18:57:02 UTC