- From: Doyle-Work <dburnett@sesa.org>
- Date: Thu, 24 Mar 2005 14:18:18 -0900
- To: John M Slatin <john_slatin@austin.utexas.edu>, Al Gilman <Alfred.S.Gilman@IEEE.org>, W3C Web Content <w3c-wai-gl@w3.org>
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