Agenda in e-mail list archives: http://lists.w3.org/archives/public/w3c-wai-eo/2004aprjun/0137.html
No outreach updates
Briefly check if any comments on revised requirements: http://lists.w3.org/Archives/Public/w3c-wai-eo/2004AprJun/0140.html
[Discussion regarding document status and changes that WCAG 2.0 will entail - reviewed last weeks discussions]
AA: Hank and I had conversations before posting if clarification needed
LC: Words from existing glossary. Might there be words that are not in current glossaries. "Augmentative Communication"
[Others agree]
Changelog: process should not be exclusive of current glossaries, should add additional words and have included in other glossaries
LC: Wording - will not be restricted
JB: Change to words will be "primarily" taken from WAI glossaries
Changelog: if we find something that should be included in other glossaries need to notify glossary owners and have included
HB: phrases too
JB: "word" may be inaccurate
Changelog: consider changing "word" to "term" or something that is inclusive of phrases as well.
HB: Concepts?
HB: Glossary will contain entry word or term
JB: redundant - word or phrase would work - two different things
JB: any one else comments on process? none
JB: comments on anything remaining?
HB: Not going to reflect changes in all documents
JB: What bother's you about that - wish someone would do it?
HB: yes
JB: ok with processes of this document
HB: Yes - don't want to be one to pick among set
JB: Concerning words drawn from documents that are already completed, and appear in multiple documents, an alternative, clearer, explanation will be proposed that combines the intention of the two definitions.
[JB proposes that we are done with document - no objections]
Hank, Helle, Andrew, Harvey, Sylvie, Carol and Libby volunteered to work on glossary
SLH: Major changes listed in changelog - major changes to organize. Move everything into one section. Links integrated into text in this version.
BM: Has a format somewhere between first and second versions. When looked at harder to focus on it - made suggestions.
BM: Don't have a nested list - go back to single list. Broke out links in content - easier to scan. Hard to focus on now.
BM: Change title some for flow. From "Web Accessibility Introduction" to "Web Accessibility: An Introduction" or "An Introduction to Web Accessibility."
HB: agrees with change
SLH: agrees - WebAIM has a general introduction page as well.
JB: Another introduction? Such a generic thing - I guess short answer don't see a particular problem with using that.
Changelog: change name to something like "An Introduction to Web Accessibility", editor's discretion
SLH: Overall impressions - compared to previous version what are folks responses to this? Revised content, etc.
CC: fine with me - comfortable with it.
DS: think this is working better for me. Optimistic friendly stuff doesn't give much feedback.
SP, AA, SAZ, LC, CS: like it
HB: what is web accessibility...environment
SLH: will come back to.
SLH: Blossom had two ideas - one to change structure and other to take out links.
SLH: Structure - usually only show H2's - just included H3's in this revision to help show what I did
SLH: Is it helpful in this case with only three main sections - does it make sense to leave those? Editors discretion?
JB: Seconds editors discretion - focus on substance.
HB: Likes as is
SLH: Blossom - in light of people being comfortable with inline - are you comfortable with it.
BM: Ok if also integrated into content. If description was more part of the content. How PWD offers more on ..... Quasi separated which is the problem.
SLH: Few that say "As described in" - adds more words though
SLH: Example - benefits of Web Accessibility - 2 things listed. Benefits here they are and here's where you can find it.
Changelog: look at integrating the links making the text primary and links
SLH: Everyone ok with current setup (leaving as one section) as opposed to separate sections
SLH: in a document like this where we're telling people what something is and encouraging them to do something. Roberto's comment if all they read is disability may think it doesn't apply to them. Want people to feel it might apply to them - but not water down focus on disabilities.
SLH: What do people think about this section addressing issues
SAZ: Good job of doing - really what we're trying to do. Important to highlight benefits why they should do this. Can't be accessible for everyone, languages, etc.
LC: Like to see if we can have an additional example that doesn't have to do with a mouse. Like to think of another example.
SLH: That would be great - send to list.
LC: When we talk about accessibility we talk about new language learners and other ways to access.
SLH: do we discuss in this document or another one?
SAZ: Should be in this - not sure about Technical Factors and Economic - exactly what Libby was talking about - different devices.
SLH: Legal and policy aren't really benefits. Social elsewhere
SLH: Where do we stop - if we put device independence, new language learners. Whole list of benefits? For examples? Link to them?
SP: document may not be able to link to everyone - saying "everyone" instead. Just mouse example is an issue. Should say how many people are effected by Web Accessibility up front.
HB: Mouse so easy for people to understand - simple way of explaining.
SLH: Last version had a more complex example of ALT text - looking for something that was easier - though not representative of all issues
SLH: Example, listing benefits and where benefits, and eventually go back to first sentence
LC: Can't do other's until fix first sentence. Have to make frame first.
SLH: don't see any reason not to - are other issues captured then?
JB: perennial debate about this. Convincing that it is relevant to everyone - discomfort when we de-emphasize disability issue, but understand it is important to make clear there are benefits to others.
JB: first sentence bothers because seems negative - disability secondary. Overclaiming "everyone" part. Thinking I'll look back and looking at online overview. It's the same. out of context - misleading. 1. disability should come first - followed up with "benefits everyone". 2. access to the web by everyone - overclaim. So many factors to consider to make sure everyone can access. Digital divide, design, language. Need to tweak more.
JB: Web accessibility ensures, improves, benefits others - more in the direction.
LC: Changed access to usable - why changed? communicates something different.
JB: if figure out here - should fix on online overview. Lead sentence on slide - needs to be changed.
SP: Purpose of web accessibility is making the web access. for PWD and also benefits people in other situations
JB: yes - I think we'll do wordsmithing separately.
SLH: When defining aren't supposed to use term in definition.
JB: ok because two words - can use in this case.
HB: Would like to emphasize having clarity on how it effects everyone.
JB: Maybe "and also benefits majority of other web users"
HB: obstacles too
SP: not just other users, should say developers, etc.
SLH: Yes organizations, etc.
SLH: another pass at first sentence and moving benefits.
SP: will be a longer sentence.
CC: move 3rd sentence up to first - would that help?
More specifically, the goal of Web accessibility is that people with visual, auditory, physical, speech, cognitive, and neurological disabilities can perceive, understand, navigate, and interact with the Web.
SLH: is that sentence too much, hard to translate?
JB: no - works well.
Web accessibility benefits people with disabilities and other Web users. Web accessibility techniques benefit those working under environmental or device constraints, like not having use of a mouse, working with a black and white screen or a text-only browser that doesn't support JavaScript, or even those with the need to work hands- and eyes-free, when driving. Web accessibility is essential to the users of emerging technologies, advanced voice recognition system
CC: those two together would work well - merge in with second sentence. Make whole thing flow together better.
SLH: Harvey's will fit into that as well. Users benefits others.
SLH: realistic implementation - "if you make your site accessible it will work on different devices such as a PDA" - is this true.
JB: amended version - qualified. My understanding is that sites that are accessible generally render better on different types of devices but might not specifically. compared to average website - like a good foundation for ensuring something will render well.
SLH: is statement true?
AA: More likely to be usable than a site that hasn't been defined with accessibility in mind. A lot further down the track if taken into account.
SLH: possibility of adding devices - doesn't automatically get you device independence. Still look at how to put in - but want to be careful with reality check. Don't want to make untrue or discrediting statements.
SAZ: does render on devices, but not optimal.
SLH: heard people say doesn't go far enough.
JB: optimized
SLH: credibility issue -
SLH: let's save example discussion for list.
SP: paragraph "More specifically..." - thinks that is a longish sentence. Suggest splitting up two parts - individuals who have functional disabilities adopt different strategies. Then "using the web means ability to perceive, interact" - explain concept, interact, operate. use the word "functional limitations". Can be temporary or environment.
SLH: requirements doc - want to keep as short as feasible. Wouldn't explain each ability - however would be good to get feedback on that from group. And on idea of using term "functional limitations".
CS: thinks more inclusive and people might relate to it more.
JB: jargony, way to avoid using the word disabilities. Used in certain settings to put more distance between medical paradigm and looking at individual needs. Communicate to people who don't work in disability rights setting
JB: curious to ask - Sylvie and Andrew's reactions
SD: cannot use something hand or something?
JB: easily translatable?
SD: I think would be translatable.
AA: I think it makes sense - if we had illustrations to term.
AA: more inclusive of people that don't have ongoing disabilities.
JB: Try and then test it with people that don't have background.
BM: I find it kind of jargony - unnecessary.
DS: jargony - I think the idea of making more explicit would help.
SP: When you illustrate with examples one can relate to it much better than just saying PWD.
SLH: if qualify with examples of disabilities - might be confusing anyway. If people know it includes things other than disabilities - and define as disabilities. Haven't gained anything.
SLH: If we want to use broader term - think about it.
SLH: send comments to list and I'll try to incorporate. thanks to comments on list (Blossom).
Discuss site-wide navigation concept
See email at: http://lists.w3.org/Archives/Public/w3c-wai-eo/2004AprJun/0139.html
SLH: Sitewide navigation concept.
SLH: One option - along left. WSTF discussed other options - wanted to bring concept to EO before going very far. Not talking about specific design aspects - not fonts, etc. Just concept. Any questions, clarifications?
SLH: What are people's reactions to deeper pages - ending pages.
JB: So when you got down in the site - the navigation would be spread out like that.
SLH: Title would be at the top with under the navigation-ish
DS: New concept with Plus signs. Seems intuitive. Plus sign throws me a bit.
SLH: so if we did this if a plus it would expand.
DS: comment on end pages - not clear why it would jump to this on end page.
DS: not sure I would expect it to look like that - new concept in terms of navigation.
SLH: Michael want to discuss background.
ML: Cisco has something very similar to this - went through 2 years of evolution. Have done lots of user acceptance and usability testing - proven system. Shouldn't be question of usability or accessibility. Question of if this works with content - do we want information to be persistent and for navigation to change depending on page we are on. Specific interaction that isn't explicitly stated - intuitive and does it complete objectives.
HB: yes and yes
SLH: WSTF if pursued would still do testing on own. While we believe and trust Cisco and thank for ideas, we would definitely still do our done.
SLH: does it add complexity and take up space - vs. advantages.
SLH: People who haven't commented?
LC: Like the navigational layout.
SP: Not uncommon - think it is helpful - where content starts there would be a skip to content link - at top. Probably visible visually as well - haven't determined yet for sure.
SLH: (last bit) and definitely would have a skip to content link for screen readers.
HB: using a table?
SLH: no, all positionin in CSS
SP: expand like a menu - should be accessible to users like me?
SLH: yes and yes
SLH: if we move forward, would look at different ways to implement and would want direct input.
SLH: Other concerns?
JB: Terms need to be much, much shorter.
SLH: would look at abbreviating.
ML: cut out a lot already
JB: got to set criteria. Blows functionality for me because I have to read instead of skim.
JB: Two words just pick one.
SLH: Yes and take off Web Accessibility from all of them.
No concerns with moving forward on idea at this time
SLH: Link to site map there - http://www.w3.org/WAI/EO/Drafts/UCD/site-map
SLH: Solid working draft - what we have now is conceptually breaking site into two major sections. One is about WAI and the other is Guidelines and Resources.
JB: About WAI much smaller concept - doesn't include groups. Questions whether that's the way people would approach site.
AA: Each of these - if go down - Guidelines and Resources. Intros to various guidelines will clearly link to working groups.
SLH: If someone came looking for helping with Web Content - go to intro page and would point to about WAI and group.
JB: so two links lead to same place.
SLH: About WAI - for people who are already in group. For new people would go through intro pages.
JB: can continue if needed
SLH: Other comments or thoughts from this week. Navigation or site map.
http://www.w3.org/TR/2004/WD-WCAG20-20040311/
Review latest draft and implementation of EOWG comments
See email: http://lists.w3.org/Archives/Public/w3c-wai-eo/2004AprJun/0148.html
JB: Spent time last year looking at document and got comments together. Realized had never copied comments back to EO - some background there. Have been staying in touch on what issues they are working on. Incorporation of them. Have been working on wording and we were worried about editorial and layout., Some things do relate to our comments however. Want to update people.
JB: update and alert people of likely schedule for next round.
JB: at least 5 people set aside time to look at next draft. Make sure document is as clear as possible - makes us ahve to do less work to reinforce.
JB: Compiled a lot of different links for your background.
JB: Have not yet commented or made all changes. Plan for publishing next working draft in July
JB: Change "none" to "mute" - commented on our changes - should be commented or something other than "none"
Glossary noted on http://www.w3.org/WAI/GL/WCAG20/WD-change-history.html#Changes we should look at it.
JB: Last two links are items they may want our comments on. If follow links are now looking at 3 level success criteria at http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-20040602.html#conformance
Summary of current questions on whether checklists should be normative or not http://www.w3.org/WAI/GL/2004/06/normative-checklist-issues.html
JB: Tricky question - pros and cons on both sides.
JB: conformists and normative issues - contribute as a group
JB: how approachable will document be to our audience.
JB: What do people think they may want to do specifically under scope of EO. Part of scope to review and comment on how well documents communicate
AA: Appreciate way you've put this together.
JB: do people agree that once draft comes out in July we review and some people review in detail.
LC: have to spend a chunk of time on this.
JB: anyone disagree?
Assume we agree and will spend some time on it. When we get there would be helpful for discussion - make sense to have Wendy there or not?
JB: may be more productive to review without someone from WCAG introducing it. Review independantly.
AA: good idea to be independant for first review
SH and HB agree
JB: Suggestion- look back at EO charter - invite chairs and editors
Harvey (technical comments), SP, AA, CS, and CC volunteer to look at 2.0 in July.
Probably September or October 2004 in the U.S., perhaps Washington, D.C.? Chicago? other?
JB: Quick initial pass at F2F meeting
JB: Looked back at list - 5 out of 7 have been in Europe. Need to rotate elsewhere. One in the US, September/October. Washington DC or Chicago came up. Local interest in DC and Chicago - both easy to fly to.
JB: have done California and Mass past few years.
JB: more related to teleconference participation
JB: Any reactions?
ML: Likes Atlanta - concerns about Chicago in Fall (cold).
SH and CS: Chicago nice at that time of year - fall colors
SLH: Issues with Atlanta ?
HB, DS, LC like DC
CC: Atlanta is a good "fly to" place
SAZ: October might be difficult for me
CC: Goes to a Conference in October
SLH: Comment DC drawing people - need to discuss goals
JB: Will discuss more next week - location or timing commments send to Judy or Shawn or list.
25 June 2004