JW questions about governmental bodies using our documents or referring to our documents. What is an appropriate response?
GV For those of us on the variety of committees, such as the COST219 in Europe or EITAAC in U.S. The stance I have taken is that the committees should defer to the work of the W3C/WAI. When we have guidelines that enforced by a country that are different from what we have and they ask for comments on those guidelines, I think this group ought to review the new set of guidelines to identify where they have created 1 of 2 things:
we need to harmonize where possible.
we have this situation now in the U.S. with the 508 guidelines. we should review and see if we have anything to contribute.
PJ W3C process question: has the w3c officially responded to committee specs in the past?
CMN the W3C as an organization has not made a formal submission. Judy Brewer has been asked for her opinion. This happens in other fields and other experts at the W3C.
PJ i'm asking if we should respond as a group. at a minimum as individuals. is the question, should we respond as a group?
GV we don't have any business making an official proclamation. all we can do is study and provide information to the W3C. don't know that w3c should make formal statement. we should review and determine the situation and provide that info back to w3c staff. we should not have an official policy to say things externally.
PJ are you saying that we just say, "here's what's different."? not should we change or should they change?
GV we should definitely incorporate better ideas from their stuff into ours, not b/c theirs but because better. if we see problems, we need to comment on them. we're going to have to live with them if they continue to exist. Judy and Tim, etc can figure out what to do with our info.
PJ when we say, "what we should publish" are you referring to a note that compares WCAG and 508?
GV no, just send them an e-mail. staff can carry this back up to W3C management. it is not a product of the WG but a process. i would love to see what other people on the WG think about this. are there problems?
JW I think it is within the WG's scope to review other guidelines based on the WCAG.
CMN not just scope but obligation to track work in the area. if someone is saying something else different, 'why" and "what?" One issue of commenting on other people's work is that I'm very concerned about Australian government and less-so about U.S. however, guidelines interact with each other and the marketplace. the marketplace is what i am concerned about. it's tricky. we can each make our own comments. sharing what we know in the WG is a good way to help us as individuals to make formal comments.
JW I know the Australian govnt has been referring to WCAG. any indication they are planning to draft guidelines? I know EU is planning to develop regulation. Is this issue likely to arise again?
CMN yes, it will continue to arise. each country will do something. possibly do something different 3 years later. Australian has a set of guidelines for government publications that reference WCAG. Is happening in Portugal. European parliament is a bit behind Portugal. Individual governments w/in Europe are doing similar things.
GV we will limit discussion of this to 1/2 hour. is anyone against discussing it?
CMN i don't think we should discuss at this meeting. WCAG requirements is more important.
GV review period is limited. WC and i won't be here. that's why on agenda here.
DB yes, should discuss.
GV harvesting for 12 more minutes. anybody who had read, compared, or aware of them please comment.
WC a few missing.
CMN they have merged a couple and lost a few.
GR have lost idea of text as "last resort." should focus on.
GV doesn't matter in law. whether it's last resort or not, if you comply you comply. therefore, probably dropped it.other things that are gone?
WC those that are missing: 1.3, 7.1, 8.1, 14.1
GV very HTML specific. no guidelines at all.
CMN we have "ensure pages are usable w/out style sheets." Chris Lilley has pointed out that that is problematic in the XML world. 508 adopted that straight out.
GV we have to say, "we screwed up on that" but ask them to change. basically mandating that government don't use XML and only use HTML. that's a serious issue to address.
PJ I thought they were trying to be more implementable therefore future technologies are not considered.
GV yes, they want things specific, but cementing industries feet.
PJ when they say "use alt-text" they don't say DON'T use other means.
JW it's a negative implication.
GV if you read the whole thing they do allow for the company to say, "here's a way to do it." supposed to spec that out not just do them.
CS we ought to encourage them to go in the same direction as the face2face - more general things. including alt in law is scary!!
JW if people have other documents that specify technical requirements, they should be brought to the attention of the working group.
GV what about portugal?
CMN forum created to give input. the final input has gone in. the result document has come back. not sure if the forum is still open.
GV if its in review stage, then we need to get it. if it is passed review and frozen.
WC EO has been monitoring activities. are you suggesting that we need to be?
GV no, they need to forward these things to us. we should review every set of guidelines to harvest for great ideas.
JW yes, anything that refers to our document wouldn't need to be reviewed but anything that specifies technical requirements should be.
WC is there an action item for people to review documents?
GV action item for all of us to watch for them. if someone on EO
WC policies relating to Web Accessibility.
JW no list of guidelines out there.
GV who is maintaining a list of current guidelines? we need to link to it from our home page.
GR standards coordination page by EO. for coordination and contact info for people promulgating guidelines.
@@Action GR: send WC URI of coordination page for standards.
@@Action JW: take to CG that EO forwards to us for technical review guidelines developed by others.
CS generalizing across technologies: does not include dynamically generated.
WC included as open issue in back: server-side.
CS and target market.
CMN the fact that what is available and what the shape of the user community is like. this will differ from language to language. we assume people can follow a link. we assume that people may not have a script-supporting browser. we ought to make those assumption explicit.
CS specify assumptions in the document.
CMN in requirements, require us to make those assumptions clear.
FT with dynamically generated site, new realm. static site you will want to adhere to all P1s. with dynamic, you could be accessible to everyone but not in every version.
JW yes, gives rise to conformance problems.
CMN theoretically possible to provide access to everyone.
WC assumptions ought to be made clear.
GV e.g. browser requirements.
CS haven't addressed applications that are not just pages. the distinction is that may not be considered content. a blur between applications and content.
WC listed as open issues, does this cover?
CS nothing about web-based applications. need to figure out the boundary between.
PJ another way of looking at: the applicability idea that Ian brought up. Are all of these checkpoints applicable in all cases? I wrestle with the server-generated content, when it shows up in palm pilot which checkpoints apply vs. on my desktop. coming from desktop paradigm to smaller devices.
GR cc/pp module? i think that that aims at it.
PJ if i use XML i have to use style sheets.
WC some of these are technology-specific checks that should be pushed to technology-specific modules.
GR i'd like to see pointers to chunks of the specifications. e.g. in CSS point to the clear conformance section.
GV we'll have to use our judgement. if a fixed document, cut and put in appendix. the reason being is that people will want to print it. if need to go to lots of places to understand, may be unlikely to get.
GR theoretically action item: to collate such an appendix.
CMN not that useful. you'll have to read the spec. it won't just be the conformance section.
JW I have doubts it would be useful. the main source for User agent requirements will be UAAG. WCAG needs to be consistent with that.
GR I don't have an issue w/that. We spent the first 1/2 hour discussing issues with a particular audience. For those who are not technically savvy I don't think they will go to the specs.
CS or at least compiling these sections into one document.
JW put it down as an issue.
WC statement of problem? these sound like
GR implication that couldn't use XML in the regulations.
CS show that different technologies implement differently. make aware that there are different versions.
GR as we try to abstract guidelines we need to make sure there is a firm foundation of what expected and what not.
WC believe this is covered by the "variety of audiences" clause in the requirements document.
Variety of audiences: WCAG 1.0 was primarily written for markup-savvy developers. WCAG 2.0 must address the needs of managers, policy-makers, designers, advocates, and others listed in the Audience section of this document. This implies using less technical language in an executive summary, and layering the information in some way for the various audiences.
Therefore, what you are looking for seems to be introductory material.
JW some of that is EO work. anything else that needs to be in the requirements document that is not?
PJ we talked about audience and usability, but missing from usability: approach to designing documents. there may be a way to take the guidelines and put them in a summary that lays out how to approach the design.
CMN agree very strongly, however work of EO.
WC what about
Coordinating with the Education and Outreach Working Group (EO WG) will be crucial to creating a suite of information that addresses the needs of our diverse audience. The EO WG has created useful derivative works of WCAG such as the Quicktips and the Curriculum. The "How to get started" project may be some of the glue that we need to tie our documents together.
PJ want a different view of the document, didn't want to go that far. create a section that's just guidelines. want all of the guidelines in one section and how they apply to creating a web site. not a "how to get started." not for executives but developers.
CS sounds like a layer, the one between executive summary and techniques.
JW that would have checkpoints as well. have to be cautious about creating too many layers and repetition.
PJ many terms on audience list are similar but have different roles.
GV should we group them? don't want to lose the diversity.
CS yes, content developer and developer are very different. content developer editorial background and developer programming background.
GR yes content developers need to be trained in writing long descriptions.
CS person writing the script vs. developing are very different.
GV director vs. camera person vs. writer, etc.
PJ these people may be performing different tasks. therefore, look at not just at titles but tasks. this will help us identify their needs.
JW not consider it in terms of audiences but requirements for the types of information that need to be provided.
PJ i give people different lists depending on where people are in the process of developing the site. different audiences, different roles, different checklists. phase development approach. the checklist changes over time.
GR could you write that up as a brief scenario? clear simple language be for the content developers.
PJ most of the checkpoints applied at every phase but at a different level. programmer looking at alt-tag while content developer looking at appropriateness of text in the alt-tag.
JW guidelines stable while techniques can change. Working through the current checkpoints to determine which need to be generalized so we can propose appropriate restatements that are more general. I think a few people could be working on this in parallel.
CS makes sense to me.
WC what about a general action item for people to discuss at next week's meeting?
GV I think people will go through it more easily than others. Some people are better at reacting than generating.
JW the task is to review the guidelines and checkpoints to identify those that are technology specific and propose statements that are technology-neutral. if that isn't possible then just say "remove and put in HTML techniques" or "CSS" or etc. Start it on the mailing list. To manage it properly should it be one checkpoint per message?
WC difficult to manage 60 threads. would be great to use with ETA.
JW there should be a few threads each proposal in a separate message.
@@Action everyone: review the guidelines and checkpoints to identify those that are technology specific and propose statements that are technology-neutral. if that isn't possible then just say "remove and put in HTML techniques" or "CSS" or etc. Start it on the mailing list.
WC further comments on requirements document? reminder to send comments to ER WG re: ERT by tomorrow.
GV typos. "we should provide real-life examples" the suggestion is that if we have a site that we want to use as an example we ought to get permission and then store a local copy somewhere. if you point to a live site, it could get edited, become a bad site rather than good.
PJ suggest we say "working" rather than "live."
GV or "provide real-life examples" and do what is appropriate. it is critical to provide them, but must be done cautiously. if you look at 508, instead of saying "things should be accessible" they said "things should be accessible and compatible." if we were say if something needs to be accessible or compatible per certain constraints, then could discuss accessibility and compatibility per each technology. i am just throwing that out there as a way to look at things. start out w/objective and role down to how achieve. gets back at what phil said, "i may not have a screen reader on a palm pilot, that's a desktop view of the world."
/* discussion of how to move forward on the cognitive disabilities issues */
GR need to find way to move forward.
GV create sample sites and see the commonalities.
WC suggest people discuss and take action items at next week's meeting.
GR optimistic because discussing shared language and bringing in other experts.
GV yes, the discussion has been good. it can take a while with sticky issues to come to a conclusion. we have stuck with it and seem to be moving foward.
$Date: 2000/11/08 08:30:15 $ Wendy Chisholm