Re: Key results and recommendations from Face to Face

I have a question about the following sentence from what Al wrote:

>"We are striving for success criteria that are written as testable
> assertions about content in its encoded form, and to provide sufficient
> and testable techniques for encoding that content.

Where it's written, "...testable techniques for encoding that content".
Shouldn't the testable techniques "decode" the encoded content?

Just a question.

Doyle

Doyle Burnett
Education and Training Specialist
Multiple Disabilities Program
Special Education Service Agency
dburnett@sesa.org
Www.sesa.org
-- 




On 3/24/05 1:55 PM, "John M Slatin" <john_slatin@austin.utexas.edu> wrote:

> 
> Thanks, Al.  This is a beautiful exposition and it helps me very much.
> 
> There is nothing in WCAG 2.0 as vague as "structure your content." We
> are striving for success criteria that are written as testable
> assertions about content in its encoded form, and to provide sufficient
> and testable techniques for encoding that content.
> 
> John
> 
> 
> 
> 
> "Good design is accessible design."
> John Slatin, Ph.D.
> Director, Accessibility Institute
> University of Texas at Austin
> FAC 248C
> 1 University Station G9600
> Austin, TX 78712
> ph 512-495-4288, f 512-495-4524
> email jslatin@mail.utexas.edu
> web http://www.utexas.edu/research/accessibility/
> 
> 
> 
> 
> 
> 
> -----Original Message-----
> From: Al Gilman [mailto:Alfred.S.Gilman@IEEE.org]
> Sent: Thursday, March 24, 2005 4:17 pm
> To: John M Slatin; w3c-wai-gl@w3.org
> Subject: RE: Key results and recommendations from Face to Face
> 
> 
> At 3:03 PM -0600 3/24/05, John M Slatin wrote:
>> Al Gilman wrote:
>> <blockquote>
>> In one model of progress, practices evolve from experimental techniques
> 
>> to known-good techniques to normative techniques to hard technology
>> (embedded in and enforced by the technology platform). Normative
>> techniques are an essential stage in the life-cycle of technological
>> practice. </blockquote>
>> 
>> I can well believe that this is the case when *technology* is the
>> expected outcome. By "*technology*" here I mean such things as user
>> agents, authoring tools, markup languages, etc. But we are writing Web
>> *Content* Accessibility Guidelines, so I need some help understanding
>> how this logic works for *content*.
> 
> This 'content' -- what is it? Web content is nothing if not technology.
> It is persistent data so that an author can input it and a user extract
> it at different times. It is data on the wire between software the
> author selected and software the user selected. It is rules for
> capturing and encoding and decoding and interpreting those data.
> 
> It is ineffable and un-governable, unless it is addressed in its
> technological incarnation.
> 
> To participate in the web, "content" must be encoded. The encoding is
> technology. The encoding makes or breaks the communication path. If the
> composition of the technical representation combines markup, with its
> machine-interpretable semantics, appropriately with text, pictures, and
> sounds with their human-interpretable semantics, then the Web works.
> 
> If the formal and informal semantics are not aligned, the thing breaks.
> So without addressing the formal semantics of the formats, you leave out
> the meat of the matter.
> 
> It's as simple as that.  The domain of web content guidelines is the
> appropriate use of technology.  Not something technology-free. There is
> no technology-free web.  No technology-free web content.
> 
> Without addressing the message in its encoded (i.e. technological) form,
> you can't distinguish between appropriate and inappropriate Web
> practice.
> 
> We are not chartered to write rules for human interaction.
> 
> "structure your content" is unenforceably vague.
> 
> Guidelines for structure would be things like how much timeToSpeak or
> how many active elements could be in an unstructured section of web
> media.  Then how to organize the structure when you exceed those limits
> (as web pages routinely do now).
> 
> Al
> 
> 
>> Thanks!
>> John
>> 
>> 
>> "Good design is accessible design."
>> John Slatin, Ph.D.
>> Director, Accessibility Institute
>> University of Texas at Austin
>> FAC 248C
>> 1 University Station G9600
>> Austin, TX 78712
>> ph 512-495-4288, f 512-495-4524
>> email jslatin@mail.utexas.edu
>> web http://www.utexas.edu/research/accessibility/
>> 
>> 
>> 
>> 
>> 
>> 
>> -----Original Message-----
>> From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On
>> Behalf Of Al Gilman
>> Sent: Thursday, March 24, 2005 2:44 pm
>> To: w3c-wai-gl@w3.org
>> Subject: Re: Key results and recommendations from Face to Face
>> 
>> 
>> 
>> These sound scary.
>> 
>> At least, at a preliminary discussion of this direction in PF, serious
>> reservations were expressed.
>> 
>> A few, not exhaustive or definitive examples inline below.
>> 
>> Al
>> 
>>> From: Gregg Vanderheiden <gv@trace.wisc.edu>
>>> Date: Tue, 22 Mar 2005 21:18:13 -0600
>>> To: <w3c-wai-gl@w3.org>
>>> Message-Id: <20050323051833.95C3960C14B@m18.spamarrest.com>
>>> 
>>> 
>>> 
>>> At the WCAG Face to Face in Los Angeles March 21, 2005 the working
>>> group made very good progress on our key questions regarding baseline
>>> and structure.
>>> 
>>> 
>>> 
>>> On structure we reached agreement on an overall structure  - and are
>>> now putting it together in a form that is easy to review.  We will
>>> submit this to the list as soon as we can get it pulled together with
>>> some examples. Basically it is not terribly different than what we
>>> have
>> 
>>> but straightens things out and makes the roles of the various
>>> documents
>> 
>>> clearer.
>>> 
>>> 
>>> 
>>> On baseline we reached consensus on the items listed below.  The
>>> consensus was unanimous with the following people in attendance: Jenae
>>> Andershonis, Mike Barta, Doyle Burnett, Ben Caldwell, Wendy
>> Chisholm,
>>> Michael Cooper, Becky Gibson, David MacDonald, Loretta Guarino Reid,
>>> John Slatin, Andi Snow-Weaver, Makoto Ueki, Gregg Vanderheiden,
>>> Takayuki Watanabe
>>> 
>>> 
>>> 
>>> These are submitted to the list for review.
>>> 
>>> We will accept comments from the list - and then consider the
>>> following
>> 
>>> items for formal adoption with revisions to accommodate list comments.
>>> 
>>> This review for adoption will take place at the working group
>>> teleconference on March 31st  2005 .
>>> 
>>> 
>>> There were 5 consensus (unanimous) items from the meeting.
>>> 
>>> 
>>> 1) Can't use UAAG as Baseline
>>> 
>>> 
>>> It was concluded that UAAG 1.0 does not resolve the baseline issue
>>> because it does not resolve key questions like whether script support
>>> is provided.
>>> 
>>> We will therefore not be relying on UAAG as a baseline.
>> 
>> Just because UAAG 1.0 doesn't answer all questions doesn't mean it
>> shouldn't be a key source in profiling User Agent expectations.
>> 
>>> 2)  WCAG not set any explicit baseline
>> 
>> The pace of change in browser functionality has slowed radically since
>> 1997 when the WAI was launched.
>> 
>> Who will do this?  Should we enlist DLNA?
>> 
>>> WCAG will not set an explicit baseline; instead, external decision
>>> makers will make baseline assumptions or requirements. These include
>>> [but are not limited to] governments, customers, companies,
>> managers,
>>> and authors.
>>> 
>>> 
>>> 3) WCAG written as functional outcomes and not assume user tools and
>>> technologies
>>> 
>>> 
>>> WCAG will not explicitly state what technologies are supported or what
> 
>>> tools users will have at their disposal. WCAG criteria should be
>>> written as functional outcomes (see clarification #1) and therefore
>>> should not be specific to any technologies such as scripting, css,
>>> etc.
>> 
>> A plan more in line with the W3C culture would be:
>> 
>> WCAG requirements should be identified at
>> the functional outcomes level.  The W3C standard way
>> to publish this is a Requirements Document which has the status of a
>> Working Group Note.
>> 
>> In addition, requirements should be identified in
>> bindings to a variety of widely-used Web technologies.
>> These can and perhaps should be normative.
>> 
>> At the very least, they should be no less authoritative
>> than the more abstract requirements.
>> 
>>> 4) With regard to baseline and techniques:
>>> 
>>> 
>>> 1.    Techniques can not be more restrictive than guidelines otherwise
>>> techniques become normative.
>> 
>> Cannot follow the logic, here.  Normative is not equal to restrictive.
>> 
>> The UAAG has provided a fine example of declaring *sufficient*
>> techniques which are then normative, but not restrictive.
>> 
>> For example: 
>> http://www.w3.org/TR/UAAG10/guidelines.html#tech-conditional-content
>> 
>>>   [and Techniques should never be normative.]
>> 
>> Normative techniques would seem to be necessary to synchronize practice
> 
>> between authoring tools and user tools. Take the example Jon Gunderson
>> is pushing us to answer: "How does the AT or UA know from the markup
>> that something is a navbar?" (so that go-to and escape-from methods can
> 
>> be furnished for this object)" Authors won't do what the browsers and
>> AT don't support, and vice versa. Agreements in the form of consensus
>> conventions are the W3C way out of this chicken-and-egg dilemma. How do
> 
>> you justify the above statement? It seems straight backwards.
>> 
>> If the techniques are not normative, how will anybody on one side of
>> the equation believe that the other side will fulfil the contract?
>> 
>> In one model of progress, practices evolve from experimental techniques
> 
>> to known-good techniques to normative techniques to hard technology
>> (embedded in and enforced by the technology platform). Normative
>> techniques are an essential stage in the life-cycle of technological
>> practice.
>> 
>>> 2.    Techniques documents may provide multiple techniques and those
>>> techniques may differ based on user agent assumptions. For example, we
> 
>>> could have 2 techniques: 1. how to make scripts accessible for user
>>> agents and assist. tech that support scripts 2.  how to write content
>>> in such a way that if scripts are turned off the content degrades
>>> gracefully (i.e., still usable w/out scripting).  however, these two
>>> techniques are not mutually exclusive and one or the other is used
>>> depending on what technology choices are made.
>>> 
>>> 5) Tests not set baseline
>> 
>> Without agreed methods of observing the de-jure normative functional
>> outcomes, will not the guidelines be unenforceably vague?
>> 
>>> 
>>> Tests will not set a baseline.  Multiple tests may be provided to
>>> correspond to multiple techniques.
>>> 
>>> 
>>> Clarifications:
>>> 
>>> 
>>> 1.    Scripting is used as an example because that has come up often.
>>> These assumptions also apply to plug-ins, etc.
>>> 2.    Functional outcomes  - may require tweaks of existing guidelines
>> or
>>> success criteria
>>> 3.    Conformance claims are not addressed by the resolutions from 21
>>> March 2005. This requires future work.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Action and timeline items from Face to Face:
>>> 
>>> 
>>> Before 24 March telecon
>>> 
>>> 
>>> *    Each person think about consequences from resolutions from 21
>> March
>>> 2005
>>> 
>>> 
>>> At 24 March telecon
>>> 
>>> 
>>> *    Discuss consequences from resolutions of 21 March 2005
>>> *    Discuss long-term plan
>>> 
>>> 
>>> By 28 March
>>> 
>>> 
>>> *    Mike [Gregg, Michael, John] - Impact assessment per guideline
>> and
>>> success criteria
>>> *    Michael [Becky, Ben] - Impact assessment for techniques (classes
>> of
>>> techniques: conformance, informative, additional)
>>> 
>>> 
>>> At 31 March telecon
>>> 
>>> 
>>> *    Consider for adoption resolutions from 21 March 2005
>> 
>> Adopting the above stated level of abstraction is dubious in the
>> absence of a fully fleshed out proposal about the profilable
>> conformance assessment scheme.
>> 
>> Al
>> 
>>> 
>>> *    Impact assessment per guideline and success criteria
>>> *    Impact assessment for techniques (classes of techniques:
>>> conformance, informative, additional)
>>> *    Status reports on Guideline 4.2 proposal and conformance claim
>>> assessment/proposal
>>> 
>>> 
>>> By 4 April
>>> 
>>> 
>>> *    Wendy [Ben, Mike] - Proposal to discuss/solve conformance claims
>>> (impact assessment)
>>> *    Loretta [Mike, David, Andi] - Revisit guideline 4.2 issue
>> summary
>>> and generate new proposal for Guideline 4.2
>>> 
>>> 
>>> At 7 April telecon
>>> 
>>> 
>>> *    Proposal for Guideline 4.2 (from LGR, MLB, DMD, ASW)
>>> *    Conformance claim assessment/proposal
>>> 
>>> 
>>> By 11 April
>>> 
>>> 
>>> *    John [Ben, Michael, Wendy, Gregg, David, Becky] User analysis
>> for
>>> structure and structure proposal/prototype for 1.1, 1.3, 2.4, 3.1, and
> 
>>> new 4.2
>>> 
>>> 
>>> 14 April telecon
>>> 
>>> 
>>> *    Discussion of structure prototype
>>> 
>>> 
>>> By September - be stable enough for WAB Cluster work to move forward
>>> on
>> 
>>> evaluation suite.  Minimum: Candidate Recommendation?? (check
>>> timeline)
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 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
>>> For a list of our list discussions http://trace.wisc.edu/lists/
>>> 
>>>   <http://trace.wisc.edu:8080/mailman/listinfo/>
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Received on Wednesday, 23 March 2005 05:18:46 GMT
>>> 
>>>      * This message: [ Message body ]
>>>      * Next message: Shadi Abou-Zahra: "Re: Key results and
>>> recommendations from Face to Face"
>>>      * Previous message: Michael Cooper: "[techs] CANCELLED
>>> Techniques Teleconference 23 March 2005"
>>>      * Next in thread: Shadi Abou-Zahra: "Re: Key results and
>>> recommendations from Face to Face"
>>>      * Reply: Shadi Abou-Zahra: "Re: Key results and recommendations
>>> from Face to Face"
>>>      * Maybe reply: lguarino@adobe.com: "Re: Key results and
>>> recommendations from Face to Face"
>>>      * Maybe reply: Michael Cooper: "RE: Key results and
>>> recommendations from Face to Face"
>>>      * Maybe reply: Michael Cooper: "RE: Key results and
>>> recommendations from Face to Face"
>>> 
>>>      * Mail actions: [ respond to this message ] [ mail a new topic ]
>>>      * Contemporary messages sorted: [ by date ] [ by thread ] [ by
>>> subject ] [ by author ]
>>>      * Help: [ How to use the archives ] [ Search in the archives ]
>>> 
>>> This archive was generated by hypermail 2.2.0 + w3c-0.30 : Wednesday,
>>> 23 March 2005 05:18:48 GMT
> 
> 
> 

Received on Thursday, 24 March 2005 23:22:47 UTC