Re: Adapting Text proposals for next week's survey. (was Re: Adding Greg L's Adapting Text proposals to the Wiki in anticipation of a vote between J&K and H&I)

> When the following author-specified text properties can be changed, the
change does not result in a loss of essential information or functionality:

H
​ow can this work?​ The author in this text has to support every changeable
property for every possible combination and ensure everything works fine.
what if the user picks black on black... there will be a loss of
functionality... but even if we plug that hole... its way too much to
support 256,000,000 colors for both foreground/background, and hundreds of
fonts.

I think we have to go with some sort of "C" or "G".



Cheers,
David MacDonald



*Can**Adapt* *Solutions Inc.*

Tel:  613.235.4902

LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>

twitter.com/davidmacd

GitHub <https://github.com/DavidMacDonald>

www.Can-Adapt.com <http://www.can-adapt.com/>



*  Adapting the web to all users*
*            Including those with disabilities*

If you are not the intended recipient, please review our privacy policy
<http://www.davidmacd.com/disclaimer.html>

On Fri, Apr 14, 2017 at 4:43 PM, Andrew Kirkpatrick <akirkpat@adobe.com>
wrote:

> Maybe I’m missing something but I don’t see the word “it” in J&K. No
> matter, I think that this captures what we were talking about at the end of
> the call…
>
> Here’s the proposed versions with a few edits:
>
> (A or AA)
> When the following author-specified text properties can be changed, the
> change does not result in a loss of essential information or functionality:
>
>    -
>    - font family
>    - text color and background color
>    - line spacing (leading)
>    - letter spacing (tracking)
>    - word spacing
>
>
> (AAA)
> A mechanism is available to achieve the following text customization (except
> for images of text and captions):
>
>    - font family can be selected by the user
>    - text color and background color can be selected by the user
>    - line spacing (leading) can be set to at least 1.5
>    - letter spacing (tracking) can be set to at least 0.12 em
>    - word spacing can be set to at least 0.16 em
>
>
> I believe that the key question we need to have answered is whether we
> want:
>
>    1. A split between a “A” version and a “AAA” version where the basis
>    of the split is that in the “A” version the intent is to avoid disruption
>    when it is possible to change text properties, and in the “AAA” version the
>    intent is to require that the user can change the text properties and when
>    they do that disruptions are avoided. This means that in the new Gregorian
>    document format that has non-existent support for text customization the
>    content will pass essentially automatically, but in a format where the user
>    has the ability to change these properties that the author needs to verify
>    that the content still works.
>    2. Essentially make the AAA item above the basis for a A/AA SC.
>
>
> I’m concerned that testing the “A” version will require that we set
> parameters on the items. I don’t think that this is a problem for anything
> except for the font family. All of the other items either don’t impact the
> visual layout or provide a testable range, but there is so much variability
> in font characteristics that we would essentially be requiring a nearly
> unlimited scope, and that is a problem. We could say “any three different
> fonts", but then we could have people only testing with the tiniest fonts.
>
> I think that we should go with Greg’s A/AAA above (I like my edits, but up
> for discussion) and we should remove the font family from the “A” version.
>
> What do people think?
>
> Thanks,
> AWK
>
> Andrew Kirkpatrick
> Group Product Manager, Accessibility
> Adobe
>
> akirkpat@adobe.com
> http://twitter.com/awkawk
>
> From: Gregg Vanderheiden <greggvan@umd.edu>
> Date: Friday, April 14, 2017 at 15:50
> To: Laura Carlson <laura.lee.carlson@gmail.com>
> Cc: David MacDonald <david100@sympatico.ca>, Joshue O Connor <
> josh@interaccess.ie>, Andrew Kirkpatrick <akirkpat@adobe.com>, Greg
> Lowney <gcl-0039@access-research.org>, Jim Allan <jimallan@tsbvi.edu>,
> WCAG <w3c-wai-gl@w3.org>
> Subject: Re: Adapting Text proposals for next week's survey. (was Re:
> Adding Greg L's Adapting Text proposals to the Wiki in anticipation of a
> vote between J&K and H&I)
>
> On Apr 14, 2017, at 12:14 PM, Laura Carlson <laura.lee.carlson@gmail.com>
> wrote:
>
> Hi Gregg,
>
> Replies inline
>
> just replace  IT with what IT means.
>
>
> Can you suggest text that everyone can live with?
>
>
> I don’t have the language in front of me — but what do you mean by IT?
> Just put that in place of the word
>
>
> Lets' find out what happens with Proposal L&M on the survey.
>
>
> I think we are slipping backwards.  I thought we resolved this before but …
>
>
> the language
> Except for images of text and captions, text styles of the page can be
> overridden as follows with no loss of essentialcontent or functionality.
> assumes that all technologies allow this -  and therefore outlaws all
> technologies that do not.
>
> So anything that doesn’t have style sheets or similar mechanism will not be
> able to conform to 2.1?
>
> or am I missing something?
>
>
> As Bruce pointed out, it goes to accessibility support.
>
>
> That is not the meaning of accessibility support.      If the * author*
> cannot do it because there *is no way* to do it *with the technology*
> they are using — then it means that the author cannot use that technology
> and conform to WCAG 2.1.       So that means 2.1 is in effect *barring*
> use of a technology.
>
> We tried to not create SC that could not be met with all major
> technologies used in Web pages today.
>
> That is all I am saying.
>
>
>
> This goes back to my statement that we should have *NO new SC* that we do
> not *also have sufficient techniques for * - at least for the
>
> perhaps we should add that as a requirement for new SC.
>
> there have to be sufficient techniques for the SC for all major web
> technologies.   (
> *that is — if WE don’t know how to create conforming content for the major
> technologies — we should require that others do it. *
>
>
> This was one reason that WCAG 2.0 took so long.  Because the WG checked
> its work and confirmed it was doable before releasing.    Lot of work but
> it really paid off.  We found so many things / errors / problems when we
> actually tried to apply all our great advice as requirements.
>
>
> ciao
>
>
> Gregg
>
>
> Gregg C Vanderheiden
> greggvan@umd.edu
>
>
>
> On Apr 14, 2017, at 12:14 PM, Laura Carlson <laura.lee.carlson@gmail.com>
> wrote:
>
> Hi Gregg,
>
> Replies inline
>
> just replace  IT with what IT means.
>
>
> Can you suggest text that everyone can live with?
>
> Lets' find out what happens with Proposal L&M on the survey.
>
>
> I think we are slipping backwards.  I thought we resolved this before but …
>
>
> the language
> Except for images of text and captions, text styles of the page can be
> overridden as follows with no loss of essentialcontent or functionality.
> assumes that all technologies allow this -  and therefore outlaws all
> technologies that do not.
>
> So anything that doesn’t have style sheets or similar mechanism will not be
> able to conform to 2.1?
>
> or am I missing something?
>
>
> As Bruce pointed out, it goes to accessibility support.
>
> Kindest regards,
> Laura
>
> --
> Laura L. Carlson
>
>
>