> EOWG Home >
EOWG Minutes.
Agenda in e-mail list archives: http://lists.w3.org/Archives/Public/w3c-wai-eo/2004JulSep/0149.html.
HS: Web accessibility event in NL for students skilled in computer development more than web accessibility issues.
JB: web accessibility for kids, idea; To serve as an introduction for kids, idea for an EO document.
HS: Holding and planning meetings on campus to spread accessibility awareness.
BM [joining call].
See review questions and issues in email archived at
http://lists.w3.org/Archives/Public/w3c-wai-eo/2004JulSep/0146.html.
Requirements:
http://www.w3.org/WAI/EO/changelogs/components#requirements.
JB. Charmane has posted comments to list, sends regrets for this meeting.
JB. General reactions please.
SLH. Let's talk about purpose of document first.
AA. [joins call].
SLH. Many people are not aware of the other components of Web accessibility.
SLH. This document is intended to explain, briefly, what the components are and the interrelationships between them.
SLH. Would like to address some of the frequent questions we get asked.
SLH. [explains document].
HB. For past years have been pressuring authoring tool vendors.
JB. Maybe difficult to discuss document in abstract way, maybe we can get people's general reactions.
CL. Like the document.
HS. Explains interdependencies.
AA. Thought we were talking about interdependencies, rather than components.
AC. These components are not only accessibility, they are the overall Web system.
WD. When you talk to many people about it, they focus on assisstive technology.
JB. Other reactions to purpose.
JB. Look at latest version of components of Web Accessibility.
JB. What are people's general reactions.
HB. Like it. Nice descriptions, clip art. .
HS. May be too brief.
HS. List for example is too brief. "Web content" rather than just "content".
HS. Add half a sentence to each component in list to explain why it is based on each one.
AA. There's more information in the diagram than in text.
JB. There was an intermediate version.
JB. More comments.
JT. I wish I'd had this document a few years ago when I was first learning about Web accessibility.
HB. A document we should refer people to.
SLH. Will be linked to from main site pages.
CL. Will be useful to show to policymakers in government.
SLH. Would be interesting to know what other documents people wish they'd had before.
SLH. CL agrees with HS. that we could add more detail.
JB. Good time to pick up new ideas for documents. For example, something really simple on how to make your site accessible.
JB. Don't have anything basic about it.
BM. Agree with HS.
WD. Really like the diagram. Would like a bottom-up view of web accessibility literature.
SLH. We can walk through document. At this level don't need to look at specific wording.
JB. Introduction.
HS. Doesn't mention interdependency. Uses word relate. Same as interdependencies.
AC. People won't understand about interrelationships because they haven't read about what we mean by 'components'.
CL. My audience would be able to cope with it, but maybe not more novice users.
JB. In our documents, try to avoid hyperbole. Here "vastly" is maybe not appropriate.
AC. Like the word "system", sums up general idea.
[talk about word "vastly"].
JB. Leave details to editors.
JB. How the components relate. [describes].
SLH. Want to check whether the parts are in the right place. Structure of document.
AA. Relate diagram items.
SLH. Three arrows in first diagram should come together then point to accessible web symbol.
SLH. Maybe arrows only point to accessible web symbol, not bidirectional.
AA. [discusses arrows on diagram].
JB. Does it help having web accessibility as focus of diagram.
WD. Important. Everything else contributes to it.
CS. [joins call].
SLH. Look at in between versions linked from from change log.
AA. Did you update it in past few hours.
SLH. Yes.
AA. Must have had previous version.
CL. In-between version is clearer.
HB. Maybe put it at end.
BM. Having trouble with newer version, shows user accessing content. Earlier version is clearer.
JT. Hard to cope with older diagram.
AA. There's a layer missing in diagram.
AA. Need to split the diagram in two.
[AA. takes over minuting. AC leaves call.].
SLH. What do we need for a good user experience.
SLH. Authoring tool + content + UA & assisstive technology.
SLH. Person uses UA to get to content.
SLH. Different from the 4 pieces that contribute to an accessible web.
SLH. Do we say that all these things need to be accessible to have an accessible experience? OR is that the way the Web works.
WD. Content, UA, assisstive technology that give a user experience (accessible web).
WD. Need to outline the bits that are needed.
JB. Authoring Tools support production of accessible content -> creation of accessible web.
JB. Also, Web is meant to be two-way - so Authoring tools need to be accessible too.
JB. Asking: if we are highlighting the components of a complex picture, it is sometimes done by "greying out" the bits not under focus - would this work.
AA. Like the idea.
SLH. Good idea, but how?.
SLH. Good idea to explore ways of doing this.
AA. What about clicking on smaller image to give larger image with full picture, but other parts grayed.
JB. Need to move along - any other comments.
SLH. If we stick with this idea, then three arrows coming together to create accessible Web.
SLH. Then need accessible Authoring tool bit.
JB. Any comments about paragraph 2.
BM Like the sentence on "users ..."
WD. "In some cases" should be "in all cases" - everyone is different.
JB. Not everyone even has a strategy - just use what is there, with no adaptation.
WD. Most persons with disabilities (PWD) arrive with a lifetime experience.
JB. Many PWD don't even consider they have a disability, have recently acquired.
WD. Certain amount of personal preference; can be hard to change any adaptive strategy that is adopted.
HB. No problem with existing phrase - but prefer "adaptive strategies in ..." eg "in using a computer", or "in browsing the web".
AA. Similar to saying the "usability" is experiential.
JB. What about the next bulleted list and second graphic.
HB. Where do the guidelines fit in.
[discussion is about "guidelines" section].
HB. WCAG/ATAG/UAAG should come before other W3C tech stuff.
BM - gets a disconnect between "guidelines" and the purpose (and rest) of the document.
AA. Tech specs is almost a background to everything else - what about a background image to the diagram?
JB. Can anyone with ideas please feed to Shawn.
Action: feed ideas on guidelines image to Shawn.
XX. Evaluation tool is not an action in the chain.
AA. Evaluation tool can be part of larger QA process, but part of content creation per se as illustrated.
HB. ".. for alternative text that describes an image".
HB. What about databases that contain images - they should have default alt text.
JB. Isn't this part of an authoring tool?
SLH. Does authoring tool include CSS and CMS? If so then needs to allow for alt text.
JT. Acronyms may confuse newbies - maybe "WAI guidelines" is better than WCAG/ATAG/UAAG.
JB. Seems like an acronym farm here - need to address.
JB. If looking for the broadest audience, then might need to reduce acronym usage.
Discussion now about "when one component is weak".
JB. Any reactions.
AA. System?.
HS. Complicates ??
Discussion on "getting implementation in the cycle".
HB. YES - getting it in early is good.
XX. Bullets are expressing the negative - can we be positive.
JB. Thanks for people's patience with walking through this document today, but please read again and comment online.
action: please all read and comment further on list - particularly about the concepts being presented, and how they are presented.
JB. Who will commit to doing this.
Carol.
HB. WCAG 2.0 is top of the reading queue.
WD. Reactions: enjoyed listening to the process.
SLH. May make changes today - so check list and refresh to get latest copy when re-reading.
JB. Next time we discuss this, may still need to focus on concepts considering the amount of good discussion today.
JT. I have to go. Bye all.
JB. Asking all group to read Guidelines document; only a few for extended reviews.
CL. Reviewing all docs for Canadian Govt - but within time frame, may not be in full depth.
JB. Talk to Wendy about deadline in relation to Canadian submission.
JB. When will people have reviews ready.
AA. Think 2 weeks considering volume of material.
20 August 2004.