Re: Extension conflict/compatibility requirement

Hi Gregg

When I met with WCAG (I think it was at the last FTF) it was agreed that we could change these rules/restrictions in the extensions. If WCAG decide to go back on that then we should have that as a separate and serious discussion. (Personally I thought the decision was the right  one.) 


We do need to be careful not to go back on these discussions too many times as each time it involves large changes to all the work done so far.



All the best

Lisa Seeman

Athena ICT Accessibility Projects 
LinkedIn, Twitter





---- On Mon, 26 Oct 2015 05:33:54 +0200 Gregg Vanderheiden<gregg@raisingthefloor.org> wrote ---- 

Hi Lisa,

Thanks for the comments and feedback


1. In extensions we do not have to be bound by the same definitions as we were in WCAG 2.0








You can check with W3C but I don’t think you can have something be an extension of WCAG and be called a ‘success criteria’ and not have it be testable.    I don’t think "success criteria” can have two completely different definitions within the same family (WCAG) of documents.   


And you can’t conform to any standard if you can’t test whether you have met the provisions of the standard.      So unless they are testable there isnt anyone that can require them.  How would they know if they were met?  (and more to the point, how would the author even know if they were met?) 


These limitations were put on because of policy makers who needed WCAG 2.0 to be as testable 





No policymakers put any constraints on WCAG 2.0.    What went in was purely up to the Working Group — and bound only by the standards of the W3C and the basics of standards development in general.  And standards work in general requires that the normative provisions in a standard be testable. 


RE Not following the same form at WCAG


     I think that is fine and in fact I think that is good and necessary.   That will allow you to go beyond what was possible in WCAG.   But you can’t use the same terminology and create new definitions for them.  


So your use of techniques is fine - and creating new techniques both for your document and for WCAG is great. 


And creating new Guidelines (which are not normative in WCAG and are general guidance) is also fine. 


But I don’t think you can or should use the term Success Criteria  in an extension to WCAG when it does not mean the same thing as a Success Criteria  (and it isn’t actually a criteria but guidance).  


So keep going forward - this is great stuff.   But drop the use of the term Success Criteria unless it is indeed
testable  (so it qualifies as a criteria) 
applies to all types of content (as limited by the SC )    This includes simple sites as well as sites like  the National Science foundation,  medical websites,  an online physics course,  the online repair manual for a nuclear resonance imager, etc.  (Unless the SC or the overall guidelines are defined as applying only to certain types of sites )





2. This is a first, early draft, -not even an editors draft-  and it is back up with many techniques in the techniques document, many of which can be testable the SC testable.




Don’t follow you here.   In WCAG the SC say what should be accomplished but not how to do it specifically.     The techniques are WAYS of meeting the SC.     Having a technique be testable doesnt make it a success criterion.      Not everything that is testable is a Success criterion.    and you don’t want to have something be a success criterion if there is another way to achieve the same result.   That would mean that you are requiring things to be done a certain way when another way is just as good. 


