W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > April to June 2017

Re: Proposal for moving COGA SC forward

From: Gregg C Vanderheiden <greggvan@umd.edu>
Date: Sun, 28 May 2017 13:38:02 -0400
Cc: Alastair Campbell <acampbell@nomensa.com>, Michael Cooper <cooper@w3.org>, Mike Pluke <Mike.Pluke@castle-consult.com>, "w3c-waI-gl@w3. org" <w3c-wai-gl@w3.org>
Message-Id: <C79F63D1-F093-41AA-B965-F566D3308127@umd.edu>
To: "lisa.seeman" <lisa.seeman@zoho.com>
I think you want the supplement to be something that always exists — and includes all the items IN 2.0 and 2.1 and all the other as well. 

The MASTER collection of ideas — not bounded by testability.    
So all of the things that are IN 2.1 would ALSO be in this document.    

So those sentences would not make sense. 

PS  (I think they would just make the Working group look lazy or it make it look like  2.1 is being released before it is ready.)    But mostly — those sentences don’t work because what is in 2.1 should also be in this doc so it is complete.  


g 

Gregg C Vanderheiden
greggvan@umd.edu




> On May 28, 2017, at 1:32 PM, lisa.seeman <lisa.seeman@zoho.com> wrote:
> 
> 
> How about this
> 
> Not all items could go into wcag 2.1 because the group did not have time to process at all the success criteria proposed by the cognitive accessibility task force. 
> 
> Some items might take considerable  time to do and some members of the working group did not feel that was appropriate  just to accommodate people with cognitive and learning disabilities.
> 
> Some items might take time to understand what to do and the group .......
> 
> Should I carry on?
> 
> 
> 
> All the best
> 
> Lisa Seeman
> 
> LinkedIn <http://il.linkedin.com/in/lisaseeman/>, Twitter <https://twitter.com/SeemanLisa>
> 
> 
> 
> 
> ---- On Fri, 26 May 2017 18:21:34 +0300 Gregg C Vanderheiden<greggvan@umd.edu> wrote ---- 
> that is a great idea Alastair
> with proper intro…
> 
> 
> How about something like this 
> 
> 
> 
> 
> Best Practice Checklist for the design of content for people with cognitive, language, and learning disabilities.   
> (short name   Checklist or  CLL Checklist  )      or some such for a title
> 
> (or checklist could be dropped along with checkboxes —and a separate checklist created from it.  I will leave the checklist/checkboxes in for now since they give a good flavor of ‘do them all’ rather than  ‘bunch of options’.  
> 
> 
> Introduction 
> 
> The following are best practices that have been identified for consideration in designing pages that will possible or easier for people with cognitive, language, and learning disabilities to understand and use.
> 
> 
> Not all items can be applied on all web pages, but implementing as many as you can will help users with cognitive, language, and learning disabilities and all are important for some people. 
> 
> Some items might conflict with others if applied on a particular web page - but techniques for implementation to avoid conflicts in different applications are being continually developed.  If you think things conflict - see the techniques. If you don’t see a solution - send a note to the working group so it can be examined and new techniques documented.
> 
> Not all items in checklist are testable — but much good practice is not testable and the attempt in this document is to capture all of what is know rather than just what is testable or always applicable
> 
> These are organized under same general categories as WCAG to facilitate use by those familiar with the WCAG.   Additional guidelines are added where needed to better group the items.   
> [We can revisit if this is a good idea after all the CheckList items are gathered. for example if 80 % fall under UNDERSTAND then we might want to re-look at this rather than force an awkward re-distribution.  but if it works - I think this organization would be helpful]
> 
> The relevant SC from WCAG are included here so that this list is complete.   
> NOTE: the numbering of the Best Practices are NOT the same as the numbering WCAG beyond the GUIDELINE livel.  
> 
> 
> PERCEIVABLE 
> 
> GUIDELINE 1:  
> 
>  [   ]  Best Practice 1a.   kldfjaldfjaldkfjasldkfjaslfjasd  
> 
> 
> 
> UNDERSTANDABLE 
> 
> GUIDELINE 
> 
> [   ]  Best Practice  3a    kajdf;ajdflaksdjflakdjf
> 
> [   ]  Best Practice  3x    [WCAG 3.4]   <text of Wcag 3.4>
> 
> 
> 
> something like that? 
> 
> 
> 
> g 
> 
> Gregg C Vanderheiden
> greggvan@umd.edu <mailto:greggvan@umd.edu>
> 
> 
> 
> 
> On May 25, 2017, at 7:18 PM, Alastair Campbell <acampbell@nomensa.com <mailto:acampbell@nomensa.com>> wrote:
> 
> Michael Cooper wrote:
> I've been thinking of the "pillars" as success criteria.... [but] they do indeed look more like guidelines than SC... But the problem with guidelines is, we have to have SC under them.
> 
> I think we need things that are specific 'checks' but are not SCs.
> 
> So still use Principle > Guideline > [Something]
> 
> In old-school usability terms, these would be 'heuristics', which are more about 'appropriateness'  than an SC. But heuristics isn't a very good term, perhaps 'checks'?
> 
> Mike, any suggestions from other standards?
> 
> For example, Plain language could be framed as something like (and this is off-the-cuff):
> 
> [Guideline] Use plain language for important information.
> 
> [Check 1] Double negatives are not used to express a positive statement.
> [Check 2] Words, phrases or abbreviations that are the most-common form for the concept.
> 
> There would be quite a bit of work to re-categorise things, but perhaps less than the current approach.
> 
> Cheers,
> 
> -Alastair
> 
> 
> 
> 
Received on Sunday, 28 May 2017 17:38:44 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 28 May 2017 17:38:45 UTC