Agenda in e-mail list archives: http://lists.w3.org/Archives/Public/w3c-wai-eo/2004JulSep/0190.html
HS: Tomorrow will report on TV explaining how Dutch people deal with disabilities - show for business people. Do work for Accessibility.
Review EOWG comments to submit:
http://lists.w3.org/Archives/Public/w3c-wai-eo/2004JulSep/0198.html
Not suggesting we do any formal approval - just taking feedback and how summarized - will pass along.
http://lists.w3.org/Archives/Public/w3c-wai-eo/2004JulSep/0198.html
#3. When explaining how to read this document, describe what the terms "informative" and "normative" signify within the format of the guidelines.
HB: Add links to glossary from "informative" and "normative"
#9. The blue boxes help differentiate content within the document but the strength of the blue is distracting for some people and not visible to other people. For the visual formatting, try other ways of differentiation, such as indentation of the content in those sections.
People like overall.
#11. - 17. on this page
Conformance questions?
#13. - "authored unit": The term "authored unit" was unfamiliar and confusing to EOWG participants, even after reading the definition. EOWG discussed some possible other terms and could not come up with a better alternative at this time. We also found potential problems with the use of the terms "material," "set of material," "author," and "URI" in this section. Clarification question: is it WCAG WG's intent that a conformance claim could be made about a single resource, such as an image, or an audio file? Also EOWG noted that the definition imported from device independence seems to exclude textual content.
SLH: Conformance claim about single resource?
JB: May not have captured everything from last time
JB: Helpful to explain why or give examples?
SH: Not sure that guidelines should go into that much detail.
JB: People surprised that anything beyond HTML would meet conformance - maybe would help with explanation?
AC: CSS stylesheets the user never sees
HJB: Confusing - way written is hard to understand. Would be strange to see a conformance claim
HB: Files would need to be accessible.
SH: Explain more
JB: What should guidelines be saying here?
CL: As a developer of content, stylesheets. Thinks valid- machine testable. But can see why developers might think it is important. Meaningless to average web user, but to developers useful.
JB: What would you like to see?
CL: Didn't understand before, but now understand better - even though guideline doc
JB: EO still feels needs more of an explanation including how and why
CC: Word "unit" made me think of organization not what created.
AC: Scope or deliminated or defined
CC: Item might work
web components
AC: collection of web content identified by a uri/url
14. It would be helpful to make a clearer transition from the introductory material into the guidelines themselves.
CC: Title or something to say this is the guidelines
#15. For glossary terms, avoid using the same term as part of the definition of a term, or at least don't bold-face the term when re-using it. Note that the definition of "programmatically located" re-uses the term "programmatically located" but without ever explaining what "programmatically" means. Also, the editorial note about programatically located should go into the glossary.
CC: Bolding term is a separate issue from redundancy of definition
JB: Split out as two comments - who term for real-time
CC: Real-time events
JB: will renumber later - current #16
no comments on 16 for now
no comments on 17
Refine comments here or go on and look at techniques document
JB: Keep going through current comments then look at Shawn's email
#11. The structure of the conformance model is clearer, but the description of the conformance levels needs to be stated more clearly.
SH: Structure of conformance - tried to put something in the intro about differences. Be stronger in this statement - making more clear.
JB: "much more clearly"
SH: Make a 2nd sentence.
HS: SP was commenting on this. Successful criteria is not needed to explain.
JB: Disagreement with how conformance level found
http://www.w3.org/TR/WCAG20/#conformance
HS: Something very difficult to understand - not important how much effort.
JB: something about usability - not what I thought originally
JB: Question of clarity not necessarily principle
HS: Difficult to say something about feasibility - problems with complying with priority 1 - Java based content on site. Priority 2 - cost work but not hard to do.
HS: Three levels - have to say something different about feasibility in three levels.
JB: What do you think it is saying?
CL: Agrees with first thing HS said - drop new scheme of conformance based on outcomes. Having been involved with WCAG 1.0 - technical accessibility. I think what's there needs to be explained better.
JB: explain Can be reasonably be applied to all Web resources - was confusing to some and unclear
HS: State feasibility also
HB: Indiv. groupings of glossary
HS: Everyone to take 10 from list - pick top 10 that comply
HS: 10 from A list - if we come up with same 10 ok. If all different words not clear about what belongs in glossary
#11. Continued. Judy reads her notes
Blossom: probably most important to comment on
JB: some not sure what meant, some disagree about what was meant.
HBJ: Difficult to understand
CL: If developing this how have I gotten there?
JB: how to make conformance claims
Group: agreement - highlight comment?
JB: Draw attention to comment 11?
Group: Yes
JT: I's and V's in brackets - example
#15. See above for full text
Comment on that in #4. - not meant to be kept in doc.
JB: Comments on Techniques doc
Blossom: reorg of doc?
JB: thought would be simple to do - can try to do some re-ordering
Blossom: Most commented on near top
#11.again
JB: #11 move in priority - only one heavily discussed
Jb: not going to do a major reorg.
Techniques doc.
#3. When explaning how to read this document, describe what the terms "informative" and "normative" signify within the format of the guidelines.
Consider making the glossary a module within the set of guidelines and techniques documents, rather than explicitly part of the guidelines document, and consider making enabling user-defined subsets of the glossary.
Who added this one?
HS: would be nice if disclosed to you words just within needs - could be modularized for doc being read
JB: was picturing glossary if not familiar with technical stuff would only show those. Or if not fluent in English would show more.
JB: What HS is suggesting better - enabling glossary subsets relevant to each document in the set
CC: can pull from database more clear
HB: Database has huge implications - doable.
HBJ: If part of W3 glossary could define each of the subsets
CS: Consistency could be maintained
HBJ: Get more of WAI glossaries into W3
JB: This might be accomplished by integrating the WCAG glossary into the W3C wide glossary
HB: haven't resolved differences in definitions between documents.
Blossom: 2 and 3 contradict each other
CC: 2 should be changed to say explain when first using
JB: #3 added new wording about subsetting glossary
Group: Ok
SH: Add example to #4
#5. Rename the section entitled "How to read this document" to "How to read this set of documents."
Regularize and simplify the formats of the gateway and techniques documents.
Simplify wording on this one
JB: bug in printing for Techniques
JT: Six different styles of boxes - only 3 in other
JT: Print version simplified (box-wise)
JB: There are at least 4 different styles of text boxes and lots of indenting
JB: reorg comments all ok
http://www.w3.org/WAI/EO/Drafts/sketchpad/wcag20-intro
Shawn describes comments on doc
What goes in separate doc?
JB: diagram - lots of documents there
JT: way to breakdown?
SH: not reality and will be broken down
How docs related
CL: Like concept of this being separated out.
CL: if content of separate doc was altogether in one section of WCAG would be ok. But to search from all different points would be annoying.
JB: Possibility of using layers
HS: Useful to have as new doc - shouldn't burden newcomers with old stuff.
JB: History in this or in WCAG draft that you would like removed.
Items in WCAG
CL: Nice doc
JT: agrees with Henk
CS: agrees as well
JB: New user - may or may not have been familiar with 1.0. Potential for new users on a continuous basis - if land in guidelines.
JB: if didn't pull anything else from web - what's guarantee that they'll see intro - separate from other document
JB: Bother's me that we are having either/or argument - should be middle ground
HS: History and relationship - not to intro. Some of the intro to 2.0 should be in document
http://www.w3.org/TR/UAAG/
http://www.w3.org/TR/UAAG/uaag10-summary.html
CL: Still needs a separate document to satisfy needs
JB: if combined would still get it
JB: problems caused by this?
SH: All front matter and none of navigation?
JB: biggest distinction would be lack of navigation
JT: What is a nicer way - what are boundaries.
http://www.w3.org/TR/UAAG/uaag10-summary.html
JB: Not standardized so don't have to follow previous examples
SH: Will have people point to intro so they get this information
JB: control over how we point people to guidelines - can point to intro pages before guidelines. First that some want last that other's want. Many will get to via link on slide of someone talking about guidelines. In bibliographic list - in many cases this is the place people will be directed to.
JB: Use cases about ways people approach guidelines - make sure we aren't assuming how people get there through paths.
CC: Exec Summary model - if not done in doc can reference intro
JB: yes - question is will they follow link or pull material?
#7 and #17 - are comments on this subject
Comments on #7?
On 17?
JB: Allowing easier updating important?
Relates to #7
Incomplete, very rough version:
http://www.w3.org/WAI/EO/Drafts/sketchpad/8-home
(then can follow some links in left nav: Guidelines and Resources, then Guidelines and Techniques, then Web Content (WCAG))
Revised Content - more coming for review
Visual Design - waiting for more designs
Technical implementation - proof of concept. Dynamic content, etc.
Evaluation - have not done much yet
Still things that aren't finalized
This is a compilation of what we've liked so far - placement of content, visual design not set (colors, etc.)
Left nav is firm, H2 above fold, WAI devlops and WAI welcomes firm as well.
Left nav - only one active. Guidelines and Resources - so you can see how would work
HB: Search to right - what is this?
SH: Would be a box and a standard button
SH: would be implemented when we have a WAI only search - for now would be link to W3C search
JB: May not be available - it's upcoming
HS: in Mozilla
SH: Not attempting to be a finalized CSS
Wayne: Change text size or color. Line height is also important - tracking. Want to make that adjustable as well.
SH: This would link to a page that would tell you that you can change these items and how to change. Might also provide some custom stylesheets that you can select.
User Agent Accessibility Guidelines - don't currently have anything in that area.
Wayne - I'll put in writing to EOWG
CL: User Agent group should see too
JB: Send here first - then someone will forward
Wayne: One stylesheet puts position static and makes page look funny. Doesn't linearize well.
SH: Haven't done anything yet - whiteboard sketch. Just for rough start - Style sheet will be adjusted later.
17 September 2004