Re: I will vote against WCAG 2.1 Draft

>Incomplete Candidates" ?

It could be something like this.

<h2>Incomplete Candidate Success Criteria</h2>
<p>The following are success criteria proposals by the task forces that
have been identified to address important accessibility barriers on the
web. However, they have not yet met one or more of the <a href="
https://www.w3.org/WAI/GL/wiki/WCAG_2.1_Success_Criteria>requirements for a
success criteria. </a> We are seeking suggestions on how they can be worded
so that they are testable, implementable, apply to all content, and apply
across all technologies (or how to manage exceptions).

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 Mon, Feb 20, 2017 at 2:46 PM, John Foliot <john.foliot@deque.com> wrote:

> "Incomplete Candidates" ?
>
> JF
>
> On Mon, Feb 20, 2017 at 1:41 PM, Gregg C Vanderheiden <greggvan@umd.edu>
> wrote:
>
>> I don’t like the  “at risk”  title
>>
>> That sounds like they are IN  but there is a risk they will fall out.
>>
>> The ones described are not in — and we don’t know how to get them in
>>  (yet)  —   and we are asking for ideas.
>>
>> perhaps call them
>>
>> *Other things we are exploring that do not (yet) qualify as Success
>> Criteria for the reasons listed for each*
>>
>> Gregg C Vanderheiden
>> greggvan@umd.edu
>>
>>
>>
>> On Feb 20, 2017, at 1:36 PM, Katie Haritos-Shea GMAIL <ryladog@gmail.com>
>> wrote:
>>
>> +1 to Greggs comments, which could be in the ‘At Risk’ (or some such
>> name) section……
>>
>> ​​​​​** katie **
>>
>> *Katie Haritos-Shea*
>>  *Principal ICT Accessibility Architect (WCAG/Section 508/ADA/AODA)*
>>
>> *Cell: 703-371-5545 <(703)%20371-5545> **|* *ryladog@gmail.com*
>> <ryladog@gmail.com> *|* *Oakton, VA **|* *LinkedIn Profile*
>> <http://www.linkedin.com/in/katieharitosshea/> *|* *Office: 703-371-5545
>> <(703)%20371-5545> **|* *@ryladog* <https://twitter.com/Ryladog>
>>
>> NOTE: The content of this email should be construed to always be an
>> expression of my own personal independent opinion, unless I identify that I
>> am speaking on behalf of Knowbility, as their AC Rep at the W3C - and -
>> that my personal email never expresses the opinion of my employer, Deque
>> Systems.
>>
>> *From:* White, Jason J [mailto:jjwhite@ets.org <jjwhite@ets.org>]
>> *Sent:* Monday, February 20, 2017 1:28 PM
>> *To:* Gregg C Vanderheiden <greggvan@umd.edu>; David MacDonald <
>> david100@sympatico.ca>
>> *Cc:* Wayne Dick <wayneedick@gmail.com>; w3c-waI-gl@w3. org <
>> w3c-wai-gl@w3.org>
>> *Subject:* RE: I will vote against WCAG 2.1 Draft
>>
>> +1 to Gregg’s comments, which are in line with how the working group has
>> historically operated in publishing drafts.
>>
>> *From:* Gregg C Vanderheiden [mailto:greggvan@umd.edu <greggvan@umd.edu>]
>>
>> *Sent:* Monday, February 20, 2017 1:26 PM
>> *To:* David MacDonald <david100@sympatico.ca>
>> *Cc:* White, Jason J <jjwhite@ets.org>; Wayne Dick <wayneedick@gmail.com>;
>> w3c-waI-gl@w3. org <w3c-wai-gl@w3.org>
>> *Subject:* Re: I will vote against WCAG 2.1 Draft
>>
>> I do not agree that you we should release SC for public comment that do
>> not meet the criteria for an SC.
>>
>> if they do not qualify — they are not SC.
>>
>> If we want to release those that DO qualify
>> AND ALSO get help on other ones that DON’T YET
>>
>> Then we could have an *additional* *section below *the ones that qualify
>>  that says.
>>
>>    - the following are things we would like to see but they do not
>>    qualify for the reasons stated under each one.
>>    - if people know of ways to modify these so they would qualify - we
>>    would much like to see your ideas
>>
>>
>>
>>
>> X1:  SHORT NAME OF #1:    Text of the thing we would like to make into an
>> SC
>>
>>    - reason #1  — and why               [ For example       * Not
>>    testable — because it contains the phrase  “must be easy” but “easy” is not
>>    a testable term ]
>>    - reason #2 (if there are more than 1) — and why       [ example
>>    *Not broadly applicable — because this can only be met by markup languages ]
>>
>>
>>
>> X2:  SHORT NAME OF #2:  text of 2
>>
>>    - reason #1 - and why
>>
>>
>> etc
>>
>>
>> That way we
>>
>>    1. don’t make it look like we can include things we can’t — and then
>>    disappoint people when we drop all the ones we can’t
>>    2. we get people who want them in there to give us their best effort
>>    in getting them into shape
>>
>>
>>
>> Gregg
>>
>>
>>
>> Gregg C Vanderheiden
>> greggvan@umd.edu
>>
>>
>>
>>
>> On Feb 20, 2017, at 12:36 PM, David MacDonald <david100@sympatico.ca>
>> wrote:
>>
>> While I agree that there has not been complete WG consensus for 23 of the
>> 25 new SCs, I would also say that the Task forces worked hard on the SCs
>> that were submitted as issues, and by their submission as Issues, it means
>> they had consensus of at least the task forces that created them.
>>
>> I was against the idea of releasing working drafts on a set schedule, but
>> since the group made that decision, then I support the group consensus to
>> do so.
>>
>> Although there are a number of SCs which do not meet all the requirements
>> for SCs, I think we should go forward and see what the public says.
>>
>> The other option is to wait about 9 months so that we can vet 60 success
>> criteria at a rate of 2 per week. And I don't think they will be that much
>> better at that point... and if a many  of the 60 SCs are rejected by the
>> public after the FPWD we will be 9 months behind.
>>
>> I think the current disclaimer language strikes a good balance between
>> saying this is the best of our work so far, and it still has a long way to
>> go, and it gives the public a chance to look over our shoulders before
>> everything is baked in.
>>
>> Cheers,
>> David MacDonald
>>
>> *Can**Adapt* *Solutions Inc.*
>> Tel:  613.235.4902 <(613)%20235-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 Mon, Feb 20, 2017 at 11:47 AM, White, Jason J <jjwhite@ets.org> wrote:
>>
>>
>>
>>
>> *From:* Wayne Dick [mailto:wayneedick@gmail.com]
>> *Sent:* Monday, February 20, 2017 11:30 AM
>> Let me clarify. Only one or two members of the LVTF could participate in
>> the discussion on github because the interface is not accessible and we
>> were given no instructions on how to participate in an alternative format.
>>
>> The 2.1 document is pretty good. I will vote for it if the document if it
>> is made clear that members with the Low Vision Task Force could not
>> participate in the discussion, and therefore, the effected  parties are not
>> present in the discussion.
>> *[Jason] Wayne’s last comment clarifies his concern. It echos my own
>> concern that this draft is destined to include proposals which have not
>> undergone thorough review and development by the working group, and which
>> have not been deemed by consensus as suitable for inclusion in the
>> document. “Suitable for inclusion” does not mean finished or without
>> problems – but it should entail some degree of review and oversight,
>> together with a formal decision to include each of the proposals, or to
>> include it with a specific note identifying issues remaining to be
>> addressed.*
>> *The draft already admits these facts. It admits, furthermore, that only
>> two of the proposals achieved some degree of consensus regarding their
>> inclusion. I think it sends a poor signal to the public about this working
>> group’s internal processes, as Katie intimated in her comment last week.
>> Now, Wayne proposes to attach a note stating that some Task Force
>> participants were unable to engage in wider working group review and
>> development of proposals after they were submitted – again, very bad from a
>> messaging point of view, and not a good reflection of how the process needs
>> to work if it is ultimately to deliver a W3C Recommendation.*
>>
>>
>> ------------------------------
>> This e-mail and any files transmitted with it may contain privileged or
>> confidential information. It is solely for use by the individual for whom
>> it is intended, even if addressed incorrectly. If you received this e-mail
>> in error, please notify the sender; do not disclose, copy, distribute, or
>> take any action in reliance on the contents of this information; and delete
>> it from your system. Any other use of this e-mail is prohibited.
>>
>> Thank you for your compliance.
>> ------------------------------
>>
>>
>>
>>
>>
>> ------------------------------
>>
>> This e-mail and any files transmitted with it may contain privileged or
>> confidential information. It is solely for use by the individual for whom
>> it is intended, even if addressed incorrectly. If you received this e-mail
>> in error, please notify the sender; do not disclose, copy, distribute, or
>> take any action in reliance on the contents of this information; and delete
>> it from your system. Any other use of this e-mail is prohibited.
>>
>>
>> Thank you for your compliance.
>>
>>
>>
>
>
> --
> John Foliot
> Principal Accessibility Strategist
> Deque Systems Inc.
> john.foliot@deque.com
>
> Advancing the mission of digital accessibility and inclusion
>