lgr: final is a proposal for 2.4 about changes to content, value, ...., focus and relationships of content (idea is AT needs to know when changes have happened) lgr: that's the quick overview of proposed SC that came out of the UAAG analysiszakim, ??P0 is Joe_Clark js: comments or questions? ben: ack Becky ben: bg: question on 2.1 - can you give an example? - am thinking about a handler to respond to an event - is that handler considered programmatic or do I now have to have a separate set of APIs that take particular information? lgr: interesting question ben: bg: guess I don't understand exactly what that means asw: my question is that if we require that everything be keyboard operable and you can in effect activate through keyboard input, then I'm not sure we need this SC gv: one of my questions was that if everything can be done from the keyboard, then what was the goal with going beyond? lgr: looking through notes to see why we added this - should I take this back to the list? ZakimMichael_Cooper, you wanted to say like the proposals, question the home of the 2.4 one ben: action: loretta to post answer to Becky's question to the list ben: mc: I like them, the one proposed for 2.4 (changes to content, structure, selection...), feels very much like it doesn't belong in 2.4 based on our latest discussions, but think we should include it in WCAG somewhere, just not sure where ben: bg: I have similar questions about the one for guideline 1.3 (role state and value can be programmatically determined...) To me, that seems like a future type proposal. Right now, that's done for you by the user agent. Only way I could do it today is to use some of the work on DHTML roadmap. Means I can't try to create a component using JavaScript today. lgr: question is whether that is a result we'd like lgr: this req. would say that authors can't do this today, but when DHTML roadmap is done, then they will be able to do it asw: what about a plugin or something written in another programming language? bg: then they could do that today asw: is this related to software req. in 508 about exposing information programmatically about objects ben: ack joe ben: jc: can someone clarify at what level the SC is that everything must be keyboard operable gv: level 1jc: 2 issues with that - there are some things that can never be keyboard operable ben: jc: point 2, there is work being done for submission to w3c about drag and drop interactions gv: is drag and drop support cut and paste?jc: check Ian Hickson's log (I'll post a URI) joeclark: HTML 5 features for drag 'n' drop from Ian Hickson:http://ln.hixie.ch/?start=1115899732&count=1 lgr: will always be the case that there is content that is valid, but not accessible - still need to look at what additional constraints might need to be established js: we're about 25 minutes into this one, should wrap up soon. we have one action item so far lgr: second item to look at proposal for 2.4 and see if there is a better home for itaction: loretta consider alternative placement for proposed 2.4 criterion ben: zakim, close this item Zakimagendum 2 closed ZakimI see 5 items remaining on the agenda; the next one is3. GL 4.2, continued (def. of baseline and revised proposal) (25 minutes) [from ben] ben: zakim, take up agendum 3 Zakimagendum 3. "GL 4.2, continued (def. of baseline and revised proposal) (25 minutes)" taken up [from ben] ben: john reviews proposals ben: proposed SC: http://lists.w3.org/Archives/Public/w3c-wai-gl/2005AprJun/0248.html# starack Lore ben: ack joe ben: jc: I had a brainstorm - these days we're on this kick to avoid overlaps and redundancies in the guidelines - occured to me if we're recasting 1.3 as use web standards, obvious one is 4.1 (use spec). my big thing on that is we should require valid code at all times (presently a level 2) ben: jc: the other one is 2.4 (orientation) - seems that one is trickier, a lot of that has to do with structural markup, link elements, sections and subsections, etc. joeclark: q? ben: jc: am wondering if 4.1, and possibly 2.4 should be moved under 1.3 js: point of info about joe's proposals - in keeping with that effort to avoid unnecessary overlap, group discussing 2.4 the other day (yvette, michael, myself so far) was to figure out how not to have them overlap. js: lets see where that goes before we take up joe's suggestion to combine gv: point of clarification - 1.3 was about separating struct. etc. you had said we're rewriting it into use web stds. - wasn't sure what you meant by that, use web stds. is more under 4.1 (use spec) ben: jc: for our own ease of abbr. reference, we can say that my proposal for 1.3 boils down to "use web standards"ack lor lgr: joe, I think just boiling this down to "use web standards" is missing part of the goal here. (ex. PDF had to do some things to include structure in their specs - older PDF versions do not) ben: jc: just read something today (will post URI) that said you have to use latest versions of a W3C technolgy, which implies that you have to use XHTML 1.1 today. Loretta's example, there would be ways to encourage use of latest versions that do include the structure we need joeclark: Paper that mentions logical contradictions in WCAG 1.0: http://www.ukoln.ac.uk/web-focus/papers/w4a-2005/html/ gv: 2 items you mentioned (if you have structure, use it) PDF had structure, but AT couldn't access it ... joeclark: "Forcing Standardization or Accommodating Diversity? A Framework for Applying the WCAG in the Real World" gv: can have structure in a standard, but no way for UA to access that structurejc: but now you're dealing with user agents gv: has come up a number of times, ex. for a while, apple had no screen reader, saying that if there was a screenreader, it could be made accessible... that's one of the issues we still have is how we create a fairly bright line about what passes and what doesn'tjc: sounds like you're restating the inaccuracy that PDF can't be read - better example than PDF (because that's contentious) gv: one of the things we're looking at is when new techs come out, we want to be sure guidelines are written so that something that conforms is actually something that is accessiblejc: you mean like SVG? gv: yes, that kind of a situation, need to look at why and howq? ben: ack gv ben: ack gregg lgr: I think the issue about whether something is theoretically or actually accessible is the baseline question that we've been talking around - think we'll be writing guidelines for which its possible to be theoretically accessible, but need to rely on whomever sets baseline to make sure they are reasonable and that techs in use contain sufficient support lgr: I would claim that earlier PDF versions coulnd't be made accessible, wasn't until spec was updated that we could address some of these things Michaelscribe: Michael joeclark: http://lists.w3.org/Archives/Public/w3c-wai-gl/2005AprJun/0248.htmlis my previous proposal. Michaeljc: SC 2 we have decided this is implicit in using to spec Michaeljc: trying to persuade authors to use structured formats when possiblejc: know that not always available gv: this is not just part of "use according to spec" gv: but might be correct within context of first SC - Structures within the document can be programmatically determined. gv: don't know if that will be Level 1 because there are times you can'tjc: e.g., <embed>, but I no solution yet; nevertheless most Web content forever and ever will be in HTML so it's pretty relevant to majority of casesjc: don't oppose keeping L1 SC 2, just think it could be moved ben: q? joeclark: um, not "forever and ever"-- within the lifetime of WCAG 2. ben: ack Lor joeclark: q? Michael lgr: introduces testability problems Zakim-JasonWhite Michaeljc: accept an imperfect world but don't want a site to fail because of edge cases Michael gv: remember anything that can't pass our requirements are barred from any site claiming WCAG conformance Michaeljc: e.g., <b> and <i> vs <strong> and <em>jc: Ruby in Japanese only in XHTML, so in HTML it's a fudge Zakim-Bengt_Farre ben: gtircbengt has left wai-wcag joeclark: ?q? ben: ack jason Michaeljw: issues with proposal, will respond on list because of connection difficulties with phone todayjw: would like proposals extracted from discussion js: will do ben: ack andi Michael asw: "Structural markup or coding is used as required by technology spec" to resolve testability issue asw: not sure if this deals with Ruby example though gv: works if you only use tech that allows you to encode structure gv: issue if you use tech according to spec, and use a tech w/o structure, you pass without having to provide structure asw: not clear why we need it, L1 SC1 covers what we need joeclark: <A HREF="http://lists.w3.org/Archives/Public/w3c-wai-gl/2005AprJun/0484. html">http://lists.w3.org/Archives/Public/w3c-wai-gl/2005AprJun/0484. html</A> Michael gv: collpase SC 2 into SC1?jc: not opposed, some issues to work out joeclark: hold on. joeclark: Bare-bones language: http://lists.w3.org/Archives/Public/w3c-wai-gl/2005AprJun/0484.html Michaelbc: advantage of SC2 gives us a better hook for techniques to say which parts of spec are more important than others - which types of structural markup sufficieint for a given baseline joeclark: q? Michael gv: SC2 says _how_ to provide what SC1 requiresjc: which causes greater harm? a) keep both b) collapse 2 into 1jc: probably b is greater harm because harder to explain; a is just a little redundant gv: semantics = meaning for a lot of people, might read it as use structural markup to encode meaning of doc; gv: need to explain narrower def of semanticsjc: this is understood among web standards people and least of our problems js: let's move discussion to weeks/week/list joeclark: and the least of our problems with hard-to-understand terminology. Michaelzakim, close this item Zakimagendum 3 closedI see 4 items remaining on the agenda; the next one is4. GL 1.3, continued (25 minutes) [from ben] Michaelzakim, take up item 4 Zakimagendum 4. "GL 1.3, continued (25 minutes)" taken up [from ben] Michaelzakim, close this item Zakimagendum 4 closedI see 3 items remaining on the agenda; the next one is5. GL 2.5 (25 minutes) [from ben] Michaelzakim, take up next item Zakimagendum 5. "GL 2.5 (25 minutes)" taken up [from ben] joeclark: also, Success Criterion 2 is all about edge cases. and *I'm* all about edge cases. so we can be reasonably confident that we will take many examples into account by the time we're done. Michael asw: issues resolved by proposal asw: 1343 user errors - might offend users - change to "input error" asw: 1521 assist user to enter correct data e.g., input mask - propose new L3 SC (specific case so at L3) asw: <reads proposal as edited by Ben> Michael asw: concern this is really usability, not accessibility, but at L3 don't care muchack ale Michael asw: that's my concern too, does it mean *must* provide input support all the time? asw: more input mask stuff, when applicable asw: look at Yvette's proposalack g Michael gv: accessibility extension of usability, could put all of usability here gv: bright line is, would this stop people from being able to enter data correctly Michael gv: do sites actually have secret input requirements?chorus: yes Michael gv: but is it a specific problem to PWDack b Michaelbc: maybe this is a general technique Michael js: trip planner on Austin bus has specific requirements and doesn't tell you MichaelMy student loan site requires I enter payments a certain number of days in the future but doesn't tell me how many until I enter a date not far enough outjc: <another example, scribe missed it> Michaelmc: error recovery could be really painful for PWD, so better to have error preventional: error recover already covered gv: this is one of many techniques under category of "do what you can to help users prevent errors" js: so a technique, not SCack g joeclark: the example I gave was library (especially Library of Congress) subject headings, which are extremely hard to type exactly. Michael gv: seems more advisory than requirement asw: let's not add the SC MakotoircMakoto has left wai-wcag Michael asw: 1524 SC 3 not testable as worded, "significant" and "important" asw: tried to quantify those terms MakotoircMakoto has joined wai-wcag Michael gv: usually worry about lists of conditions, but proposal is better than previous gv: could miss an area but too bad, we can live with this since it's more objective, therefore support it Michaelal: concept of financial transaction difficult to define since for me everything is it asw: might make sense to move to L3 since it's so specific gv: so easy to meet might be good to leave at L2al: probably ok but impacts a lot of stuffal: feels like this SC is written specially for SAP and Oracle asw: meant to be for online banking etc. js: live with for now?al: ok, but will examine later gv: add "legal" to conditionsal: change "occur" to "conclude" gv: they're synonymous in this situation js: accept proposal w/ addition of legal?