W3C logo Web Accessibility Initiative (WAI) logo > EOWG Home > EOWG Minutes

EOWG Minutes 11 June 2004 Meeting

on this page: Attendees - Outreach Updates - Glossary - Web Accessibility Intro - WAI Site Redesign - WCAG 2.0 Working Draft - EOWG Face-to-Face - next meeting

Meeting Summary


Agenda in e-mail list archives: http://lists.w3.org/archives/public/w3c-wai-eo/2004aprjun/0137.html



Outreach Updates

No outreach updates


Background (from agenda):

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

Web Accessibility Introduction

Background (from agenda):


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.

Structure and Link Changes

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.

Wording of first sentence

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).

WAI Site Redesign

Background (from agenda):

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.

WCAG 2.0 Working Draft

Background (from agenda):


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.

EOWG face-to-face Meeting Planning

Background (from agenda):

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.

Next Meeting

25 June 2004

Last updated on $Date: 2004/07/11 21:41:10 $ by $Author: shawn $