Language to attach to SCs that are not mature yet for FPWD.

*Jason said*
* >>also agree with Gregg that the problems identified with proposals
should be noted (e.g., it isn’t reliably testable in its current form, it
might not apply to all Web content, it’s too vague/ambiguous as written,
etc.).*

I think that's a good idea. We could have standard notes to add to the
identification using the language from the SC requirements. Here is a
suggested
​start on a ​
library of these comments:
​==============​

- In it's current form, the proposal may not address a situation where a
user with a disability will be disproportionately disadvantaged (as
compared to a user without a disability) if the criteria is not met?
Suggestions from the public on how to improve it are welcome.

- In it's current form, the proposal may not be reliably testable either
through human testing or automated testing? Suggestions from the public on
how to improve it are welcome.

- In it's current form, the proposal describes the method to address the
criteria.
​Success Criteria should describe the ​
the specific
​passing ​
condition required to meet the criteria
​. ​
Suggestions from the public on how to improve it are welcome.

- In it's current form, the proposal does not apply across technologies.
Suggestions from the public on how to improve it are welcome.

- In it's current form, the proposal is creating a requirement for
something that is already required by an existing Success Criterion. [See
SC XXXX] . Suggestions from the public on how to improve it are welcome.

- In it's current form, the proposal may not be implementable, using
readily-available formats, free (or low cost) user agents, and/or assistive
technologies
​ that are available today​
. Suggestions from the public on how to improve it are welcome.

​================​


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 6, 2017 at 10:51 AM, White, Jason J <jjwhite@ets.org> wrote:

>
>
>
>
> *From:* lisa.seeman [mailto:lisa.seeman@zoho.com]
> *Sent:* Sunday, February 5, 2017 3:05 PM
>
> Can we have  any "at risk" SC  placed in the draft in the main section
> with an editors note with the issues that need to be addressed. I do not
> think they should be a separate "at risk " section.
>
> *[Jason] I thought the prevailing view was that “at risk” wouldn’t be the
> right concept to use at this early stage of development.*
>
> *I don’t mind how the editors decide to distinguish proposals that are
> known to be problematic from those which are on track for inclusion, but I
> think the distinction should be drawn in the draft so that reviewers can
> comment and, potentially, help by suggesting solutions. I also agree with
> Gregg that the problems identified with proposals should be noted (e.g., it
> isn’t reliably testable in its current form, it might not apply to all Web
> content, it’s too vague/ambiguous as written, etc.).*
>
>
>
> ------------------------------
>
> 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.
> ------------------------------
>