So success criteria actually have another requirement (remember I said there were more than two)
it must be testable
it must apply to all content that the guidelines (or the SC) are scoped to cover
it must not require things to be done a certain way when the same result could be achieved another way
(in that case the “result” is the SC and the “ways” are alternate techniques for achieving the result


 (Such as - enable adaptability). 




The challenge will be in seeing if you can make  this testable?    Exactly how much adaptability is ‘enough’ adaptability to pass?     How much is not enough?   How do you measure it.  

We could decide at this point what we want to aim for in a second pass, such as more active language or more prescriptive and testable instructions.




Remember testability is only one criterion.  Many techniques are testable and they are not SC. 


(not sure what you mean by Active Language.   all the SC are pretty passive.     They are statements of fact - that must be true.     “All non-text content is blah blah blah” )

 At this point I believe it is premature to thouw out anything as not being testable,




AGREE !!   Do not throw anything out.   


Just don’t call it a success criterial 

 because, if we decide to make testability a criteria for this extension, we should first strive to make it testable. However I would vote that testability, and things being appropriate across the board should be an aim not a requirement.




Agree.  If you make testability the goal of the document you will have all the same limitations as WCAG. 

 If doctorate works is not fully accessible for COGA, so be it.




Actually all content no matter what you do will not be accessible to some people with some degrees of cognitive disability — unless you are going to have a cut off where you don’t worry about anyone below that level.   Cognitive disability goes all the way to zero cognitive ability. 


So you have both websites that can’t meet your guidelines — and people who can’t use websites that do. 



Best 







gregg


----------------------------------
Gregg Vanderheiden
gregg@raisingthefloor.org




 
 
On Oct 25, 2015, at 4:10 PM, lisa.seeman <lisa.seeman@zoho.com> wrote:

Hi Gregg

Two comments
1. In extensions we do not have to be bound by the same definitions as we were in WCAG 2.0
These limitations were put on because of policy makers who needed WCAG 2.0 to be as testable  as possible  and applicable across all web content so they could be adopted across the board. However we do not need to limit extensions for the same considerations. Let policy makers decide if they want to include an extension and in what scope. Our mandate can be simply to provide the guidance for people who want to include people with cognitive disabilities.


2. This is a first, early draft, -not even an editors draft-  and it is back up with many techniques in the techniques document, many of which can be testable the SC testable. (Such as - enable adaptability). We could decide at this point what we want to aim for in a second pass, such as more active language or more prescriptive and testable instructions. At this point I believe it is premature to thouw out anything as not being testable, because, if we decide to make testability a criteria for this extension, we should first strive to make it testable. However I would vote that testability, and things being appropriate across the board should be an aim not a requirement. If doctorate works is not fully accessible for COGA, so be it.












All the bestLisa SeemanAthena ICT Accessibility Projects LinkedIn, Twitter










---- On Sun, 25 Oct 2015 21:35:10 +0200 Gregg Vanderheiden<gregg@raisingthefloor.org> wrote ---- 

Thanks Laura,

This is very helpful


Here it the problem/question I am having with the use of the word  Success Criteria 
I looked over the document and I saw lots of techniques and general advice — but nothing that would qualify as a success criteria. 


A success criteria would be a testable statement about the Web content - that can apply to all web content (as qualified in the SC). 




For example


“Use a clear structure”  
is advice (or a command)  but not a success criteria.
as a success criteria it might be worded  “Content uses a clear structure”  
except that isn’t testable.  
What does clear structure mean exactly for all types of content?
Would most everyone agree for each page whether the structure was clear or not?  
If not it can’t be a criterion for success. 



I love the document — it is full of great techniques and can provide a lot of valuable guidance in how to make things more accessible to not only people with cognitive disabilities but everyone.   
But I think you are running into the same problem that the WCAG WG ran into with WCAG 2.0


There are lots of things to talk about or provide advice on.    But there is little that 
a) applies always on all web pages   (including the National Science foundation,  medical websites,  an online physics course,  the online repair manual for a nuclear resonant imager, etc. ) or else have clear unambiguous criteria for what is excluded from the requirement) 
b) is objective enough to be testable  (most people rating something independently would come up with the same answer) 


This is what drove us crazy in trying to define SC in this area and find thing that there was consensus on as being  testable, and applicable across we pages.   (These arent the only criteria for SC but they are the ones that stopped us the most. 




Maybe I missed one or two in the document — that would qualify (if I did let me know) .     But most (or all?)  of the things listed as SC  - can’t qualify.     


They are all good advice.  But not




I think it is important to not label things as SC that don’t qualify.   It really confuses the discussion - and will only create stuff that needs to be reworked later.  




PS - I also saw that some provisions were recommended to be moved from level AAA to higher levels.   The one exception we did make (in order to include more cognitive SC) was to put some things into Level AAA that did not apply to all web content.  We clearly mentioned that in the WCAG (that some things in level AAA could not be applied to all websites) and recommended that level AAA never be universally required for that reason.    For that reason - those items also could not be moved to higher levels because they do not meet the full SC criteria. 




Good luck on this.   This is a critical area — but it is very hard to find things that qualify as SC.    I think a better route is to focus on creating a “Design Guidelines for making web content more accessible to people with cognitive, language, and learning disabilities”     and make it a ‘how to’ rather than a standard - which will just tie you up in knots like it did the WCAG WG working on WCAG 2.0 — because a standard can only have objective testable criteria  for conformance — and ones that always apply (or always apply as qualified) —  and we  don’t know how to do that for most all of the good advice that we have for making things accessible to this important group of groups of users. 


 
gregg


----------------------------------
Gregg Vanderheiden
gregg@raisingthefloor.org




 
 
On Oct 25, 2015, at 11:37 AM, Laura Carlson <laura.lee.carlson@gmail.com> wrote:

Hi Gregg,

On 10/21/15, Gregg Vanderheiden <gregg@raisingthefloor.org> wrote:

Where is there  a list of the actual SC we have so far for
any extensions? I  went though the docs and there were
lots of places where there was a title that said Success
criteria X  but then there was no SC below it. Just general
advice or techniques.

How many do we have?

The COGA TF has a first draft of an extension proposal [1] for the
full WCAG working group to review via survey [2]. The draft currently
has 11 proposed Success Criterion.

1. Enable adaptability
2. Timed event should be avoided
3. Use a clear structure
4. Use clear visual affordances
5. Use a clear writing style
6. Minimize the cognitive skills required to use the content when
there is an alternative that achieves the same ends
7. Be predictable
8. Provide rapid and direct feedback
9. Help the user understand the content
10. Help users complete and check their work
11. Help the user maintain attention

Kindest Regards,
Laura

[1] https://www.w3.org/WAI/PF/cognitive-a11y-tf/wiki/Proposal_for_WCAG
[2] https://www.w3.org/2002/09/wbs/35422/cogaextreview/

--
Laura L. Carlson