Re: Extension conflict/compatibility requirement

the link to the full techniques document is at https://rawgit.com/w3c/coga/master/techniques/index.html, as you can see there is a lot we could do to make these techniques human testable, (at least per language).




Also can we cc the task force (public-cognitive-a11y-tf@w3.org), or should we shield them a bit until we have some united comments?


All the best
Lisa




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