RE: WCAG 2.0 usage scenarios

Hi Wendy,

Thanks for making a start on this.  Here are some of my thoughts on the
usage scenarios doc:

1] column headings
I agree with your later mail: "The point (as I see it - feel free to
disagree) is to figure out the different types of information that
people need.  If the needs of an information architect differ greatly
from a designer, then we ought to address them as separate entities.  If
not, then we ought to find a general category that represents them
both.", ... except that I would suggest we group together identical
profiles into a single column without losing the detailed role
information.  Eg. Make the header for the first column read:
"Layout designer
Stylistic designer
Navigation designer
Content creator"

This makes the table look simpler while removing the problems of finding
a general category name that means the same thing to all.  It maybe also
strengthens the idea that these are roles rather than people (see the
next point).

Note that 'Content Creator' may be a little vague as a term for our
usage, esp. given the title WCAG.


2] roles vs. people
I think we should replace the text "This is a matrix of the people who
might use..." with something along the lines of "This table shows how
WCAG 2.0 documents related to various roles in the development process".
Whether a particular person relates to one or more of these roles should
be irrelevant.  In fact, it may even be good to include some
introductory text specifically recommending that the reader search for
all the roles they consider to be part of their current assignment. 

It may actually help this to change the column titles to Layout Design
(rather than Layout Designer), Content Creation (rather than Content
Creator), etc.  


3] missing categories?
I think we may need to capture the following:
-	writers/producers of markup and scripting (such as HTML markup,
code linking to database such as JSP, etc., client-side scripting such
as JavaScript).  I'm not sure how we label that, or whether we need to
separate that role into more specialised roles.
-	designers of DTDs / Schemas 

I think an additional benefit of combining points 2 and 3 (in this mail)
is that it is likely to help in a situation where, for example, some
authors use tools to create HTML and just write text, whereas others
write the HTML at the same time as the text.  The former would just look
under Content Creation; the latter would look under the union of Content
Creation and Coding.


4] presenting this to the reader
When it comes to helping people decide what documents to look at,  I
think it would be much better to collect information about them using
form input and to generate a clean page devoted to their interests than
to present them with the table.  Such a page could look similar to
http://www.w3.org/WAI/Resources/ but have unuseful stuff filtered out.


5] this usage scenarios table vs. filtering
guidelines/checkpoints/techniques
I think if we were to filter information provided to the reader on a
checkpoint or technique basis, we'd probably need to classify roles in a
more granular way than for this table.  For example, we'd need to be
able to associate a given directive with either layout designers or
content creators or both (to use the example above).  In fact we may
even want to split content creators into text authors and
graphic/multimedia designers.  The trick, I guess, is to find the
smallest number of categories to make that remain manageable.


6] creators vs auditors
My preference when creating content is to consult a document that groups
information by task.  This is much more like the headings of the
Techniques documents than those of the Guidelines document.  When I'm
auditing a web site, the reverse is true.  Thus, I would say that the
Stylistic Design column should emphasise the importance of, eg. Core and
CSS Techniques documents rather than guidelines when talking about
people trying to implement something, but emphasise the guidelines
document for people auditing the Stylisitic Design approach used by
someone else.  I'm not sure how to show that.


7] a missing dimension
I think as we develop the table we will find it is missing a dimension:
technology.  For example, Stylistic Designers could be using CSS, XSLT,
XSL-FO, or other things.


8] different perspective?
While the table you put together is useful as a starting point, I think
that we should not ultimately create a table that shows how the current
deliverables are relevant to user types; rather we should create a table
that shows what deliverables we need to support the range of user types
that is in scope.


I hope those ideas help.
Richard.

============
Richard Ishida
W3C

The W3C Internationalization Activity has restructured, and has issued a
call for participation.  
See http://www.w3.org/International/about.html

tel: +44 1753 480 292
http://www.w3.org/International/



> -----Original Message-----
> From: Wendy A Chisholm [mailto:wendy@w3.org] 
> Sent: 25 September 2002 23:55
> To: w3c-wai-gl@w3.org; ishida@w3.org; mcmay@w3.org
> Cc: Judy Brewer
> Subject: WCAG 2.0 usage scenarios
> 
> 
> Richard and Matt,
> 
> Based on our discussion last week about WCAG 2.0, I created 
> the following 
> skeleton of a document, "Usage Scenarios for WCAG 2.0." [1]  
> It is very rough.
> 
> WCAG WG,
> Would you find something like this useful?  My goal is to 
> help us meet our 
> 4th requirement of "Requirements for WCAG 2.0" [2] - 4. Write 
> to a more 
> diverse audience.  In talking with people about WCAG 2.0 I 
> have found two 
> issues:
> 
> 1. it is difficult for people new to WCAG to piece together 
> all of the 
> pieces.  They need a roadmap. Since the resources include 
> those written by 
> EO, AU, UA and some non-WAI groups, this might be an EO 
> exercise rather 
> than something I should do, although I think it is an 
> exercise that will 
> greatly benefit the WCAG WG understanding of who uses our 
> materials and how 
> the materials are used.
> 
> 2. There are two levels of detail people may want at the technology 
> level.  Currently the "HTML rules" are phrased as, "Use the 
> TITLE element 
> to describe the document."  Some people would rather see a testable 
> statement such as, "Check that each HTML element has a TITLE 
> element."  Matt has me thinking that we might want both types of 
> statements.  It is similar to the level of detail at the 
> checkpoint/success 
> criteria level of the guidelines, but technology-specific.
> 
> A group of us took an action item to address the second 
> point.  I began 
> working on a proposal, but mostly documented background. [3]
> 
> In conclusion,
> 1. Is it helpful to complete the exercise begun at [1]?
> 2. Is it helpful to create a roadmap of how the pieces of 
> WCAG 2.0 fit 
> together?  Will a roadmap help WCAG WG move forward on WCAG 
> 2.0? 3. How do people feel about two levels of detailed 
> statements at the 
> technology-specific level?  Any reactions to [3]?
> 
> Best,
> --wendy
> 
> [1] http://www.w3.org/WAI/GL/2002/09/authoring-scenarios.html
> [2] http://www.w3.org/TR/wcag2-req/#audience
> [3] http://www.w3.org/WAI/GL/2002/09/tech-check.html
> 
> -- 
> wendy a chisholm
> world wide web consortium
> web accessibility initiative
> seattle, wa usa
> /--
>

Received on Monday, 30 September 2002 12:39:04 UTC