Re: Call for Review: Requirements for WCAG 2.0 Extensions - First Public Working Draft

Apologies for being late 

I wrote this a week ago - then let it sit to think about it but forgot to sent it.   Found it this weekend. 

Hope it isnt too late.  (or too long) 



First I want to say that you did an excellent job on the document - and on thinking through the criteria and elements involved in creating an extension and any new SCs.      I sent a comment  to the chairs earlier before formal comment period, commending the group on its work. 

The only concerns I have (and I THINK they are very important ones) are 

that the preamble (and document ) are written in such a way that there is the expectation all the criteria will be met and that extensions will be created.   A lot of good work has been done — but it is very hard to create SC that meet the criteria.  It might be that something other than an extension will turn out to be the most useful to the field.  This should be acknowledged I think.

There is such a focus on creating SC that the other great work of the task forces is being overlooked.  There is so much good advice and technique and ideas that are not necessarily always applicable (as an SC would require)  — but that should be applied where they do apply and can be applied practically. 

Don’t overlook all that is in WCAG already in these areas. 



RE: about too great an expectation on there being extensions. 

Too much expectation can lead to a mission, or feeling of mandate to create one, such that, if the criteria in your requirements document are not met, there will be a tendency to push things beyond the criteria in order to succeed and meet the expectation of an extension. 

The working group that created WCAG 2.0 spent immense time on these same topics and was not able to identify any additional SC that could make the SC test.   And members of it spent a LOT of time considering mobile, touch and cognitive areas.  



RE: OVERLOOKING GREAT WORK - BECAUSE IT ISNT AN SC

I have been following the work - and there is a lot of good work represented.  But for something to be a new SC it needs to be testable (so you can tell when you pass), apply everywhere to all types of content (after qualification) so that they can be generally required, etc.     

My concern is that, in an attempt to create an extension (which requires SC) the great work that is being done, that is compiling what can be done to enhance accessibility in all these areas  - can either be lost - or be felt to be second class to Success Criteria.     In addition, if we focus on SC, and testability and general applicability, we will fall victim to the same limitations that the WCAG 2.0 group had to work with.   They had no choice but to focus on testable SC.   But the current Working Group does have a choice - and can instead focus on great documents that do not limit themselves to testability that an extension would require, and instead focus on providing a solid application guide that focuses on really helping a developer understand what the problem(s) are, what the different techniques are, and how to apply them wherever possible. 



RE: DON’T OVERLOOK WHAT IS IN WCAG ALREADY

RE COGNITIVE:  The working group spent more time on cognitive than any other disability (and perhaps all the other disabilities).  And there are many provision that relate to cognitive, language, and learning disabilities.   To recognize all of them though it is important to understand that there are two types of access. 
Direct Access — where the provision makes the content more accessible directly - without AT.    There are 26 Success Criteria relate to direct access.  9 relate to built-in voicing of displayed content  (non-screen reader voicing). 17 others related to other types of direct access by people with CLL disabilities
Access via AT —  where the provision makes sure all content is accessible to Assistive technologies.   25 Success Criteria make it easier to use ICT with Assistive technologies.  When we compiled WCAG 2.0, there was little in the way of cognitive AT and there is still only limited CogAT today.   But we are now coming on a time when cognitive AT is becoming possible — and all the work to ensure the AT could get access to the information on the page can come to fruition.    However — the computer scientists need to know WHAT WILL MAKE PAGES EASIER TO UNDERSTAND.  We can’t create CogAT if we don’t know what it should do. This should be a major focus of the Task Force work.    Not what the author must do (because quite frankly - it is very different for different types and degrees of cognitive, language, and learning disabilities).   Rather we should define what different forms the AT should change a page into for each of the different types and degrees of cognitive, language, and learning disability.
NOTE ALSO That 
11 others relate to video description -   (which helps people with some types of cognitive disabilities to understand what they are seeing)
11 are general that apply to all disabilities  (Vision, Hearing, Physical, CLL) (e.g. documents are accessible, support is accessible, etc.)
CogAT is the best hope for making pages take all the different forms, and have all the different levels of complexity needed by all the different people with different levels of cog disability.    We do NOT  want to make pages all be designed for the lowest common denominator or people with the most severe levels of the different cognitive, language, and learning disabilities.    Too much information would be lost to those with moderate levels.      The ONLY way to really address this is to 
create pages that can be changed into the different types and levels needed (i.e. that CogAT can read/ understand -   that are programmatically determinable) 
create AT that understand these pages and re-present them to all the different people with different types and levels of cog disability
And to do that we need to 
FIGURE OUT WHAT MAKES PAGES EASIER TO USE / UNDERSTAND FOR ALL THE DIFFERENT PEOPLE
DOCUMENT THAT FOR THE FUTURE COG-AT DEVELOPERS - who are just now getting new tools needed to address this area.


RE MOBILE: 
mobile came on strong while WCAG was being developed  — and all of the provisions were examined for coverage of mobile.  In fact WCAG was cited as the best guidelines for mobile back then.  There are now additional mobile guidelines - but much time was spent trying to ensure that mobile accessibility aspects were covered.  There are new input techniques that can make things simpler for some users - but they shouldnt be confused with generic input that can support many different input approaches including gesture. 
RE GESTURES:
gestures were examined and found, like voice input, to be great additional input techniques, but not something that should be required or that could replace the essential 2 provisions for adaptability (text that allowed presentation of information in any modality,  and encoded (keyboard interface) that allows could allow for control via any modality (selection, scanning, voice, gesture, brain, etc.) 
Gestures are wonderful additions - but not everything can support gestures
and gestures are NOT sufficient to replace “keyboard interface” requirement.  Not all people can gesture (elders, physical disabilities).    And gesture cannot allow control via non-gesture modalities like encoded input can  (aka keyboard interface).    Think of encoded input as the universal neutral input format - in the same way that encoded text output is the universal neutral output format. 




So my recommendations are 

Add to the introduction something that says in effect    ‘ these are the rules and constraints for creating an extension.   We don’t know that we will in fact be creating extensions - but it was felt we should clearly define what was involved if we are to examine this approach and determine if an extension is needed and possible’
  
Step back, and focus on “What will make web sites more accessible to  _______________” (mobile, cognitive, touch devices).  Don’t think about testability or universal applicability.   Think about all the things that can help individuals.  Write something to help readers really understand the problem.    (Why isnt zoom good enough.  Why is responsive design and text that enlarges and wraps so helpful.  Don’t tell me I must do things. Help me really understand why this or that is important.  What is the problem.  Why is this so much more effective for a person with that situation.  I can create cognitive AT that can change a page into different forms for different people,  what should I/it do for each different type/degree - and why? ) 

If advice appears that is clearly testable and universally applicable etc,  then see if it warrants an extension.

If not — then you will still have a great document - and one that does what WCAG could not do.   That puts that creates an integrated document that helps people both understand what the issues are —and the strategies for solving them - and that integrates side by side, both the testable and non-testable strategies, both the universally applicable and the only sometime applicable strategies/techniques, and paints a cohesive picture and tutorial for making things more accessible that is not limited in the ways WCAG was. 


Good luck on your work.  It is REALLY hard.   But it is also really needed. 


Gregg