W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > October to December 2006

RE: Task Approach to conformance.

From: John M Slatin <john_slatin@austin.utexas.edu>
Date: Mon, 23 Oct 2006 15:08:44 -0500
Message-ID: <6EED8F7006A883459D4818686BCE3B3B03A8F8AD@MAIL01.austin.utexas.edu>
To: "Paul Walsh, Segala" <paulwalsh@segala.com>, "Gregg Vanderheiden" <gv@trace.wisc.edu>, <w3c-wai-gl@w3.org>
OK, I'll bite, though I'm not sure how much I can chew.
 
Gregg writes:
<blockquote>
* There will probably be endless arguments about tasks.  What is a task,
what is not a task, whether information presented on a page is a task or
whether
tasks are only things you do.  Is music a task, is a movie a task, etc.
Some of these will be easy to address others might get contentious.

</blockquot>
 
Yup. I don't see how we can define "information" as a "task." *Locating*
information is a task that the user performs (or is unable to perform,
or decides s/he doesn't care about anymore...). *Presenting* information
is a task that authors and user agents perform. But the information is
not the task.
 
One of the principles we tried to go by in writing (or re-writing)
success criteria after the March 20005 face to face meeting in Los
Angeles was to make sure that each SC focused on the content and not on
the user, because we wanted to avoid building in implicit ideas about
what users might or might not be capable of. So the SC are written to
describe functional outcomes without talking about the *user's*
"functionality."
 
The guidelines, on the other hand, are written as "tasks" assigned to
the author-- e.g., Provide text alternatives for all non-text content"
or  "Make all functionality operable via a keyboard interface." So we
could understand the SC under each guideline as providing ways to
determine whether or not the relevant task has been accomplished.  Each
SC in turn implies one or more tasks for authors; these  are described
in the techniques documents. 
 
It seems to me that talking about conformance in terms of tasks would
force  us to either an impossibly high level of abstraction or an
equally impossibly low one.
 
Having said all that, I'm sure I've missed something...
 
John
 
 

"Good design is accessible design"
John Slatin, Director
Accessibility Institute University of Texas at Austin 1 University
station Stop G9600
Austin, TX 78712, USA
Phone +1.512.495.4288 Fax +1.512.495.4524 cell +1.512.784.7533
email jslatin@austin.utexas.edu
www.utexas.edu/research/accessibility/ 

	-----Original Message-----
	From: w3c-wai-gl-request@w3.org
[mailto:w3c-wai-gl-request@w3.org] On Behalf Of Paul Walsh, Segala
	Sent: Monday, October 23, 2006 4:06 AM
	To: 'Gregg Vanderheiden'; w3c-wai-gl@w3.org
	Subject: RE: Task Approach to conformance. 
	
	
	
________________________________


	From: w3c-wai-gl-request@w3.org
[mailto:w3c-wai-gl-request@w3.org] On Behalf Of Gregg Vanderheiden
	
	

	At the last meeting it was suggested that instead of using web
pages or web units as the basis for making conformance claims that we
would use tasks.  

	 

	[PW] Whether you like the 'idea' or not, why use the term task
to replace a widely understood and already recognised term 'case'. Like
your definition of task, test cases could also have lower level test
cases. 

	 

	[end of comment]

	 

	This is an interesting idea that both addresses a number of
problems we face and raises a number of new problems.  

	 

	Because it addresses problems that we have faced and because we
have not yet had a chance to see whether or not the new problems can be
addressed I think it is worth taking time to walk the idea carefully
remembering that if it does not work we can always back off and if it
does work it might lead to some very interesting advances.

	 

	This email speak neither for nor against the idea.  It is just
some thoughts to get us thinking and exploring the topic.

	 

	 


	Thoughts


	 

	The first question that strikes me when thinking about basing
all the claims on tasks is "how you would define the word task?".  

	In looking at a web page one person could view the whole page as
being used to accomplish a task.  Others could view it as being a
collection of many tasks.  In fact in those cases it probably would come
down to being a task nested in tasks nested in tasks.

	 

	This nesting of tasks however may not be a problem since the
conformance claim says that all tasks must meet the guidelines.  

	Thus if even if you said that the page was an example of triple
nested tasks it would not change the fact that they would all need to be
accessible.

	 

	In fact if we think about it the word "tasks" may be no less
testable or definable than the word "purpose" which we also use in our
guidelines.  In fact, the way we use it may be very similar. 

	 

	 

	Using the "task" as the basis of conformance (or tasks) might
solve the "everything is accessible on my site except the order
fulfillment page" since the PURPOSE or TASK being carried out (and for
which the page was designed) was ordering and you can do that if the
fulfillment page is inaccessible. 

	 

	We probably would still need to talk about tasks at a URI or
range or URIs.  That is, you probably would still have to say that all
of the tasks represented by (or that can be accomplished at) the
following URIs would meet conformance.  Thus the basis for conformance
would still be URIs.  Instead of saying web pages or web units however
we would talk about the tasks at that URI.

	 

	This has the advantage also of blending very nicely with the
concept of equivalent facilitation.  That is if you can carry out all of
the tasks at that URI it does not require that you carry them out in
exactly the same fashion just that it is possible to carry out all of
the tasks in a fashion that meets all of the WCAG guidelines.

	 

	Concerns

	 

	*	There will probably be endless arguments about tasks.
What is a task, what is not a task, whether information presented on a
page is a task or whether tasks are only things you do.  Is music a
task, is a movie a task, etc.  Some of these will be easy to address
others might get contentious. 

	 

	*	There is always the question about whether or not the
same task can be achieved at the same URI.  This is not a different
problem I do not believe than the one we currently have which is whether
or not you will be able to get accessible content at the same URI. 

	 

	*	What if a task spans ten URIs but a conformance claim is
only made on five.  Does the conformance claim only have to cover those
tasks which are fully contained within those five pages or does making a
claim on any page automatically extend the conformance to any task that
might be carried out using that page as a part of the larger set of
pages (which go beyond the conformance claim).  The problem in either
direction here is clear.  You do not want a shopping site to claim
conformance to everything but its check out page and then say well "the
only tasks you can do are to window shop."  On the other hand anyone's
page might be accessed in the context of a larger task that they could
not possibly be responsible for  (Think "PORTAL" site). 

	 

	Advantages

	 

	*	It gets to the essence of the page or unit.  That is,
the page or unit was there for a purpose.  If that purpose can be
achieved in an accessible fashion than is that URI accessible? 

	 

	*	It helps to solve the problem between PHP (which
generates a bunch of "pages" from the same URI) and a set of HTML pages
which are on different URIs.  In both cases they allow users to carry
out the same task and so they would be treated the same. 

	 

	 

	Just some thoughts to get us thinking. 

	 

	 

	 

	 

	 

	
	Gregg
	
	------------------------

	Gregg C Vanderheiden Ph.D. 
	Professor - Depts of Ind. Engr. & BioMed Engr.
	Director - Trace R & D Center 
	University of Wisconsin-Madison 
	<http://trace.wisc.edu/ <http://trace.wisc.edu/> > FAX
608/262-8848  

	DSS Player at http://tinyurl.com/dho6b
<http://tinyurl.com/dho6b>  

	  <http://trace.wisc.edu:8080/mailman/listinfo/> 

	 

	 
Received on Monday, 23 October 2006 20:09:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:47:47 GMT