WC please read through and let me know if comments about structure have been addressed. Comments from Charles I will address on the list.
JW We will discuss requirements document for next version of the WCAG. Charles raised issues last week. Others?
TN level of language or the way they are presented for people who are intimidated by the technical language of the document? In an interview with Jim Thatcher, he said that IBM found that several people found the guidelines unapproachable. they are too detailed and long-winded.
JW division of labor between WCAG WG and EO. The solution we resolved on last year was that the EO materials would be advised to refer to them rather than the guidelines. the guidelines are there as reference.
TN that's reasonable. many people may not be aware of.
JW in the into to the guidelines, i believe they mention the EO work. if people not noticing, then a problem.
CMN a genuine problem. they are large and difficult to use. if we can solve those issues we will solve some issues.
DB agree. i could share site groups reactions to the guidelines.
WL there needs to be something between WCAG and quicktips. I would also like to De-TML this to a certain extent. like authoring tools did.
JW yes, charles raised this issues last week. many of the checkpoints can be pushed to the HTML module. we could generalize many issues.
WC anything people should have read before coming to the meeting?
WL ATAG because they tried to do that.
JW Daniel's note on XML Accessibility. Standards compliance by major user agents with style sheets in particular.
WL in the guidelines are there proscription against shipping preformatted stuff.
JW by implication.
CMN checkpoints that say, "use style sheets."
JW separate structure from presentation.
WC those that refer to PDF are for non-w3c technologies.
WL what if it becomes a w3c technology? Hakon has published a stance on this. This is general and thus could be discussed.
CMN we say specific things, "markup headers." we could instead say, "markup structure and semantics." then you could say, "here is where the spec says here's how to markup structure..."
JW as look at development of new XHTML modules, we need to be more specific as to exactly what kinds of structures and semantics distinctions are necessary. the danger is similar to what ICADD did - created a DTD that did not achieve the goal of encoding the necessary distinctions. it was not exhaustive. we should be specifying what sorts of distinctions ought to be captured. let's not pretend to be exhaustive.
WL stake out some turf. the details are beyond me. if people can point back to something, that will be good.
CMN there is a specific example where a major change was affected by saying that for accessibility purposes, reformatting every kind of document is critical.
JW make use of the DOM.
CMN use of meta data
JW we ought to define that a bit more. we have a clear case of RDF in providing additional content to make graphics more accessible.
WL expand idea of guidelines to include production of the next level of anything that will affect the web, not just web documents. "you can't start a new thing w/out looking at..."
CMN that is out of scope. that's PF's job. XML guidelines are response.
JW as a rough indicator, the user interface issues are UA. anything that relates to content, including schema and dtd definitions, falls w/in WCAG. any issues relating to specific review of upcoming technologies is PF.
WL ok.
CMN we have our work cut out for us. we aren't generating techniques docs fast enough.
JW we have a number of issues. any areas that we have missed?
CMN cognitive disabilitites.
WL yes.
JW guideline 14.
WL particularly in view of the almost total lack of anything being done in our own world.
CMN accessibility of graphics.
JW I had some thoughts on that. the current treatment of image maps is very HTML specific. the principles of access of providing labels and descriptions becomes more feasbile with SVG. guidelines relating to preservation of structure also important. that gives rise to interesting possibilitites that ought to be explored in next version.
CMN SMIL also things that are image maps. it is intrinsically times. SVG is not although has animation module.
JW generalize our principles to cover these cases. the accessibility of mathematical content. need MathML techniques module.
CMN develop an accessibility and MathML module.
WL musicML? what's up with VRML?
CMN web3d turning it into XML. yes, that area is another to investigate. we ought to take our guidelines and run them against a VRML document. where do the requirements seem too specific and irrelevant.
TN generalizations will make it more abstract. from editorial perspective will it still be feasible to stay something that applies to specific technologies?
CMN leads to more targetted techniques structure. if a graphics artist, probably don't care about XML accessibility. however, interested in grahpics techniques document.
TN but core guidelines document should not be so abstract that it is theoretical. there ought to be some reference to the sorts of things we are talking about. e.g., mark up doc strucutre (headings and lists, etc.)
JW yes, need clear indicators of what is needed.
CMN in this context, would be good to have some testing of the different approaches. Someone do some usability testing. People prefer examples?
JW because the guidelines are w3c recommendation they are stable that is not intended to be revised frequently. thus we must be careful to make sure they are as timeless as possible. thus another reason for the layers of abstraction.
WC interested in usability testing.
CMN have person interested in the project.
TN my comments are not about splitting it up but that as it becomes more abstract that the reader does not lose what we are talking about.
CMN ATAG is almost opposite of WCAG, we are almost example free. thus it is really short. it is quick to read through. developers seem to like. as soon as they have read through it, they begin to question, "what does this mean." thus they read techniques. wcag - masses of examples. don't read techniqeus because they think everything is in the examples. thus we force people to read the techniques doc. the more tightly targetted techniques further encourages people to read them.
JW instead of examples, could refer to language features as illustratios.
CMN not arguing for religious aversion, but propose keeping volume of examples down to minimum.
TN brief illustrations exactly what thinking of.
JW many of the features for access seem to be shared across languages.hearing strong interest in generalization and distilling of principles than even higher than current version.
DB higher level is not the only solution. the specifics and what means when not clear. some are subjective. i'll share more on that. generalities are good but need more specifics.
CMN we want to take the guidelines doc to more abstractions. have techniques bring that into focus. in ATAG we discussed putting into techniques tests - what is it you have to do to measure conformance? different from a checkpoint as well as examples.
WC some quicktips and validation. agree should be expanded. also concerned about lots of new names registered for the meeting. should we spend some time in a.m. to get up to speed?
CMN waste of time. discuss offline.
DB refer to web pages, but blurring into web applications.
CMN chuck opperman discussed this a while ago. there's a thread on IG: what is the minimum standard? can everyone use a form? do we expect that everyone can follow a link? does everyone have a JVM? a javascript parser?
WC Trace looking at lowest common denominator. depends on stats. those hard to come by.
TN everyone having javascript is far from true.
CMN an issue we should grapple with.
WC gets into the timeless issue. we tried to address with "until user agents." personally would like to get rid of until user agents page. authors want to know what to do. leaving it as open as we have creates problems.
/* address in techniques document */
/* will have an effect on user agents. */
DB next release of IE will have affect.
CMN SVG spec says, "an SVG generator should conform to ATAG." that requires ATAG and WCAG are implementable and usable by developers of those tools. in ATAG we managed to convince developers of graphic design tools that they could do that. these things are happening we are making a difference. we need to keep on supporting the developers who are working on the tools to keep making a difference.
WL to get back to new people: one plus is to make the agenda items have a lot of meat on their bones. write up an agenda that summarizes these issues.
@@JW and WC fill out the agenda.
JW these minutes are part of the prior reading for the meeting.I would add guidelines and techniques to the reading list.
CMN ATAG WG is working on templates for authoring tools to use. please review. give comments. test.
JW agenda announced to the list. no teleconference on the 16th or 23rd because of the face2face on the 20th.
$Date: 2000/11/08 08:30:15 $ Wendy Chisholm