- From: John M Slatin <john_slatin@austin.utexas.edu>
- Date: Fri, 25 Mar 2005 10:23:17 -0600
- To: "Doyle-Work" <dburnett@sesa.org>, "Al Gilman" <Alfred.S.Gilman@IEEE.org>, "W3C Web Content" <w3c-wai-gl@w3.org>
Doyle, just a clarification: I (John) wrote the following: <blockquote> >"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. </blockquote> I wrote the above as a response to Al's very careful explanation of what he meant in saying that Web content is a technology. The central point I took away from his careful exposition was that Web content is technology because in order to be delivered via the Web all content (text, video, etc., etc.) has to be "encoded" in some form such as HTML, SVG, SMIL, Flash, PDF, JPEG, etc. With that in mind, I think it makes sense to think of WCAG as specifying success criteria for content as encoded for the Web, and to think of the techniques documents as providing advice about how to do the actual encoding. The tests then verify whether the encoding has been done correctly. Hope that makes sense. 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: Doyle-Work [mailto:dburnett@sesa.org] Sent: Thursday, March 24, 2005 5:18 pm To: John M Slatin; Al Gilman; W3C Web Content Subject: 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 Friday, 25 March 2005 16:33:53 UTC