GV - every one get open issues?
/* no - wendy sends to everyone */
GV - six open items. believe #1 (5.3 & 5.4) is closed.
/* from the open issues list:
5.3 Do not use tables for layout unless the content makes sense when linearized or a linearized version that makes sense is provided. This includes the proper use of structural markup within table cells (refer to Guideline 3). Note. When style sheet positioning is fully supported then tables should not be used - refer to checkpoint 3.6.
5.4 (leave as is - here's the 19990324 version) - If a table is used for layout, do not use any structural markup for the purpose of visual formatting. [Priority 2] For example, in HTML do not use the TH element to cause the content of a (non-table header) cell to be displayed centered and in bold. */
JW - proposes reorganizing a bit to highlight structure.
CMN - not necessary.
Resolved: consensus reached to reword 5.3 as proposed and leave 5.4 as is.
GV - talked with Mark Novak at the Trace Center, he believes making a browser-helper tool could be done with three mechanisms, and be done in less than a month on IE. in regards to netscape, not as sure about timing, but should also be doable reasonably soon. So, since there can and will be linearization tools (at least from here perhaps others). We'll link with ER. Top of our priority list. Daniel? Phill?
PJ - version 2 of browsers linearize tables by default.
CMN - not sure that's true.
PJ - when I accessed table with N2 shows text as big chunk.
CMN - have to put breaks in.
JW - if proper <P> markup in cells, then it should work.
DD - consider making it a p3?
JB - if changing priority, then changing the substance.
DD - then remove?
CMN - say this is a non-issue. the until user agent claim has been met.
PJ - agree, but then we would have to change "UUA clause" to let authors make the decision rather than w3c.
GV - what is the problem with removing the item?
CMN - mostly philosophical. having it there is a guide to the fact that historically it has been a huge problem. if you take it out you remove the pointer to the problem.
JB - don't see it as an historical issue but a process bind. If we can demonstrate that the technology has changed in the timeframe of writing this, then we can make this as an appropriate change.
JW - because the solutions aren't yet out there available to all the people who need them. would be dangerous to remove. perhaps put a note in techniques to discuss relevant tools.
CMN - prefer to allow content developers claim that condition has been met rather than the w3c deciding. current defn says, "The W3C WAI will
make information about support for accessibility features available from its Web site (either directly or by providing links to the
information). Content developers are encouraged to consult this information regularly for pertinent updates." not appropriate.
GV for compliance reasons there has to be an "authority." it will be moot in less time than it will take for a site to copmly with it.
JB - we do not distinguish between retrofitting or new sites. we need more evidence on this issue. we're debating again. several people felt that they need more evidence. i'm still not hearing evidence laid out.
PJ - I did post to webwatch-l, x and y, that os/2, dos, and unix have solutions. i don't have specific window/SR combos.
JB - need more than "an available solution" on each platform.
GV - does opera linearize?
CMN - yes. I dispute the fact that WAI should decide what is an appropriate level of compatibility. we aren't the authority?
GV - then who is?
CMN - whoever makes a conformance claim.
EH - agree w/CMN
CMN - /* example of small national govnt being taken to court for inaccessibile pg */
DD - if we had kept "interim" labels, then could have conformed to different levels of "interim."
CMN - someone must claim that situation has been met. currently states that WAI decides.
GV - i get a checklist. DOJ says you have to do. I get the "UUA" clause, I don't know what AT is. friend says, "that's a wheelchair." so i must judge if i should do it.
CMN - if DOJ says do, they judge.
JB - we're the resource. we need to see if there is a way to resolve 10.3, by ideally clarifying the current guideline.
CMN - 3 proposals.
1. UUA satisfied, remove 10.3. not substantial change - it's a test that doesn't need to be done.
2. UUA satisfied, leave 10.3 but have a WAI web pg that says, "UA allow you to linearize web pages."
3. WAI make info available, authors make the decision.
still think UUA is loosely defined and decision should not be left to WAI.
JW - agree with CMN argument. WAI provide info, does not make final decision, author make decision. way to clarify w/out delete: "at the time of writing, this condition is likely to be met soon. info about be made available."
DD - status of UA support be supplied with guideliens?
GV - where does it say that?
CMN - reads UUA again.
WC - see 3.11.1 of tecniques doc, "browser support."
CMN - we shouldn't weasel out or do a poor quality job. the requirement shouldn't be so strong. it clearly says that WAI will provide the information and keep it up to date.
GV - it says that the WAI will make information available.
DD - can we address each of the UUAs?
/* discussion about where to put the information and who should keep it up to date. should not be in guidelines. */
JB - "the best info we can to help support a decision"
GV - then, 10.3 is not sustainable in the current form. since the WAI can't give good info.
CMN - make the defn. slightly clearer - WAI does not have authoritive answer.
PJ - content developer needs to be worded in a way for them to make a decision. if they aren't going to find info, they'll throw their hands up. defn does not say, "all, or most" says "some." there are tools that support.
CMN - disagree.
GV - DOJ ruling on this. can't have a law who the only person who determines if you satisfy is you.
CMN - case law based on "reasonable person."
JB - [responding to PJ] trying to figure out what makes sense both for guidelines and process. since "most of" is satisfied (and wasn't aware of this is in the defn earlier), the suggest P3, which could be supported. not feel comfortable dropping it entirely. for those w/out access, is p3 rather than p2. i could strongly argue for.
GV - best suggestion so far. preserves the point. reflects the fact that it still is a problem, even if install a helper, it's still a problem. and moves it off of being a severe problem.
DD - changing level of priority in term of "interim" and # of people affected.
JW and JB don't.
CMN does.
GV - no, doesn't mean with #. the degree of difficulty because only one browser satisfied (and was server-side). now, not a big problem, many that can address.
CMN - but still have to get the pieces and put them together. it's a significant barrier.
PJ - but we're only talking about column wrap text.
CMN - yes, but must install, set up. etc. not impossible, but pain in the butt.
GV - issue is not can they get the technology to work, but can they get the information.
JB - PJ - in terms of info collection: lack of response is not equivalent to non-issue.
JW - we shouldn't determine right now until we've done all of the research.
GV - we have no choice.
CMN - we have a choice to say to the company that submitted...
GV - no, this is a problem across companies. suggest move from P2 to P3.
DD - support but think changing idea of priorities. because it deals with # of persons having the problem.
GV - no, not people, based on platforms.
DD - different than saying everyone has solution in hand.
GV - if there is support any browser, it can not be a p1. now we're saying, "if lots of browsers available" then probably not a p2 because lots of way to solve it. if all solve, not on here at all.
DD - o.k. but that is not stated anywhere.
JW - the defn does mention. readily available solution impacts user groups. thus, since solutions widely available, # of groups lower impact, therefore o.k. to move to p3.
DD - where is this stated - what gregg said.
JW - /* reading checkpoint text */ don't think it needs to be stated anywhere.
DD - i agree w/that.
CMN - dispute that there are lots of browsers that do this - lynx, lynx, lynx. /* people cut in disputing, naming others */ IE and current SR - most current costs lots of money. we can expect people to make good decisions - we already do when we leave it up to them to determine what are headers, lists, etc. i would like us to give the author the decision making power in the rest of the instances as well.
JB - don't feel appropriate to put burden on author.
JW - agree with CMN - we can provide info, up to govnt if go to court.
PJ - only on UUA for author to make decision or all of them.
GV - time out. people consensing on decision, but people have different reasons, thus argued. so, do we have consensus on leaving 10.3, but changing to p3?
JB - text might need to be adjusted slightly.
CMN - don't agree, can live with.
CL - concur. concern that people will have side by side english/french text. no problem.
/* discussion how much of an issue this is */
JB - yes, w/the caveat that the beginning of next week is used to make sure that there aren't holes, such as the language thing.
JW - don't like it. can live with it. same reasons as charles.
DD - support.
EH - support. although a bit troubled about changing the meaning of priority. want deleted. w/minor wording change.
PJ - looked at defn for p3. /* reads */ want it deleted, but will support p3.
WC - support.
GV - support.
Resolved: move 10.3 to p3 with minor wording changes.
JB - this falls into the category of "substantive change" (defined by Tim). but is the only workable solution based on the information that we have. thus we'll have to create a justification. "new evidence w/in spririt of the original document." may not work, but will argue strongly for it.
/* from open issue list - 1.2. Remove the priority 2 requirement for redundant text links for client-side image maps. Client side image maps are handled by text browsers and assistive technologies today. 1.2 should say to provide redundant links for server-side maps, when server-side maps are required. Refer to Checkpoint 9.1 in checkpoint 1.2 */
DD - it's an "until."
JB - thus it is a clarification, and appropriate.
DD - then lower priority as before?
CMN - same category as before.
GV - 2 or 3 depending on how soon be solved.
CMN - handle the same way as the previous one.
GV - motion on the floor to adopt same label on 10.3 - UUA with P3 for client-side, but p1 for server-side.
JW - dispute the p3.
CMN - disagree w/p3 rating. will not block consensus.
GV - yes the same things that solve this one as the previous one. thus CMN right.
JW - agree with CMN. don't like reducing the priority but can live with it.
CL - yes
JB - concerned that establishing a trend and burying the document.
/* many disagree */
EH - yes.
DD - yes.
PJ - yes.
WC -yes. but judy?
JB - there is a process issue. so i can live with it.
GV - yes.
Resolved: Including redundant text links for image maps is a P3 for client-side, but p1 for server-side.
/* from open issues:
1.3 and 1.4. Lower the priority of synchronized alternative multimedia content to priority 3. [ "1.3 For each movie, provide an auditory description of the video track and synchronize it with the audio track" "1.4 For any time-based presentation (e.g., a movie, animation, or multimedia presentation), synchronize equivalent alternatives (e.g., captions or video descriptions) with the presentation."] We agree that text transcripts and text or audio descriptions should be a priority item. We feel that important video information available as a text description is not made more accessible by being synchronized with the video. We also feel that text transcripts of audio tracks of video information is not made more accessible by being synchronized with video. It will also be a huge burden to re-produce existing multimedia content in the varied synchronized formats and platforms. The guidelines need to be clearer in describing the formats that it requires. This is similar to internationalization issues of translating audio and video information. Synchronizing the alternative content should be priority 3 and only applicable to new content produced.
*/
CMN - these clarified by 4/16 version. can't see how to make a guideline to only new content. accessible or not accessible.
JW - opposed to making a change to syncrhonization requirement. it's essential to understanding any multimedia content.
PJ - if i provide a movie to i have to provide a caption with the movie, or is o.k. just to provide a text transcript.
GV - have to do caption.
PJ - don't understand. i either watch the movie or read the trascript.
GV - doesn't work all the time.
PJ - then transcript should contain description about what is in the video at point of description. i can give the book instead of the movie. If i provide auditory description, should be syncrhonized. o.k. so p3 since alternative way of providing accessibility.
if significant dscription of graphic or procedure can't do it with auditory description. have to pause movie to listen to description then go on with video.
CL - with broadcast media going on to the web, be like every deaf person sending a stamped envelope to get the script of news they just saw. disagree with downgrading. agree can be work, but they're guidelines - if you don't want to do them, then don't.
JW - don't want to change. these have been carefully designed.
GV - when talk about equivalent. should discuss "best" equivalent. e.g. - mona lisa. your recommendation requires people who can see to read text rather than watch the video, and those who can hear to read text rather than listen to the audio.
PJ - but I have to provide all three?
GV - yes.
JW - agrees with gregg.
PJ - argues that this requirement is higher than U.S. govnt, thus is it reasonable.
JB - this is w3c/wai.
PJ - crux of issue. if i can listen to the video or read the desription of the video, is that accessible?
GV - you want them to listen to the video, and read the text to determine when the text corresponds with video?
PJ - we need to talk about significant information. we don't describe all info.
GV - hears gun go off, description says, "he shoots so&so"
PJ - but if have a script. it's all described.
GV - not syncrhonized.
PJ - doesn't matter.
JW - not easily done.
PJ - is a book an equivalent to the movie.
CMN - for a blind person, book is not good as movie. for deaf, not good enough.
GV - disagree. intonation, action that is auditory. described movie different .
PJ - keep defn. to accessible.
JW - still no reason to change.
GV - make a good point - how much of the info accessible. do capture most of the information. so perhaps maybe not a p1 (for blindness). however, not true for deafness - the visual presentation is very rich. would not split apart by disability and would definately not drop to p3. cost of adding auditory is nothing compared to costs of creating rest of production cost of movie.
EH - don't believe rates p1. already have text equivalents of audio and video. basic level of access is there.
DD - agrees. sets bar too high.
JW - nope. doesn't set bar too high.
PJ - i talked with several people who are blind. they preferred to read book rather than listen to described videos.
JW - not widely available. what i personally read they don't make videos of.
JB - i'm surprised by the question. if someone were to answer "no," that's not a reason to take away a form of access. DVS widely available in boston area in theaters, video stores, and local channels. it is extremely popular. if you have questions about, contact DVS for testimonials. e.g. titanic.
JW - it is what the guidelines are tyirng to reach - equal access. in order to do that, if they can take advantage of multimedia content, then they are entiteld to do that. for people who are deaf-blind, they need both. creating captions not that much more effort that providing text equivalents.
PJ - do I have to do both? (text equiv and caption).
JW - yes, if written one, then written the other.
EH - the audio production is costly. takes time.
PJ - do for every file format?
EH - keep issues separate between auditory description and text transcript?
/* wendy's computer died */