/* minutes not yet available */
/* minutes not yet available */
Scribe: Andi Snow-Weaver
Summary of WCAG 2.0 comments
WC: Guideline 1 comments
RN: should be stated as requirements
Resolved: Group agrees that we should distinguish more between G1 and G2. Highlight differences
GV: G1 Presentation flexibility: Design .... G2 Interaction flexibility: Design...
WC: Guideline 2 comments. Aaron's comment - "preferences" implies saveable preferences
CS: "preferences" could mean saveable preferences. This is one of the server side techniques.
WC: Aaron thinks we sound like we are limiting people's creativitiy
MM: Rules, by their nature, do that to some degree.
MC: Associated docs can explain this.
GV: limiting their space
WC: Aaron suggests adding rationale for guidelines. Group agrees we should do that.
GV: Should have version with and without rationale.
MM: Cover rationale in separate document, debunk myths, etc.
RN: Is this the job of EO?
GV: will need to have some rationale in here.
ACTION: WC/GV add rationale to each guideline
WC: Daniel says preamble to G3 is confusing.
MM: Machine readable information is not content until it is presented to a user.
GV: If text in a db, intended for a human.
Resolved: Move preamble of G3 to introduction. Consider shortening to first sentence only.
JK: Might be helpful to include catch phrase with guideline; e.g. presentation, user interaction, comprehension, technologies.
Resolved: include catch phrases for guidelines.
WC: Terminology currently is Guidelines, Checkpoints, Technques. What about categories, guidelines, and checkpoints?
RN: Suggests that guidelines are "requirements".
WC: Judy said yesterday that we can't use "requirements".
Resolved: Group doesn't like "categories"
Issue: changing terminology so can refer to technology-specific checkpoints as something other than "techniques"
AS: They are principals.
GV: Most people think of "checkpoints" as something you need to make sure you "do". In EITACC, found we need two kinds of checkpoints - functional and technology specific. If checkpoints are technology specific, it is possible to do them but still defeat the guideline they were intended to meet.
JW: Interpret techniques in terms of the higher level guideline. Need to resolve the issue of terminology. Put on agenda for next meeting.
CS: Likes concept. Similar to concept in SW testing. Glass box and black box.
WC: Daniel says example 1 for 1.3 is unclear. editorial
WC: Daniel comments that mention of italics is presentation specific.
RN: Kept trying to figure out what the requirement is.
CS: This was word smithed to try to make it clearer to non-technical reader.
WC: Propose deleting the sentence. Group agrees.
JW: Should rewrite the explanation under this checkpoint.
CS: Should be rewritten to be similar in structure to the rest of the checkpoints.
AS: Could be worked into rationale.
RN: (unnumbered) bullet 2 is talking about presentation, not structure
GV: remove that bullet or reword "based on their personal preferences" to "to make it easier to find"
ACTION CS: propose rewording to checkpoint 1.3
WC: Aaron suggests combining 1.4 and 1.5
RN: 1.4 sounds like techniques for 1.5
GV: Could drop from logical structure discussion the bicycle example.
WC: Included for SVG
GV: Then say "For graphics, a bicycle might be ..."
ACTION: Reconsider issues with CP 1.4 and 1.5 after Cynthia proposes rewording
CS: Thinks 1.4 and 1.5 should be reversed
JW: Think 1.4 and 1.5 are in the proper order
MC: Implication is "don't use markup to provide presentation"
GV: yes, it is a prohibition
WC: Daniel surprised cp 1.6 is not part of guideline 2. Group agrees.
Resolved: Move 1.6 to guideline 2
GV: Graham's comment about 1.7
RN: Suggests dropping the word "newer".
GV: "style sheets" listed here but XML doesn't work without style sheets.
CS: Propose removing "this may be accomplished by ...."
LGR: Leaves it too fuzzy.
CS: If you give an XML doc to a UA
AS and JK: Problem with having this checkpoint here at all
ACTION: 1.7 Should probably be part of guideline 4. Wendy will reword.
JW: This is the issue of UA capabilities. Part of issue is that it becomes a separate conformance issue.
Resolved: Consensus of group is that technology-specific checkpoints will be normative.
/* William Loughborough joins meeting */
Scribe: Andi Snow-Weaver
/* Al Gilman joins meeting */
/* HTML WG joins meeting */
JW: Technology-specific section starting now. Purpose is to undertake further work on technology specific requirements for WCAG 2.0. Several sub-groups will be formed. Members of the HTML working group are joining us to communicate changes they are considering and to understand accessibility requirements for their work.
WC: Four groups are: EARL, HTML/CSS. In afternoon, we'll have server side techniques and PDF. Cynthia, Len, and Loretta will meet re: EARL. Rest will be part of HTML group.
Steven Pemberton: Starting to define real XML version of HTML. Up to now just be XML-izing old HTML. Objective is to make XHTML more accessible. e.g. accessibility of text needs to be improved. Particularly interested in WAI's feelings about <br> and <hr>.
JW: Minutes of this meeting will be published in a public space.
SP: Will note anything that should not be included in the minutes.
SP: Considering replacing H1 - H6 with just H so you would never have improper nesting of H's.
RN: Concern re: file size and data rate of transfer. Need to keep file size as small as possible.
JW: If this is not an accessibility issue, take it up offline.
AG: Need structure description language that is rich enough to describe what is there. e.b. sidebars are a way of conveying "concurrency" visually. Need to research how people are actually designing info on the web and
JK: Is there anything being done to improve forms?
SP: XFORMS WG addresses this. They are improving accessibility such as providing "caption" and "help" on every forms element.
AG: Need a way to combine image and text link into one tabbable entity.
WC: People still using "D" link because browsers don't support longdesc.
JW: HTML 4 has <object>
WC: Will image be depracated?
SP: I would be in favor of that. Need strong message coming from WAI. People say <object> is too complicated, etc.
AG: <object> we have now is not a saleable proposition in market today. Has to be re-engineered into a proposition that will sell.
JW: Underlying principal in WCAG is that person should be given access to version of content that is as close as possible to what they would get if they were capable of getting it in its original form. Benefit of <object>
is that it provides for the multiplicity of alternatives.
GV: Want to make sure that we either "fix" <image> or replace with <object>. Can't continue to have "broken" <image>.
??: All browsers now support <object>.
SP: accessibility issues with <hr> and <br>? text?, frames?
GV: non-linear document structure
JW: quick overview of WCAG 2.0 structure. 1.0 became rec in 5/99. For past year WG has been defining 2.0. Developing in two directions. First, make guidelines more general so that they can apply across more technologies. Make part that details with technologies more specific so that tools can easier determine compliance. Will have HTML specific requirements. May need separate set for XHTML. Need to make sure that guideline requirements track development of XHTML 2.0.
GV: Want to make sure we are not guiding people towards something that will be depracated soon.
SP: Should recommend <object>, not <image>. If use <image>, must use "alt".
GV: XHTML 2.0 writers will look at different list
SP: Objective is to reduce number of accessibility guidelines needed
MM: Technology checkpoints will be put into db so that authors can query based on the technologies they are using
GV: We have to keep in sync with HTML WG as it goes along. Can't depend on formal process to catch everything.
SP: WCAG WG should send e-mail to HTML WG with requirements.
GV: Likewise, HTML WG should verify things they think are accessibility issues with WCAG WG before spending a lot of time on them.
WC: Want to discuss tables.
ACTION: WCAG WG if image is broken, just make a formal request (to HTML WG) to have it removed
AG: we need to provide information regarding what an accessible browsing experience is wrt images
SP: GL are trying to fix up the problems of the past. Want to know how we would like to have things.
GV: New guidelines are more general. XHTML could just ensure that these things are satisfied by writing valid XHTML.
JK: Problem with <object> today. Can put an alternative inside <object> that is not accessible; i.e. <applet>. Or alternative might be somewhere else in the document.
MC: Just replacing <image> with <object> may make the problem worse.
WC: Interested in scripts and DOM
AG: Look at variable control in SMIL. Let WG know if requirements not being met.
ACTION: AG will post request to mailing WCAG list re: variable control in SMIL.
JW: Debate about what should be done with decorative images.
WC: Providing semantics based on the value of an attribute is not a good idea.
SP: Is there an accessibility issue with <hr>
GV: Problem is when people use it instead of structural markup.
SP: Mobile devices may not have style sheet processor.
AG: <hr> is closet structure in author's mind.
JW: Can use style sheets if <hr> is really a section header. Problem is case where want <hr> but is not section header
GV: Not everybody who is writing HTML understands hierarchical structure. <section with hr> and <section w/o hr> container?
GV: <br> is same issue as <hr>.
ACTION: WCAG WG needs to articulate recommendations and suggestions for XHTML 2.0 to the HTML WG and include PF WG in the loop.
SP: Replacing H1 - H6 with <sectionh>. Nesting provides structure.
WC: Can we get semantics?
SP: Make a specific request
WC: Do you have contraints on how many new elements you want to add?
SP: At brainstorming stage now. Send all ideas.
GV: Frames next
SP: Frames have serious usability problems. Want to replace with something that authors need and fix some of the usability problems.
AG: Should share list of usability problems.
SP: e-mail sent to HTML WG mailing list.
ACTION: SP send list of usability problems with frames to WCAG mailing list.
ACTION: AS send these minutes to HTML WG mailing list also.
GV: Some blind users would rather have frames than some of the alternatives that people do. With frames at least you can navigate between the frames.
MM: Design of some frames sites doesn't lend itself to linearization.
WC: As with sections, more semantics are better; i.e. navigation frame vs content frame. Big problem is when interaction in one frame causes something to change in another frame. NOFRAMES is not particularly useful.
GV: alternative to frames may be worse than frames because people will cobble together other things to accomplish the same thing.
JW: Useful to have semantics independent of what is used to do it; i.e. frames, tables, etc.
WC: EARL wants to be able to refer to any element on page. If ID were required on every element, it would make this easier.
SP: Don't think we can do that.
WC: Will people continue to use tables for layout?
SP: No plans to change tables. Understand their misuse. Don't see a way to prevent this. Will continue to allow nested tables.
WC: Could we get semantics on how they are being used?
TC: Proposal that tables should not be used for presentation?
AG: Should discuss offline on PF WG mailing list.
JW: Providing the right level of semantics and structure in the language reduces the misuse.
GV: Part of larger topic. Desire to think of everything occurring in structured format. People do things "free form". Sometimes the only structure available is how it's layed out on the screen. Is there any way we can support this behavior except by allowing people to misuse <table> and other structured formatting elements?
KH: Can we have a class of HTML called a template?
SP: Worthy of further discussion.
/* get notes from Len */
/* get notes from Cynthia */
Scribe: Wendy Chisholm
brian, andi, loretta, michael, wendy
MC features of scripting and what is accessible or look at each guidelines and figure out which features are impleicated. "confirm" new dialog or not? form validation - DOM rewriting. document.write generates entire page.
/* WC shows DHTML case study */
MC Do we differentiate script element and event attributes of HTML tags?
LK If all you have is stuff in the head.
MC Repositioning objects. Menu where hidden layer is made visible. Event handler looks for clicks anywhere on the screen. "did layer x get clicked. if so, i'll do this, if not i'll do this."
LK Could also be responsive to button clicks.
MC Form validation. instead of telling user by alert box. need to do server-side validation. duplicate on the server.
WC how hard of a sell?
BM didn't get a response.
ASW don't think should push for accessibility.
ASW perfectly accessible way to execute.
WC browser survey for scripts.
MC redirection throws off bobby. if script dosen't run, no content. redirection is the content of the page.
MC Scripting SVG?
LK Have text equivalents, when swap images swap alt-text.
MC Lines up with 1.2.
LK Don't know if does anyone any good.
BM 6.2 (WCAG 1.0) update text equivalents of dynamic content
MC if you use scripting language to generate content that includes media, generate accessible alternatives. later - don't use scriptingin languages to generate content.
ASW Can't do it to use the menus?
MC That's just showing and hiding.
WC if don't have scripts do have style sheets, then only load positioning style sheets after scripts are loaded.
LK what about 508 wording?
ASW thread on mailing list.
BM Do it where doesn't create undue burden.
1.2 and 1.3 SMIL and SVG type of thing.
1.4 markup or data model.
WC benefit javascirpt.
MC If documenting with document.write or writing to the dom - use structure.
WC basically have to follow ATAG.
1.5 separate and structure from presentation.
WC another benefit.
WC Deal with or generated with?
LK attach event to span but can't tab to it.
MC If not an A tag doesn't respond. have you tested?
LK Pretty sure w/recent MSIE.
MC Event capture, do what necessary to make it keyboard nav.
LK If capturing keyboard events, also do mouse.
MC A talmudic question. What is the baseline interface? discreet input.
LK Aside from philosophical aspects, if you have somebody using a head pointer to move teh mouse, should bring up onscreen keyboard.
WC What about using keyboard for mousekeys? What problems run into?
ASW just move mouse pointer.
MC We keep bumping up into. probably something we can new about.
WC Should at least get purpose of game.
RN How many alt characters can be displayed by browser.
MC Make your scripts use an external script so same script on each page.
WC Check elements across pages.
MC If do image swapping in navbar don't do "mouseover(asd;flkjaseoriuajfscript junk)" rather, "Mouseover(swap-function)"
LK Unless generated on server.
MC Suggested technique versus normative.
WC A server-side technique. Here is applet. We now have scripts interacting with flash, applet, PDF, SMIL, SVG, CSS.
BM I assume throughout the site.
WC WCAG needs to state that assumption.
LK Still issue with consistency with web. guru.com was even hard for us to figure out.
MC One of jakob nielsen's principals. even if bad for usability, if that's what people are used to, you have to do.
KHS HPR is reading 300 alt-text characters.
BM Do it slowly.
LK case where javscript has advantage over animated gif, since can turn it off.
WC will we work with cookies?
MC ran into a page where if didn't have ran into infinite redirect.
LK session cookies. sometimes, if set preferences for color, stops working.
KHS when you mouse over something and it turns blue, you don't want to hear all of that.
WC What about flicker? Has anyone seen a script generate it in the hertz range that cause seizure.
LK If have 2 images that "flicker" out of phase, cause seizure?
MC monster.com ad used a banner ad where the monster moves through the screen. only does it once, very distracting. perhaps a don't do? movement of links, have to catch in order to click.
BM Almost more of 2.3.
MC Or 2.4
LK Do these guidelines mean you are not allowed to have scrolling text? i would like it to mean that?
MC Should not be expected to follow links that are moving.
WC alerts and errors, should get focus.
LK As long as first line is, "this is a new window."
WC I like the CNN and Optavia approcah where before the list of links, will say "following links appear in new window."
MC If there is a target attribute in the link, in ACSS will say "link in new window"
LK what if title of window says new window?
WC we would have to test it.
MC If you use window.open w/out any window paramteres, uses default parameters. if send some, only uses tho. not sure if impementation or scripting definition.
Action ASW send some examples
Action KHS edit
Action MC compile what have written, send more examples
Action WC help KHS edit
Action DH get involved.
ASW many places where javscriptnot an issue.
Resolved: use [scripting] in subject of messages to the list so people can filter out.
KHS demonstrates inline scripting, to show pop-up windows and how HPR reads them. Only one that doesn't work is the one tha to opens a window.
RN Useful to have the description and put code up there.
Scribe: Cynthia Shelly
Change newer "technologies" to newer "standards"?
Marti: remove newer?
Cynthia: no, because many of the technologies we're discussing aren't standards based
Action item Wendy: wordsmith this checkpoint
Comment from Daniel: move to 3?
Kynn: it's kind of on the line. Had to put it in one place or another.
Resolved: don't move it.
Jason: can cross-reference
Comment form Aaron: the checkpoint asks for consistency but talks about interaction
Kynn and Wendy: What do we mean by consistent?
Kynn: Maybe 2 checkpoints: one for results, one for navigation
OPEN ISSUE: should we split this?
Action Kynn: write up suggestion for split checkpoints
Action Rob: help Kynn with this
Daniel - why not in guideline 3?
Kynn: Daniel didn't like where we split hairs
Kynn rewrite to make it fit better with guideline 2
WC: already covered?
Kynn: change concentrate to interact? The user's ability to do what the user is doing.
Aaron: delete this?
CS: I like the idea of deleting this. Point of an ad is to distract
Kynn: there are times when it's important to distract the user (alerts)
Action Item Kynn: work on this
Action Item CS: give feedback
Comment from Aaron: this is a UA issue
Agree: Jason, Kynn,
CS: can be done in script or in UA
Open Issue: is this UA or WCAG?
Kynn: Frames bullet should be changed to script
Gregg: how about "if you create extreme changes in context, let the user turn them off"
Gregg: Use mechanisms that users can control for any extreme changes in context. (say it better)
Rob: define extreme changes of context
Action Katie: add extreme changes of content to glossary
Len: change extreme to unexplained.
Matt: this may be desirable behavior in a shopping cart application
CS: is breaking the back button actually an accessibility issue, or just a usability issue? OPEN ISSUE:
Need an example
Already has an example
Rob: This is very hard to implement
Action Item Rob: figure out how to change this to make it less onerous.
Len: why not have different language choices (such as simple and complex language)
CS and WC: Anne and Leesa both want that
Rob: move to techniques?
Wendy: only if there is a generalized guideline to replace it that could point to the technique
Action Item Rob: try come up with a generalized guideline
Aaron's comment is editorial
Consensus is to leave it alone
Gregg: the current one is easier to read.
Write as clearly and simply as is appropriate for the [site, content, audience, whatever]
Should note that audiences for Web Content will always be larger than you might assume.
Resolved: Change to "Write as clearly and simply as is appropriate for the content of the site." Action Wendy: change it to WCAG 1.0 wording.
Judy: unverifiable, unmeasurable. We knew what we meant in 1.0, but it didn't speak well enough to everybody.
Jason: if you're going to raise this issue, please do so with a counter-proposal.
Len: does not cover "organization", which was in 14.1 from 1.0
Jason: it's in another checkpoint
Len, Gregg: There is a problem with the 1.0 -> 2.0 document.
Action Kynn: deconstruct the checkpoint.
Action Wendy (I think?) fix 1.0 -> 2.0 mapping document
CS: shouldn't the specifics be in the technology specific checks?
Greg: should be ok
Matt what's the relationship between 4.1, 4.2, 4.3
CS: o4.1 pick an accessible language o4.2 use the language right o4.3 use the accessibility features of the environment hosting your markup.
Rob: oFear factor
Gregg: 4.3 says be compatible with assistive technologies. It's the only place we say that. It should be 4.1.
Action Wendy: write an introduction
Action Rob: rewrite in less geeky language
Action Wendy: Move 4.3 to be 4.1
Scribe: Wendy Chisholm
WC INET in June in Sweden.
?? Too expensive.
GV Can't do it first week of June because of HFWeb in Madison.
WC I'm also committed to that.
KHS Avoid 20/21 - when 508 goes into effect.
HB: Avoid July and August - European vacation months.
GV Need someplace easy to fly in and out of and inexpensive. Major hub. Just bought ticket for Alan Newell to fly from Dundee to Seattle for $300.
WC University of Dundee in Scotland - coordinate usability testing?
/* other discussion not captured */
Resolved: Attempt to have next F2F 2nd or 3rd week of June in Europe.
Action: Submit ideas to the list for venue and events we might be able to piggy-back off of.
$Date: 2001/03/08 19:34:28 $ Wendy Chisholm, Andi Snow-Weaver, Cynthia Shelly